Table of Contents

• ブログサイトがSSG(Static Site Generation)で生成されるようにしました
  • なぜSSG？
    • 費用を節約するため
    • Angular でSSRとSSGができるようになっていたから
  • 構成
  • SSG in Angular の使い勝手
  • MarkdownからHTMLの生成
  • まとめ

ブログサイトがSSG(Static Site Generation)で生成されるようにしました

ブログサイトをSSG(Static Site Generation)で生成されるようにしました. 久々の趣味開発.

なぜSSG？

費用を節約するため

以前の構成は, Google Cloudのお勉強とWebアプリを開発したい欲が強すぎたために, 無駄に色々な手間(ロードバランサー,データベース,Cloud Run, SPA構成などなど)をかけていました.

当然, インフラの運用コストがかかります. PVがショボショボなのでCloud Runにかかるお金は0円でしたが, Cloud SQLには月1500円ほどかかっていました.

今回SSGにすることで, Cloud SQLを利用しない構成にしました.

Angular でSSRとSSGができるようになっていたから

ちょっと使ってみたくなりましたというのが本音です. 自分はAngular v12あたりで止まっていたのですが, 久々に触ったら物凄く変わっててビックリしました. signalという新概念ができており, なんかReactっぽくなってね？と思いました.

Reactにしなかった理由

Reactのフレームワークが乱立しており, ハズレのフレームワークを選んでしまった時に将来発生する移行コストを嫌ったからです. 最近のReactはフレームワーク(Next.jsなど)の利用を推奨していますから, フレームワークを利用せずにReactを利用するアイディアにもネガティブでした.

構成

超シンプルになりました.

• 記事を書く
  • ローカル環境に立ち上げたエディタ上で記事を書きます. 1つの画面中にMarkdownとHTMLが表示されていおり, Markdownを書き換えた後のHTML即時に確認できます.
  • このエディタはSSGやSSR(Server Side Rendering)ではなくAngularのSPAです.
• 記事をアップロードする
  • ローカル環境にてMarkdownをHTMLへ変換し, AngularのSSG機構によって配信するHTML, 画像ファイルなど含めた配布物を作ります.
  • 配布物はGitHubへpush後, Cloud BuildのジョブによってCloud Storageへアップロードされます.

なんとしてもGoogle Cloud使ったる！という不毛な執着心から, 配信インフラを Cloud Load Balancing, Cloud CDN, Cloud Storage としました. (さらなる費用削減が求められたらGitHub pagesなどへ移行し無料で配信しようと思ったりしていますが, それはプライドが許さないのであります)

↓エディター

SSG in Angular の使い勝手

使い勝手は良かったです.

公式Docを読み, 難なくSPAを書くのと同じようにSSGアプリを書くことができました.

1つだけハマった点は, レンダリングする際に必要となるデータ取得をOnInit関数などではなく, route guards の中で実行しなければならないことでした. 私はResolveFnを使いました.

MarkdownからHTMLの生成

Goldmarkというライブラリを使っています. カスタマイザブルで比較的にLightweightなライブラリなので気に入っています.

まとめ

ブログサイトをSSG(Static Site Generation)で生成されるようにしました. 最近忙しくて趣味開発があまりできてないですが, Webサービスを0から作る行為はやっぱり楽しいものですね.