CSRとSSRの長所短所

ReactとHotwireの大きな違いは、CSR中心かSSR中心かです。それぞれがどのような長所を持ち、どのような短所を持つかは、かなりの部分がそこで決まるように思います。ここではいくつかのポイントを取り上げて、議論したいと思います。

JSON APIの視点

CSRはJSON APIが必須であり負担である

CSRはJSON APIを必要としていますが、これの作成およびメンテナンスには意外と多くの工数がかかります。いかに議論が活発に行われ、ツールが作成されているかという事実から、JSON APIの作成とメンテナンスが決して容易ではないことが伺い知れます。

• 純粋なRESTだと一度に複数のデータが取得できず、N+1リクエストを発生させやすくなります
• RESTのN+1リクエストを防ぐために、一つのエンドポイントに関連データを加える方法があります
• GraphQLを使って、クライアントが一度に多くのデータを任意に取得できるようにする方法がありますが、課題も多くあります
• APIはフロントエンドとバックエンドで共有される必要があります。そのためにOpenAIなど、ドキュメンテーションの規格が用意されています。加えてこれを作成・編集するためのGUIツールもあります
• APIエンドポイントの動作確認はcurlだけでも十分ですが、多くの人はPostmanなどのGUIツールを使用します。多くのGUIツールが作成されています

JSON APIが複雑になるアプリはSSR向き

Reactを使う限りはJSON APIは必須になります。SPAであればもちろんですが、Next.jsのようにSSRがあったとしても、（Hydrationのために）裏ではJSONが自動的に作成されていますので、JSXに渡すオブジェクトはシリアライズできるものに限られます。

一方でHotwireのようなSSRの場合はJSON APIが不要です。ERBの中でドメインモデルをそのまま扱うことが可能で、そのメソッドを呼び出せます。ドメインモデルをシリアライズしなくても、あるいはシリアライズできなくても、ERBでは自由に使えます。

つまりアプリ画面の要件によりJSON APIが複雑かする場合、その画面はReactのようなCSRではなく、HotwireのようなSSRで作った方が良いということになりそうです。

• 一つの画面に複数のモデルが混在するような画面はJSON APIが複雑になりやすいです。維持管理の負担が増大します。GraphQLも銀の弾丸ではありません
• 一方でHotwireのようにサーバ側のHTMLテンプレートで作成するページであればJSON APIは不要で、モデルのシリアライズも不要です。HTMLテンプレートからモデルのメソッドが直接呼び出せますので、リッチなドメインモデルがそのまま使えます

サーバ通信なしで動作させる視点

SSRは必然的にサーバ通信を必要とする

HTMLをサーバでレンダリングするSSRの場合、必然的にサーバ通信が必要になります。サーバ通信ができない、もしくは遅延を嫌ってサーバ通信をしたくない局面では、SSRだけに頼ることはできません。

サーバ通信なしでも動作させたいアプリはCSR向き

サーバ通信できなくても正常に動作するアプリを作成したい場合は、SSRは不適です。HTMLをサーバで作成しますので、サーバ通信をしなければ画面に何も表示できないためです。

またサーバ通信をする場合でも、CSRであれば複雑な楽観的UIも作成しやすいです。

このようなケースにおいては、CSRを前提として開発されたReactが優れています。