もくじ
ADR 3 : かどで日記のフロントエンドとバックエンドの分離
Status :🟢 承認
Context
現状サーバーサイドで PHP を用いてレンダリングしている。 Next.js を導入することで SPA 化を行うことで、より早く、よりリッチな UI を実現する。
Decision
かどで日記のフロントエンドとバックエンドを分離する。 用いる技術は Next.js。
理由としては技術が安定してきており、企業での採用事例も増えているため。
もともと意図的にフロントエンドとバックエンドを分離してきた。 これは長期的な管理のコストを減らすためであり、この事自体は目標を 1 年半にわたり果たしている。 一方でこの状態から抜け出せない原因にもなっており、技術の停滞化を招いている。
また速度面からも DOM 操作で管理するモダンフロントエンドを使いたい節がある。
Consequences
Pros
- 今後フロントエンドの付け替えが容易になる
- フロントエンドとバックエンドの開発が分離できる
- アプリ対応などが容易になる
- DOM 操作になるため、通信量を節約できる
- View 側にビジネスロジックを書いている現状を改善できる
Cons
- 開発工数増える
- 相当な大改修が必要
- 認証周りが面倒
- Vercel 使わないことでの機能制限(ISR の難しさなど)
Notes
なぜ Next.js なのか
- React 単体では扱いにくい諸々を解決してくれている
- 昨今利用事例が増え、情報を得やすい
- 企業での導入も増えており、安定し始めている
- 少なからず利用経験がある
- MIT ライセンスである
Vercel には依存したくないので、Next.js を他のところで動かしたいが、やはり Vercel に最適化された FW。
Deno を使う手もあるが、まだ成熟していない感が否めない。 もうちょっと枯れた技術を使いたい
レンダリングは CSR がよいかも。殆どのページが個々人しか見ない上、頻繁に見るものではないため、キャッシュ周りの効果薄い。
トップページとかは SSG でいいかも。
なぜ今なのか
- リファクタリングなどが少し進んで見通しがたった
- 最適なドメインを入手できたので、URL 変更のタイミングでフロントまで変えたい
- UI 部分の変更をするタイミングで移行することで複製する手間を省ける
- かどで日記の開発が停滞しているため、破壊的な変更を設けることで強制的に開発速度を上げたい
References
https://github.com/KadodeProject/kadode_nikki3/issues/336