Next.js の App Router で静的ブログを作る方法
2024/08/03
本記事では、本ブログを支えている技術について紹介します。
Next.js でブログを構築する理由
本ブログは主に以下の技術スタックで動いています。
- Next.js v14 (App Router)
- Cloudflare Workers & Pages
- Cloudflare R2
- Python v3
- Material UI(MUI) v5
本ブログは Meta（旧 Facebook）社が開発している JavaScript ライブラリ「React」の Web アプリケーション用のフレームワークである「Next.js」で作られています。
採用の理由としては、現在 Web サイト開発で主流になっている WordPress はプラグイン管理が複雑かつ サーバー運用にコストがかかるためで、 一方 Next.js は上記の難点を解消しつつ Web の最新標準に近い組み方ができ、 かつコミュニティ規模が大きく開発を進めやすいからです。
（モダンな Web サイト用フレームワークは他にも Gatsby や Nuxt や SvelteKit などがありますが、コミュニティの大きさで見たら Next.js が一番な印象です）
Next.js × Cloudflare によるサーバーコストゼロの高パフォーマンスブログ構築
Next.js で作られた Web サイトは、 Web サイトホスティングサービスにデプロイすることでインターネット上に公開できます。
レンタルサーバーを使わないため、かかっている費用はカスタムドメイン代のみです。
Next.js のデプロイ先として開発元会社が提供している「Vercel」がもっとも相性が良く、 Next.js の機能をフルに使えるようになるのですが、 Vercel は無料プランを商用サイトに使えない制約なのでデプロイ先として「Cloudflare Pages」を使っています。
Edge Runtime によるサーバーサイド処理
Cloudflare Pages は基本的には Next.js のサーバーサイド処理が動きません。
（ほかにも画像表示処理などで別途ケアが必要になります）
そのため、そのままだとブログの記事検索や記事の一覧表示などの動的な処理ができませんが、「Edge Runtime」という、サーバーではサーバーサイド処理をやらないが「エッジ」というインターネットの入口部分にある装置がちょっとしたサーバーサイド処理をやってくれる仕組みを使う方法があり、それを使っています。
ただし Edge Runtime が処理できるのはあくまで「ちょっとしたサーバーサイド処理」なので、 例えばファイルの読み書きなどはできません。 なので残念ながらこれだけではブログの記事検索や一覧表示はできません。
そこで、Cloudflare の「R2」というストレージサービスを使います。 本ブログではビルド時に記事ファイルを Python で解析して、 記事検索や一覧表示用に整形して R2 に仕込んでいます。
（Cloudflare Pages は Python が組み込まれているので Next.js のビルドに合わせて実行させることができます）
つまり、記事検索や一覧表示時は Edge Runtime を使って R2 から情報を取得して処理しているわけです。 これで記事検索、一覧表示、ページネーションなどにしっかり対応しつつ、静的にブログ記事を表示できます。 静的な記事表示ができると、WordPress などの一般的なサーバーサイドレンダリングのやり方と比べて 劇的に速く画面を表示させることができます。
サイトのパフォーマンスの指標となる Lighthouse のスコアもこの通りです。
念のため補足しておくと、無料枠が大きくかつ使いやすいため R2 を使いましたが、他のデータストアでも構いません。 キーバリュー型データストアであればより高速に処理できる可能性があり、 RDB 型データストアであればより複雑な検索条件にも対応できます。 Cloudflare にも「KV」というキーバリュー型データストアサービスや「D1」という RDB があります。
デザインシステム（Material UI）の活用
もうひとつ、Material UI について紹介しておきます。 Next.js では、「Material UI」という Material Design 準拠のデザインシステムを使うことができ、 本ブログで採用しています。
Material Design というのは、Google が提唱しているデザインガイドで、 スマホの UI や、GMail などの Google アプリで使われています。 これを素の CSS で作ろうとすると結構大変なのですが、 Material UI なら（若干初期設定が大変ですが）対応するコンポーネントを呼び出すだけで表現できます。
Material Design に沿って開発すると、良くも悪くもスマホや Gmail の UI に近くなります。 そのため没個性になるリスクもあるのですが、 突飛なデザインでちゃんと組めるほどデザインセンスがあるわけでもないので、 見た目に統一感が出ていい感じになったので OK ということにします。
まとめ
本記事では本ブログを支えるモダンなシステム構成について紹介しました。 普通に Web サイトを組むのと比べてコーディングが必要になりますが、 そこはエンジニアの腕の見せ所になるかと思います。 使っている技術も他で応用できるものが多く、組んでみる価値はあるかと思います。