Monolith から Monorepo へ: Next.js 移行ストーリー

VS Code の白いカーソルは静かに点滅しましたが、型のヒントは表示されませんでした。同僚のイライラしたため息が Slack 通話に響きました。彼の古いマシンはついに TypeScript の提案を完全に諦めていました。 Next.js アプリケーションを構築して 1 年後、私たちは恐れていた壁にぶつかりました。モノリシックなコードベースが快適にするには大きすぎたということです。

モノリシックな始まり

このプロジェクトを最初に始めたとき、Next.js は完璧な選択のように思えました。 React Router と Express を使用したプレーンな React SPA の背景、さらには PHP の以前の経験から、サーバー コードとクライアント コードを同じ場所に配置するというアイデアは直感的に感じられました。従来の通念に従い、技術的な懸念事項ではなく機能別にコードを整理しました。認証、プロスペクト、アカウント、チーム機能 – それぞれが独自のモジュール内に存在し、独自の型、ユーティリティ、定数、およびサーバー側コードを備えています。

「最初は美しかった」と最初の数か月間、私は思ったのを覚えています。アカウント モジュールで作業するということは、コンポーネント、フック、tRPC 関数、さらには Prisma ファイルなど、必要なものがすべて 1 つのフォルダー内にあることを意味します。それは私がずっと望んでいた開発者エクスペリエンスでした。

亀裂が目立ち始める

7 か月後、最初の危険信号が現れました。 TypeScript の言語サーバーは問題を抱え始め、提案が表示されるのがますます遅くなり、ビルド時間が徐々に増加しました。私の強力な開発マシンはまだそれを処理できましたが、同僚の古いハードウェアはその複雑さに完全に屈服しました。

私たちは、問題に資金を投入するか、問題を適切に解決するためにエンジニアリング時間を投資するかという古典的なエンジニアリングの岐路に直面しました。確かに、ハードウェアをアップグレードすることはできます。TypeScript のパフォーマンスは開発にのみ影響し、運用環境には影響しません。しかし、その解決策には何か絆創膏のようなものを感じました。私たちは、Turborepo を使用してモノリスをモノリポジトリにリファクタリングするという、より困難な道を選択しました。

移行の旅

最初のステップは驚くほど簡単で、コードを分割せずに構造を移行しました。 Web アプリを含む apps フォルダーを作成し、ESLint と TypeScript 構成用の 2 つの標準 Turborepo パッケージを追加しました。しかし、実際のテストは、型推論を維持しながらコア機能を移動することになります。

私はデータベース層から始めて、すべての Prisma 関連のコードを独自のパッケージに移動しました。 package.json エクスポートの調整をいくつか行った後、私は息を止めてメイン アプリの型を確認しました。それらは完璧に機能しました。さらに良いことに、同僚が変更をプルしたところ、数週間ぶりに IntelliSense の提案を受け取りました。私たちは何かを掴んでいました。

次に、tRPC が登場しました。これは論理的であるように思えました。これは、サーバー側の機能のもう 1 つの自己完結型です。しかし、ここからが興味深いことになります。 「tRPC を移動するだけ」として始まったものが、一連の予期せぬ依存関係に連鎖していきました。

• 私が構築した統合ライブラリ
• MJML と React テンプレートで構築されたメーラー システム
• Trigger.dev ワークフローは v2 と v3 に分割されます

学んだ教訓

この移行により、アーキテクチャと開発の実践についていくつかの重要な教訓が得られました。

1. サーバーとクライアントの分離は重要です: Next.js を使用するとサーバー コードとクライアント コードを簡単に混合できますが、その利便性がアーキテクチャを乱雑にする可能性があります。影響について考えずに、型と定数を境界を越えてインポートしていることに気づきました。

2. Monorepo から始める: もし今日もう一度始めるとしたら、初日から Turborepo から始めるでしょう。これにより、複雑さが最小限に抑えられ、依存関係とアーキテクチャについて健全な方法で考えることが求められます。

3. 明示的な依存関係はより良い: モノリスを解体することで、依存関係を視覚化し、疑問を持たざるを得なくなりました。これらの接続は必要ですか?循環依存関係を作成していませんか?これらの制約により、私たちはより適切なアーキテクチャ上の決定を行うことができました。

これからの道

移行はまだ完了していません。サーバー コードと共有ユーティリティは引き続き適切に構成する必要があり、tRPC レイヤーとデータベース レイヤーが別々に存在するため、モジュール構造を再考しています。しかし、すでに私たちの開発エクスペリエンスは劇的に向上しています。

拡張性のある Next.js アプリケーションを構築している人は、モノリポジトリ構造から始めることを検討してください。初期投資は最小限ですが、それによって提供される建築上のガードレールは非常に貴重です。将来のあなた、そしてあなたのチームの古いラップトップはあなたに感謝するでしょう。

以上がMonolith から Monorepo へ: Next.js 移行ストーリーの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。