Senarai Semak Produksi Praktikal untuk Next.js 16 App Router

App Router dalam Next.js merupakan satu anjakan paradigma berbanding Pages Router. Ia memperkenalkan ciri-ciri hebat seperti Komponen Server dan caching terperinci, tetapi ini juga datang dengan kerumitan baharu. Membawa aplikasi dari persekitaran pembangunan lokal ke produksi yang stabil di Vercel memerlukan satu set semakan dan pertimbangan yang berbeza.

Di JRV Systems, kami membina sistem kompleks untuk perniagaan di Malaysia, daripada platform e-dagang sehinggalah SaaS pengurusan klinik. Kami telah membantu beberapa klien melalui transisi ini. Artikel ini adalah senarai semak produksi Next.js 16 kami yang padat dan praktikal, memfokuskan pada perkara yang benar-benar penting sebelum anda 'go live'.

Senarai Semak Produksi Next.js 16 Anda

Sebelum 'deploy', semak semula bahagian-bahagian teras ini. Ia mewakili titik kegagalan atau degradasi prestasi yang paling kerap kami lihat apabila memindahkan projek App Router ke persekitaran produksi.

• Strategi Komponen: Sudahkah anda tentukan secara eksplisit komponen mana yang merupakan Komponen Server dan yang mana Komponen Klien? Pilihan lalainya ialah Server.
• Caching dan Pengambilan Data: Adakah anda sengaja menggunakan caching fetch yang baharu, atau adakah anda telah memilih untuk tidak menggunakannya di mana perlu? Halaman statik boleh menjadi dinamik secara tidak sengaja.
• Logik Revalidation: Jika anda menggunakan Incremental Static Regeneration (ISR), adakah logik 'revalidation on-demand' melalui webhook atau laluan (path) anda dikonfigurasi dan dijamin selamat dengan betul?
• Pembolehubah Persekitaran (Environment Variables): Adakah semua pembolehubah untuk server dan klien dikonfigurasi dengan betul dalam tetapan projek Vercel anda? Ingat awalan NEXT_PUBLIC_ untuk pembolehubah di sisi klien.
• Pengendalian Ralat dan Log: Sudahkah anda menyediakan fail error.js dan global-error.js untuk mengendalikan ralat runtime dengan baik? Adakah perkhidmatan log seperti Vercel Logs atau alat pihak ketiga telah diintegrasikan?
• Analisis Saiz Bundle: Pernahkah anda menggunakan @next/bundle-analyzer untuk memeriksa saiz bundle JavaScript di sisi klien yang besar secara tidak dijangka? Komponen Klien yang besar boleh melambatkan laman web anda.

Komponen Server vs. Klien: Keputusan Teras

App Router mengutamakan server ('server-first'). Setiap komponen adalah React Server Component (RSC) secara lalai. Ini sangat baik untuk prestasi, kerana ia mengurangkan jumlah JavaScript yang dihantar ke pelayar. Walau bagaimanapun, sebarang interaktiviti memerlukan Komponen Klien.

Peraturannya mudah: jika komponen anda menggunakan 'hooks' seperti useState, useEffect, atau useContext, atau bergantung pada API khusus pelayar dan 'event listeners' (onClick, onChange), anda mesti menandakannya dengan arahan "use client" di bahagian atas fail.

Kesilapan biasa adalah menjadikan komponen 'layout' yang besar sebagai Komponen Klien sedangkan hanya sebahagian kecil daripadanya yang interaktif. Amalan terbaik adalah untuk mengekalkan komponen di server sebanyak mungkin. Asingkan interaktiviti ke dalam Komponen Klien yang lebih kecil dan spesifik. Sebagai contoh, halaman produk boleh menjadi Komponen Server yang mengambil data, manakala butang 'Tambah ke Troli' di dalamnya adalah Komponen Klien yang kecil dan serba lengkap.

Memahami Lalai Caching Baharu

Ini adalah salah satu perubahan terbesar berbanding Pages Router. Dalam App Router, panggilan kepada fetch akan disimpan dalam 'cache' secara automatik dan kekal secara lalai. Ini sangat berkuasa untuk kandungan statik tetapi boleh menyebabkan masalah besar jika anda menjangkakan data yang sentiasa segar.

Jika anda mengambil data yang berubah-ubah, anda mesti menyatakan strategi caching:

