Astro.jsとAWSによるBlog構築 クラシックCMSとモダンフロントエンド

このBlogは、AWS CodeCommitでコードを管理、AmplifyでCI/CD、SSGした静的ファイルをS3に格納して（httpsにするために）CloudFrontで配信するという構成を取っています。フロントエンドはAstro.jsを使い、コンテンツコレクションで記事を管理し、Markdownで書いています。

sharpのエラー

Astroはv4からastro-compressも絡んだ画像の最適化に関するsharpのissueがあり、サイト構築中はそれでビルド時にエラーになる問題が出ていましたが、v4.1.2辺りで暫定的のようですが解決したようです。

Astroで使用しているインテグレーション

現時点で使用しているインテグレーションは下記の通り。

astro-compress
各種ファイルのminify。

@astrojs/partytown
Google Analytics等のサードパーティJSを並列処理化。

@astrojs/rss
RSSの生成。

astro-google-fonts-optimizer
Googleフォントの最適化。

BlogをJamstackにしない理由

ヘッドレスCMSを用いてJamstack構成にしないのは、CMSサーバの管理をしたくないというのが大きいです。S3 + CloudFront構成にしているのもWebサーバの管理をせずに独自ドメインでサイトを公開したいというのがあります。もちろん、ヘッドレスCMSについてはSaaS版を使うという選択肢もありますが、記事データは手元に置いておきたいなと。ただ、CMSを使わずにMarkdownで記事を書いていると、CMS以前のHTMLを手打ちしていた時代が何となく思い起こされます。

また、SSGでは記事数が増えてくるとビルドに時間が掛かるという問題も予想され（個人Blogでそこまで記事数が増えるかは不明。）、APIを叩いてSSGするよりは記事データも含めてスタンドアローンでビルドした方が相対的にパフォーマンスには優れるだろうという推測もあります。
ただ、コンテンツコレクションでの動的ルーティングは、記事数が増えた場合にどう影響するのかは未知数なところですね。

フロントエンドフレームワークでのSSGビルド時間問題は、MovableTypeで記事数が増えて再構築に時間が掛かるようになったり、WordPressで記事数が増えてメモリが足りなくなったりするのと似たようなもので、いつまでもソリューションが見つからない古くて新しい問題だという印象です。

そもそもフロントエンドフレームワークの多くは、画面の状態を管理したいインタラクションの多いWebアプリ（SPA）を構築するためのソリューションであり、大した状態管理が不要のスタティックなボリュームのあるWebサイト（MPA）には不向きということもあるでしょうか。

クラシックCMS vs. モダンフロントエンド（+ヘッドレスCMS）

フロントエンドフレームワーク、各種npmパッケージ、Node.js、AmplifyやVercel等のビルドWebホスティングサービスといったようにモダンフロントエンドを中心とした構成は変数が多いため、初期構築のオーバーヘッドやバージョンアップの追従コストが高く、また、問題が発生した場合の原因究明もモノリシックな構成のクラシックCMSと比較すると相対的に面倒です。

クラシックCMSであれば、EC2やVPSでOSのレイヤーから自分で構築することも検討できますが、モダンフロントエンドを中心とする場合はリソースをフロント（アプリ）側に割く必要性があるため、リソースが潤沢にある場合を除けばサーバ周りはSaaSなマネージドサービスを前提に考えることになるでしょうか。

マネージドサービスを選択すると管理コストをサービス側に転嫁できますが、引き換えに自由度は下がり、システムは隠蔽・抽象化されます。とは言え、日々進化を続けるクラウドのマネージドサービスであれば、だいたいのケースで事足りることが多く、スケールの面で言ってもマネージドサービスに軍配が上がるでしょう。

モダンな環境と比較し、クラシックCMSで改善が必要と思われる点は、テンプレートをGitでバージョン管理することが面倒だったり、テンプレートが独自記法なのでLinterやフォーマッターが微妙だったり、デプロイが手動だったり、ヘッドレスではないのでテンプレート（デザイン）とデータが密結合していて柔軟性が相対的に低い、といった辺りが思い浮かびます。

どちらか一方が必ずしも優れているという訳ではなく、結局、技術は一長一短なので、リソースなどを含めて検討し、適材適所、その時々で使い分けていくことになるとは思っていますね。