モダンフロントエンドはJSON APIが鬱陶しいので、無くしていきたい

はじめに Kaigi on Rails 2025で発表し、何人かの人といろいろ話しているうちに、モダンフロントエンドが面倒臭いのはJSON APIのせいではないかと考えるようになりました。そしてJSON APIそのものが悪いというよりは、JSON APIを必要以上に使う原因となっているSPAが問題ではないかと思っています。まだ考えは固まっていないのですが、まずは部分的に紹介したいと思います。 モダンフロントエンドはJSON基礎工事が大変 SPAのReactフロントエンドを作る場合、Hotwireなら不要だった多大な工数が新しく発生します。 APIエンドポイントのルータおよびコントローラから、JSON APIシリアライザ、クライアントサイドのルータ、JSON APIをfetchしてフォーマット変換する作業、さらにAPIの契約を文書化したOpen APIを作成します。ここには記載していませんが

[snowcrush]

この人の記事は常に「Rails開発している人としてはこういう意見になる」というコンテキストが抜けている。逆にその背景を理解していればなるほどと頷けることも多い

[soxandcity]

複雑ではなく冗長で煩雑なだけでしょう。 寧ろ複雑性でいうと挙げられている例の方が高いと思います。AI時代は煩雑さは問題にならないので、シンプルにバックエンドはAPIに専念することを私はお勧めします。

[yamad111]

"Rubyは動的型付け言語ですが、実行時には強い型付けをします。それに対してJavaScript/React/Vueは実行時に弱い型付けになります" ←ここの後者は例示はReactの仕様。他方で前者Rubyは言語。かなりナンセンスな比較だ。

[cpw]

良い設計はコミュニケーションをしなくてよくなる設計と思う。この例であれば何をERBに載せて何をAPIに載せるのかを議論しなくてよくなるのが良いかな。

[yuuAn]

UI が重要で、BE を FE から独立させるほどの規模でもないなら、普通は FE 側に BE の機能を実装する発想になる気がする。

[hc0001]

責任分界点を FE/BE の技術的分業に選んだ故の JSON API であり、巷は「モダンな FE は React による SPA だ」という思考停止も多いので、*トレードオフ（解像度重要）に見合っている限り* は BE での HTML 生成はたぶん合理的

[door-s-dev]

JSON APIにしてるのは元々クライアントがウェブだけじゃなくてアプリとかも出てきたからってのがあるのでは。ここで書かれてるような用途ならいらないよねってのはまあそう

[ghostbass]

そのWEBフレームワークで使われるテンプレートエンジンを捨ててまでＳＰＡというかそういうのを導入する理由があるのかどうか。jQueryは嫌だとか言って余計にややこしくてどうするんだとか

[nak1114]

AIで開発効率が良くなった結果、BE/FEで分けるのダルくね？でモノリシックに回帰するのは全然あり。そういう規模のプロダクトは無数にありそう。

[atico]

JSON APIがいい。 生成AIはどういうリクエストでどういうJSONが返ってきたかを見れば、問題解決できる。手間等々はコーディングエージェント使えば全く問題ないし、テストもopenAPIの規格だったらcommitteeでほぼ自動。

[YassLab]

“実現する方法は(流行りの言葉では)island化と呼ばれるものです。インタラクティブ性が要求されるところだけをReactなどで書き、それ以外はサーバでレンダリングする方法です。”

[kobito19]

JSON API作るだけでそんなに時間かかるわけないので、隠れてた負債が炙り出されてるとかが真の原因では。COBOL使い続けるのと同じ理由

[secseek]

サーバーサイドが古くてJSON APIに向いてないからそういうことになるんではって感じがします

[aarx]

"私はこのようなモダンリプレイスプロジェクトに頓挫した現場に複数入っていますが" この人が頓挫に多々貢献したんだろうなぁと思うような内容。複数現場入って何も学ばず失敗させ続け自慢とかヤバすぎ人材。

[soybeancucumber]

モダンとは

[sippo_des]

モダンフロントエンド大変なことになってるのね

[mk173]

開発者の手間を減らすため他のことを諦めてそうなRailsからReactへの移行は大変そう

[kompiro]

React Server Component の話かと思った。

[strawberryhunter]

最近、PHPだけで作るのが楽だったので、気持ちは分かった。ビルドが必要ないとか最高だな。

[tmtms]

バックエンドが Rails でフロントエンドとバックエンドで分業しないんであれば、React 使わないほうが簡単ってのはそれはそう

[Eiichiro]

Rractメインでうまく高速開発できてる会社を見れてないから、比較しづらい。 バックエンド要件が固定やほぼ無い場合で、フロントだけ変える案件が多いならReactも良さそう。 shopifyサイトとか、既存api利用のみ構築とか。

[kimihito]

https://inertiajs.com/ への私見も聞いてみたい。

[uehaj]

リプレースの文脈ではそうだろう。壊れてない既存のリプレースで、見た目や機能が変わらないなら、移行前後のセマンティックギャップが少ないほうが工数や、作業の複雑さが減るのは確か。

[mole-studio]

バックエンドに型のある言語使ってGraghQL経由で生成したら、リゾルバ書くだけで勝手にシリアライズされるのでデータ変換層が消えるんだけどねー

[fa11enprince]

SPAが必要なところと、JavaScriptでこねくり回さなくてもいいところはあると思う。無駄に全部SPAで作っちゃってるケースはあるんじゃないかな。

[remonoil]

Railsやめればいいと思うよ

[kakusuke07]

Railsやるならそうですねとしか。

[mr_ozin]

バックエンドのテンプレートエンジン+Vanilla JSで済むならいいんだけど、要件が複雑化してそれを折り曲げられない場面に耐えられるアーキテクチャとなるとフロントエンドに分離する必要がありますね……

[huusen20]

フロントエンドとバックエンドを分けることで、変化の流れが速いフロントエンドの乗り換えをしやすくなるし、バックエンドもAPIで抽象化されるので、部分的に切り換えも可能になる。長期保守を考えると良いと思うが。

[mayumayu_nimolove]

ちょっと前にフロントエンジニアはなくなるみたいな記事増田にあったけど、一向に安定しないからってのも一理あると思う。あ、私はしろーとなので知らん。Next.jsのディレクトリ構成決まった？

[dorapon2000]

“ページ全体をSPA化をしてしまうと、インタラクティブではないフィールドもすべてJSON APIに載せる必要があります。一方でERB直接書き込んでおけば、JSON化は不要です。”

[knjname]

マルチクライアントやシステム間連携を1つのサーバで賄う、操作ごとにエンドポイントが分かれ監査コントロールを楽にするとかまあ色々あるので、最適なものを使っていきたい