• Revalidation Berasaskan Masa (ISR): Untuk mengambil data baharu secara berkala, gunakan opsyen next.revalidate. Ini memberitahu Next.js untuk menyimpan hasil dalam cache untuk bilangan saat yang tertentu. fetch('https://api.example.com/data', { next: { revalidate: 3600 } }) // 'Revalidate' setiap jam

• Memilih untuk Tidak Menggunakan Cache: Untuk data yang mesti sentiasa segar (contohnya, maklumat sesi pengguna, paras stok), anda mesti mematikan caching secara eksplisit. fetch('https://api.example.com/data', { cache: 'no-store' })

Terlupa menetapkan cache: 'no-store' untuk data dinamik adalah punca pepijat yang kerap kami selesaikan untuk klien yang melancarkan laman e-dagang baharu. Harga produk atau paras stok kelihatan lapuk sehinggalah 'deployment' seterusnya membersihkan cache.

Melaksanakan Revalidation Atas Permintaan (On-Demand)

'Revalidation' berasaskan masa amat berguna, tetapi selalunya anda mahu mengemas kini halaman serta-merta apabila datanya berubah. Inilah yang dipanggil ISR 'on-demand'. Contohnya, apabila sebuah klinik mengemas kini jadual doktor dalam papan pemuka SaaS mereka, anda mahu halaman jadual awam memaparkan perubahan itu dengan segera.

Ini dicapai menggunakan dua pendekatan utama:

1. Revalidation Berasaskan Tag: Anda boleh 'menanda' permintaan fetch tertentu dengan satu rentetan teks (tag). Kemudian, anda boleh memanggil satu laluan API atau Server Action yang menggunakan fungsi revalidateTag('nama-tag') untuk membatalkan semua 'fetch' yang berkaitan dengan tag tersebut.
2. Revalidation Berasaskan Laluan (Path): Jika anda mahu 'revalidate' satu laluan URL tertentu, anda boleh menggunakan revalidatePath('/slug-halaman-anda').

Untuk melindunginya, 'endpoint' revalidation ini biasanya adalah webhook yang dilindungi oleh token rahsia. Sistem CMS atau backend anda akan memanggil webhook ini selepas data dikemas kini, menghantar token rahsia untuk mencetuskan 'revalidation' pada aplikasi Next.js anda.

4 Isu Produksi Lazim yang Telah Kami Selesaikan

Berdasarkan pengalaman kami di JRV Systems, empat isu ini sering muncul apabila pasukan melancarkan projek App Router pertama mereka.

1. Versi Node.js Tidak Sepadan: Projek berfungsi dengan sempurna pada mesin pembangun yang menggunakan Node.js 20 tetapi gagal di Vercel, yang mungkin menyasarkan Node.js 18. Sentiasa nyatakan versi Node.js yang tepat dalam fail package.json anda di bawah medan engines dan konfigurasikannya dalam tetapan projek Vercel untuk memastikan konsistensi.

2. Pengendalian 'Environment Variable' yang Tidak Betul: Pembangun terlupa menambah NEXT_PUBLIC_ pada kunci API yang perlu diakses dalam pelayar. Di Vercel, pembolehubah ini akan menjadi undefined di sisi klien, menyebabkan ciri-ciri tertentu rosak. Pengasingan yang jelas antara pembolehubah server (process.env.DB_PASSWORD) dan klien (process.env.NEXT_PUBLIC_GA_ID) adalah amat penting.

3. Paparan Dinamik Secara Tidak Sengaja: Halaman yang sepatutnya statik (SSG) dipaparkan secara dinamik pada setiap permintaan. Ini sering berlaku apabila fungsi dinamik seperti cookies() atau headers() digunakan dalam komponen atau 'layout' yang mempengaruhi halaman tersebut. Ini menjejaskan prestasi dan meningkatkan kos. Gunakan log binaan Vercel untuk menyemak halaman mana yang dijana secara statik berbanding dinamik.

4. Kehabisan Sambungan Pangkalan Data: Dalam persekitaran 'serverless', setiap permintaan boleh memulakan 'instance' fungsi baharu, yang berpotensi mewujudkan sambungan pangkalan data baharu. Tanpa 'connection pooling' yang betul (menggunakan perkhidmatan seperti Neon atau PgBouncer dari Supabase), anda boleh menghabiskan had sambungan pangkalan data anda dengan cepat. Ini amat kritikal untuk aplikasi dengan trafik yang tidak menentu, seperti sistem pengebilan atau halaman promosi e-dagang.