NILTOプロダクトサイトのアーキテクチャについて

前提

プロダクトサイトをベータ版からアップデートする際「NILTOを組み込みリッチなサイトで PageSpeed Insights で100点を出す」を目標として掲げており、達成する為にどうするかを考えました。

まずレンダリング方式から「SSGだと速いがコンテンツ増えた場合に更新までのビルド時間がネックになる...」「SWR だと CDN の調整や実装コストが...」みたいなことを考え出した結論が

レンダリング方式をSSRにして、速度面・負荷軽減・内容更新の即時性は CDN に任せる

というものでした。

その観点からアーキテクチャを作成しました。

アーキテクチャ概要

エンジニアとして頭の先から足の先まで Google Cloud Platform（以下GCP）ユーザーなので、まず GCP で包括的に完結する事も重きに置いて上記のようなアーキテクチャになっています。

実行環境は Google App Engine の Node.js ランタイム、パフォーマンスに直結する CDN に関しては Cloud CDN を利用しており、 Cloud Load Balancing の設定で即座に連携をして手軽に導入ができます。

実行環境として Node.js ランタイムを利用していますが、そのフレームワークとして Astro を採用しています。

今ノリにノってるフレームワークの Astroですが、採用の理由としては勢いがあるのはもちろんあるものの、下記が大きな理由です。

他のフレームワークと組み合わせて開発ができる
1. React、Svelte、Vue 等のフレームワークを組み合わせて開発が可能
出力時に無駄な js が出ないので、パフォーマンスが良好
1. Partial( Selective ) Hydration がコンセプトにあり、不要な js は取り除かれ、開発者が必要な js だけを残すことが可能
直観的で分かりやすい
1. ディレクトリ構成、ファイルベースルーティング、コンポーネント構造など直観的で分かりやすく、コーダーやコードも書けるデザイナーなどの非エンジニアの方にも教えやすい

特に 3 の直観的で分かりやすいに関しては NILTO を組み込む事においても重要で、Developer API で NILTO で入力をしている内容を Astro のコンポーネントスクリプト内で読み込み、その内容をコンポーネントテンプレートを利用する上から下への流れは直観的で分かりやすいと思っています。