GatsbyJSにはずっと不満を感じていたのですが、先週ついに限界が来て、一気に置き換えることにしました。
かなり昔、このブログはHugo + ローカルのMarkdownで運営していたのですが、ローカルのMarkdownを編集するのが大変でContentfulへ移行した経緯があり、以下のような構成になっていました。
Netlifyはホスティングサービスとしてはとても良いのですが、dependabotなどで依存性を頻繁に更新しているとビルドの上限に達してしまうことがあり、少し不便に感じていました。
特にGatsbyJSは依存性が増えすぎる傾向があるため、なおさらそのデメリットを大きく感じていたように思います。
このような構成で、Next.jsのStatic Optimizationを利用してビルドしています。ホスティングもNext.jsにあわせてVercelに移行しました。
Netlifyを使っているのはもうポートフォリオだけなので、この際ポートフォリオもVercelに移行しようかという気持ちが出てきています。中身はNext.jsですし。
contentfulも正直なところAPI設計がそれほど好みではなく、GraphCMSなどのほうが良かったのかもしれないという気持ちはあります。
ただ、この移行コストは非常に高いので一旦は見送りました。GraphCMSに移行しても同じ問題を抱える可能性は捨てきれませんでしたし。
最近はブログやポートフォリオを含めて個人でメンテしているプロジェクトが4つほどNext.jsで動いており、ようやくRailsからの脱却が本格的にできてきたなという気持ちがあります。
Next.jsはAPIエントリポイントが出たときに「そんなフルスタックになってしまうのか」という気持ちがありました。
ただ、よく考えてみるとRailsに対して抱いていたフルスタックへの嫌悪感は「フロントエンドの描画をコントローラに依存して行っている」ところだったので、Next.jsのようにレンダリングがReactでできていて、バックエンドとの疎通をAjaxで行える（SPAを維持できる）のであれば、APIエントリポイントは問題にはならないという結論に行き着きました。
またAPIエントリポイントがあるとプロキシとしても使えるので、バックエンドサーバを隠蔽することもできますし、HTTPヘッダにAuthorizationを埋め込むこともできるので、非常に便利に使えています。
Railsは1プロジェクトでGraphQL APIとして使っているのですが、正直これもTypeScriptで書いたほうが書きやすいので、そのうち移行しそうだなという感じです。
慣れているから書きやすいというのはありますし、何でも揃っているから楽ではあるのですが、やはりその分融通がきかなかったりするので、今後もRails脱却は進めていきたいところです。
blog.unresolved.xyz