Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

LaravelのフロントエンドをNext.jsに段階的に移行している話

Takatoku
February 28, 2024
2.7k

 LaravelのフロントエンドをNext.jsに段階的に移行している話

Takatoku

February 28, 2024
Tweet

Transcript

  1. たかとく(松本拓人) 所属 出身 趣味 最近の関心ごと 技術スタック 株式会社じげん エンジニア 栃木 マンガ、アニメ、サウナ、ジム

    web アクセシビリティ、hono PHP(Laravel) 、TypeScript 、 React/Next.js 、 @takatoku_learn 年齢 25( エンジニア歴3 年) 自己紹介
  2. コード品質の低さによる可読性と拡張性の低下 デザインの統一感がない エラーやバグの検知が遅い 不必要なライブラリ・モジュールの読み込み フロントエンド起因のビルド時間増加 品質維持の仕組みを導入しにくい 多様なフロントエンド要求に対応できない リファクタリング js フレームワーク(vue)

    の拡充 フロントエンドを切り出し新しいフレームワーク導入 SEO に対して弱くなる懸念 vue2→vue3 へのアプデート大変 時間はかかるが、フロントエンド分離を選択 なぜ移行するのか 旧来のリショップナビのフロントエンド環境の問題点 解決手段として
  3. 段階的な移行 フロントエンド移行はTop ページから 段階的に始めた 全体の移行には時間がかかりすぎる 開発者の負担的にも、事業リスク的にもビックリラ イトは非現実的 定期的に成果を出せた方がビジネス側を説得しやす い top

    ページから段階的に始めることで、複雑なペー ジはナレッジが溜まってきてから取り組むことがで きる top ページはサイトの顔であるためデザインの方向 性を決めやすい
  4. 選定理由 Next.js を選んだ理由 コミュニティの信頼度が高い 後方互換性が意識されたバージョンアップ 情報量が多い 導入事例も豊富で詰まったときにも大体情報がある ライブラリが豊富 react 界隈のライブラリを使える

    技術的な選択肢の幅が多い パフォーマンスのチューニングもある程度選択肢がある レンダリング方法、キャッシュ、etc... 人数が少なくても開発、追従が可能 全てカスタムで選定、実装すると属人化やバージョンア ップがしんどい 前提 フロントエンド専門チームはな く、ある程度フルスタックにエ ンジニアが活動している C 向けのサービスなので、SEO 対策を意識した実装が必要
  5. 候補に上がったフレー ムワーク vue(Nuxt) Remix Svelte Preact webComponent 系 コミュニティ信頼度の問題 バージョンアップによる後方互換の不安

    利用率が低いフレームワークだと経験者採 用が難しい 情報量が少なく、詰まった場合に解決に時 間がかかる 管理するべきライブラリが増えることによ り、フロントエンドに時間が取られる 候補に上がったフレームワーク 採用されなかった理由
  6. 移行してみて 残念だったこと vercel 上で動かさないとNext.js のフルパワーは出せない 新しくstable になった機能でもnode.js 上で動くのか心配 Next.js(vercel) に依存しすぎてしまう

    キャッチアップコストが高い 複雑なフレームワーク仕様や独自コンポーネント、fetch api のラップ、キャッシュの罠など覚え るべき事項が多い 技術の進化が早すぎる 周辺ライブラリが追従してない場合がある 不安定なフレームワーク挙動 ベストプラクティスの変化が激しい
  7. 【SP 】 リリース前 リリース後 Performance 87 96 FCP 1.2s 1.3s

    LCP 3.7s 2.5s TBT 120ms 90ms CLS 0 0 Speed Index 3.8s 2.2s Accessibility 85 96 BestPractice 92 95 SEO 83 98 【PC 】 リリース前 リリース後 Performance 89 100 FCP 0.5s 0.4s LCP 1.4s 0.5s TBT 0ms 0ms CLS 0 0 Speed Index 0.8s 0.6s Accessibility 83 96 BestPractice 83 100 SEO 83 100 現在の姿 リリース前後でlight-house スコアが上昇 * リリース当時のスコア
  8. 現在の姿 Next.js 独自コンポーネントをラップするなどして変化に強い設計に(third party ライブラリも同様) コンポーネント分類にatomic design の採用をやめ、独自のルールを採用 (feature ディレクトリに近いものを導入)←

    近いうちにまとめて記事にするかも 状態管理にはContext API を使用 バックエンドとの通信にopen api 、コード自動生成にorval を使う server action を使うかどうか悩み中