ずっと、プレーンなReactで開発してましたが、Next.jsを使う様になりました。Next.jsの周辺にあるSSR、BFFなどの登場人物達を一旦整理してバラバラのドットを繋いでいきたいと思います。
そもそもNext.jsとは
ホスティングサービスのVercel製のReactフレームワーク。
主な便利ポイントは
(1) Pre Rendering
(2) ルーティングなどのサポート
(3) API Routing (9.0から)
(1) Pre Rendering
Pre Renderingは読んで字の如く、事前にHTMLをレンダリングして、「HTMLと必要最低限のJS」をクライアントに返すこと。
Pre Renderingの前にClient Side Rendering（SPA）を復習
プレーンなReactで作成されるWEBページはリクエストされた際、ほぼ空のHTMLへReactがコンテンツを生成してページを描画する。つまりブラウザ側でHTMLファイルを組み立てるのがClient Side Rendering
Googleのクローラーは、Reactがコンテンツを生成する前のほぼ空のHTMLファイルを見て、低く評価してしまう。※最近は改善されつつある。
また、ブラウザが動いてる端末(スマホやPC)でHTMLファイルを組み立ててレンダリングするので、大きなサイズのJavaScriptを読み込むと遅くなり、しかも読み込むまで何も表示されない初回読み込み問題がSPAの弱点。すごく細かいところでいうと、OGPタグに対応されない、などもあります。
そんなSPAの弱点を克服するために生まれたのがPre Rendering
事前にHTMLをレンダリングすることで、Googleのbotへコンテンツを正しく認識してもらえたり、スペックの高いサーバでレンダリングしてブラウザへの負荷を下げたりと、Client Side Rendering（SPA）の課題を解決できます。
Pre RenderingにはSSRとSSGの２種類がある
・SSR：Server Side Rendering リクエストごとにサーバーでHTMLを作成して返却する。
・SSG：Static Site Generation 言葉通り静的サイトを生成する Pre-redndering。ビルド時にAPI叩いてデータを取得する、SSRだとサーバーのセキュリティ問題を考慮する必要があるが、SSGなら不要。
サーバを持つこと自体がデメリットになりうる、そこでNext.jsの開発元であるVercelは、SSGを推奨している。
→都度リクエストを受け取ってHTMLを生成するのがSSR、デプロイ前にHTMLを生成するのがSSG
ビルド時に表示内容が決定しているページはSSG
アクセス時に表示内容が決まるページにはSSR
という風に、ページごとにSSR、SSGと使い分ける設計もOK、アプリ全体で統一させる必要はない。
Next.jsでSPAの開発も可能
Next.jsはSSRフレームワークだが、Pre-Renderingさせず、Client Side RenderingさせるSPAを開発する事も可能です。
(2) ルーティングなどのサポート
pages ディレクトリにファイルが追加されたとき、ルートとして自動で使用可能になる。
pages/index.js → /
pages/blog/index.js → /blog
プレーンReactだとルーティングのために別途パッケージ入れたり面倒ですが、最初からサポートされてるので楽ですね。
(3) API Routing
Next.jsで簡単にAPIを作れる機能で、Node.jsみたいな感じで書ける。
ただ、DBから値を取得したり、認証処理したり、といった複雑なビジネスロジックが含まれるような本格的なWebAPIがこのAPI Routingでできるのか？フルスタックフレームワークとして使えるのか？というと微妙らしい。
この機能はBFFとして使う方が向いているらしいです。
この記事に詳しく載ってます
ひとまずは以上です、随時追記していきます。