もうかれこれ 10 年以上前から作りたいと思っていた技術ブログ的なものをようやく開設する運びとなった。
QiitaとかZennとか技術記事系の素敵なサイトに投稿すればいいかなとも思ったけど、ああいうプラットフォームに投稿するのってちゃんと記事書かなきゃいけない気がしちゃってちょっとハードル高いよね。
やっぱり日々のメモ代わりに気軽に色々書ける場所がいい。
そんで今立ち上げるなら静的サイトジェネレータ系一択だなと思ってHugoとGatsbyで迷った結果Gatsbyでやることにした。
何か流行ってるのは知っていたけど使ったのは初めて。すごい良いね。
一回ページ読み込んだ後はクライアントサイドで画面遷移するから動作がめちゃくちゃ速い。DEVみたい。
ローカルのプレビューもサクサク動くしちゃんと保存する度に更新されるし。
Gatsby Cloudいい感じ
最初GitHubからNetlifyとかに連携してデプロイするつもりでいたら公式でGatsby Cloudというマネージドホスティングを始めていたのを発見。
公式サイトからGitHubアカウントと連携→テンプレート選択とポチポチ進めるだけでサイトがデプロイされてしまった。
あとはローカルで編集したのをpushすればその度に自動でビルドが走ってデプロイまでされるみたい。超便利。
Pricingを見ると今のところ Free/$0 Professional/$50 Enterprise/$相談 の3パターンの料金体系がある。個人サイトならFreeでも十分そう。
大事な項目だけ抜粋するとこんな感じ↓
Free プラン
| 項目 | 制限 |
|---|---|
| 管理ユーザ数 | 1人 |
| 並列ビルド数 | 1並列 |
| コア数 | 1コア |
| メモリ | 1GB |
| ビルド回数/月 | 500回 |
| ビルド分/月 | 制限無し |
| デプロイ回数/日 | 制限無し |
| カスタムドメイン数 | 1個 |
| サイト数 | 5個 |
| 通信量/月 | 100GB |
| リクエスト数/月 | 100万 |
| Serverless Functions | 10万 |
| プレビュー | ○ |
| プレビューのパスワード制限 | × |
一ヶ月で100万リクエスト/100GBまでのトラフィックを捌けるカスタムドメインサイトが1つ持てるという感じ。
ビルドに使えるメモリが1GBというのは実際どんなもんなんだろうね。速度だけに影響するのか、プラグインや記事の数が増えるとビルド自体が成功しなくなるのか。
個人ブログとしては全然十分そうなのでしばらく使ってみるつもり。
何より結局自前のローカルでもビルド出来るから自分で別に用意した環境に移行するのも当たり前に可能というのが素晴らしいね。
ブログサービスみたいに完全ロックインされない。
料金表を見てたらServerless Functionsという項目があることに気が付いて調べてみるとまぁその名の通りサイトに動的なAPIを生やせる機能みたいだった。NEXT.JSのVercelにもあるやつ。
NEXTのAPI Routesもそうだけど、どんなに簡素でもいいからフレームワークなりプラットフォームなりが公式に推奨してるユースケースの範囲内で任意の処理を走らせられる機構があるのと無いのとでは取り回しの良さが段違いに変わってくるから嬉しいポイント。
最近のホスティングすごい
それにしてもVercel, Netlify, Firebase Hostingしかり最近のマネージドホスティング系のサービスはデフォルトでFastlyとかのめっちゃ速いCDNが前段に置かれててすごいね。
↓こんなん当たり前のように備えててありがたすぎじゃない？ドキュメント見てるだけでワクワクするねー。
- ほぼノーコンフィグで設定できるGitHub連携のビルド&デプロイフロー
- 爆速のCDN
- 簡易なサーバサイド処理のフルマネージド実行環境
- コンテナベースのプレビュー/ロールバック可能なデプロイ管理
- 小規模の利用なら十分な内容の無料プラン
今はまだ実験的なものだけど最近動的な処理をCDNのエッジノードにのせられる系のサービスもあるよね。
多分今後はそんなんも当たり前のように備わるようになって、可能な限りアプリケーションサーバに到達するリクエストを減らしていく方向の構造が主流になっていきそう。
ちょっと前に出たNEXTと同じReactベースのフレームワークのRemixもそんな思想だよね。
NEXTがコンテンツの静的なキャッシュの生成/配信の管理を中央のアプリケーションサーバで行うことを前提にしているのに対してRemixは動的なコンテンツの生成自体を出来るだけエッジに寄せた上でキャッシュまわりはCDNに全面的に頼るという。
「実際本格的なWebサービスってほぼほぼリアルタイムでSSRが必要なケースがかなり多いよね、だからやっぱそれは前提にした上でパフォーマンスも開発効率もめっちゃ良くなるみたいなアーキテクチャがみんな欲しいんじゃない？」というRemixの主張は確かにそうです感がすごいある。
他にもNEXTで開発してるとSSRを前提にしてる部分としてない部分のコンテキストの違いがちょっと混乱しやすいなというか、そこらへんの機構についてしっかり理解した上でNEXTの動作仕様に習熟していないと多分わけわかんなくなっちゃうんだろうなと思うことが多々あって。
Remixみたいにクラサバベースでサーバが常に動的にレスポンスを返すのが前提だとメンタルモデル的にも開発者がとっつきやすいというのはありそうだよね。
むしろ個人的にはそれが主な理由で流行ることもありそうと思ってる。公式サイトもオシャレでかっこいいし。
ブログを開設したという話から逸れまくったけど、そういう感じでこれからもどんどん色々進化していってまた今後数年でガラッと環境変わってくんだろうなと思うと楽しみだね。
楽しみながら色々思ったこととか感じたこととか雑にまとめていけたらいいなと思う。
Webは本当に楽しいな。