blog.unresolved.xyz
Sun Jul 12 2020

ブログをGatsbyJSからNext.jsへ変更した

  • JavaScript
  • Ruby on Rails
  • Next.js
ブログをGatsbyJSからNext.jsへ変更した

もうGatsbyJSはずーーーっと嫌だったんだけど、先週ついに限界が来ておらーーーーーーーーっと一気に置き換えることにした。

構成

ものすごい昔このブログはHugo + ローカルのMarkdownで運営してたんだけど、ローカルのMarkdownを編集するのがつらくてContentfulへ移行した経緯があって、以下みたいな感じになってた。

As-Is

  • コンテンツ管理: contentful
  • ホスティング: Netlify
  • ビルド: GatsbyJS

Netlify、ホスティングサービスとしてはめっちゃいいんだけどdependabotとかで依存性ガンガン回してるとビルドの上限行っちゃったりしてちょっと嫌だな感を持ってた。

特にGatsbyJSは依存性が増えすぎる傾向があるからなおさらそのデメリットを大きく感じてたように思う。

To-Be

  • コンテンツ管理: contentful
  • ホスティング: Vercel
  • ビルド: Next.js

こんな感じでNext.jsのStatic Optimizationを利用してビルドしてる。ちなみにホスティングもNext.jsにあわせてVercelに移行した。

もうNetlifyを使ってるのはポートフォリオだけなので、この際ポートフォリオもVercelに移行しようかなって気持ちが出てきてる。中身はNext.jsだし。

contentfulも正直API設計とかがそんなに好みではなくて、GraphCMSとかのほうが良かったのかもなあという気持ちはある。

けどこの移行コストはものすごく高いので一旦はやらなかった。GraphCMSに移行しても同じ問題を抱える可能性は捨てきれなかったし。

最近の個人開発とNext.js

最近はブログやポートフォリオを含めて個人でメンテしてるPJが4つほどNext.jsで動いてて、ようやくRailsからの脱却が本格的にできてきたなあという気持ちがある。

Next.jsはAPIエントリポイントがでたときに「え〜そんなフルスタックになっちゃうの?」って気持ちがあった。

ただよく考えてみたらRailsに対して抱いてたフルスタックの嫌悪感は「フロントエンドの描画をコントローラに依存して行ってる」ところだったので、Next.jsみたいにレンダリングがReactでできていて、バックエンドとの疎通をAjaxで行える(SPAを維持できる)のであればAPIエントリポイントは問題にはならないなっていう結論に行き着いた。

あとAPIエントリポイントがあるとプロキシとしても使えるので、バックエンドサーバを隠蔽することもできるし、HTTPヘッダにAuthorizationを埋め込んだりってこともできるのでめちゃくちゃ便利に使えてる。

Railsは1PJでGraphQL APIとして使ってるんだけど、正直これもTSで書いたほうが書きやすいのでそのうち捨てそうだなあという感じ。

慣れてるから書きやすいっていうのはあるし、何でも揃ってるから楽ではあるんだけど、やっぱりその分融通がきかなかったりはするので今後もRails脱却は進めていきたいところ。

Author
Daisuke Tsuji

Daisuke Tsuji

フリーのWeb Developer。

RubyとかRailsを触ってる時間が多い。コーディングもマークアップもライティングもデザインもSEOもやるタイプ。

だいたいどれもだめ。業務委託のお仕事募集中。