Dari Monolith ke Monorepo: Kisah Migrasi Seterusnya.js

Kursor putih dalam Kod VS berkelip senyap, tetapi tiada petunjuk jenis muncul. Esakan kecewa rakan sekerja saya bergema melalui panggilan Slack kami – mesin lamanya akhirnya menyerah pada cadangan TypeScript sepenuhnya. Selepas setahun membina aplikasi Next.js kami, kami telah melanggar tembok yang saya takuti: pangkalan kod monolitik kami telah menjadi terlalu besar untuk keselesaan.

Permulaan Monolitik

Apabila saya mula-mula memulakan projek ini, Next.js kelihatan seperti pilihan yang tepat. Berasal dari latar belakang dalam SPA React biasa dengan Penghala Reaksi dan Ekspres – dan pengalaman lebih awal dengan PHP – idea untuk menyusun kod pelayan dan klien terasa intuitif. Mengikuti kebijaksanaan konvensional, kami menyusun kod kami mengikut fungsi dan bukannya masalah teknikal. Pengesahan, prospek, akaun, ciri pasukan – masing-masing hidup dalam modulnya sendiri, lengkap dengan jenis, utiliti, pemalar dan kod sisi pelayannya sendiri.

"Ia pada mulanya cantik," saya masih ingat terfikir semasa bulan-bulan awal itu. Mengusahakan modul akaun bermakna semua yang anda perlukan ada di sana - komponen, cangkuk, fungsi tRPC, malah fail Prisma - semuanya dalam satu folder. Ia adalah pengalaman pembangun yang saya inginkan.

Retak Mula Menunjukkan

Tujuh bulan kemudian, tanda amaran pertama muncul. Pelayan bahasa TypeScript mula bergelut, cadangan muncul lebih perlahan dan lebih perlahan, dan masa binaan merangkak ke atas. Walaupun mesin pembangunan berkuasa saya masih boleh mengendalikannya, perkakasan lama rakan sekerja saya menyerah sepenuhnya kepada kerumitan.

Kami menghadapi persimpangan kejuruteraan klasik: buang wang pada masalah itu atau laburkan masa kejuruteraan untuk menyelesaikannya dengan betul. Sudah tentu, kami boleh meningkatkan perkakasan kami - prestasi TypeScript hanya memberi kesan kepada pembangunan, bukan pengeluaran. Tetapi sesuatu tentang penyelesaian itu terasa seperti bantuan band. Kami memilih jalan yang lebih sukar: memfaktorkan semula monolit kami menjadi monorepo menggunakan Turborepo.

Perjalanan Migrasi

Langkah pertama adalah sangat mudah - pindahkan struktur tanpa membelah sebarang kod. Saya mencipta folder apl yang mengandungi apl web kami dan menambah dua pakej Turborepo standard untuk konfigurasi ESLint dan TypeScript. Tetapi ujian sebenar akan menggerakkan fungsi teras kami sambil mengekalkan inferens jenis.

Saya bermula dengan lapisan pangkalan data kami, memindahkan semua kod berkaitan Prisma ke dalam pakejnya sendiri. Selepas beberapa tweak eksport package.json, saya menahan nafas dan menyemak jenis dalam apl utama kami. Mereka bekerja dengan sempurna. Lebih baik lagi, apabila rakan sekerja saya membuat perubahan, dia mendapat cadangan IntelliSense buat kali pertama dalam beberapa minggu. Kami sedang melakukan sesuatu.

Seterusnya ialah tRPC, yang nampaknya logik – satu lagi fungsi bahagian pelayan serba lengkap. Tetapi di sinilah perkara menjadi menarik. Perkara yang bermula sebagai "hanya memindahkan tRPC" melantun ke dalam satu siri kebergantungan yang tidak dijangka:

• Perpustakaan integrasi yang saya bina
• Sistem mel dibina dengan templat MJML dan React
• Aliran kerja Trigger.dev berpecah antara v2 dan v3

Pengajaran yang Diperoleh

Penghijrahan ini mengajar saya beberapa pelajaran penting tentang seni bina dan amalan pembangunan:

1. Perkara Pemisahan Pelayan-Pelanggan: Walaupun Next.js memudahkan untuk mencampurkan kod pelayan dan pelanggan, kemudahan itu boleh membawa kepada seni bina yang tidak kemas. Saya mendapati diri saya mengimport jenis dan pemalar merentasi sempadan tanpa memikirkan implikasinya.

2. Mulakan Dengan Monorepo: Jika saya bermula semula hari ini, saya akan mulakan dengan Turborepo dari hari pertama. Ia menambahkan kerumitan minimum sambil memaksa anda untuk memikirkan tentang kebergantungan dan seni bina dengan cara yang sihat.

3. Ketergantungan Eksplisit Lebih Baik: Memecahkan monolit memaksa kami untuk memvisualisasikan dan mempersoalkan hubungan pergantungan kami. Adakah sambungan ini perlu? Adakah kita telah mencipta kebergantungan bulat? Kekangan ini mendorong kami ke arah keputusan seni bina yang lebih baik.

Jalan Hadapan

Penghijrahan masih belum selesai. Kod pelayan dan utiliti kongsi kami masih memerlukan organisasi yang betul, dan kami sedang memikirkan semula struktur modul kami sekarang kerana tRPC dan lapisan pangkalan data hidup secara berasingan. Tetapi sudah, pengalaman pembangunan kami telah meningkat secara mendadak.

Bagi sesiapa yang membina aplikasi Next.js yang mungkin berskala, pertimbangkan untuk memulakan dengan struktur monorepo. Pelaburan awal adalah minimum, tetapi pagar seni bina yang disediakannya tidak ternilai. Diri masa depan anda – dan komputer riba lama pasukan anda – akan berterima kasih kepada anda.

Atas ialah kandungan terperinci Dari Monolith ke Monorepo: Kisah Migrasi Seterusnya.js. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!