makedream
36:54Vercel
Log in to leave a comment
No posts yet
Mesin Nitro milik Nuxt mungkin terlihat berjalan dengan baik di mana saja, tetapi ceritanya berubah saat diunggah ke Vercel Edge Runtime. Alasan mengapa pustaka seperti sharp atau bcrypt, yang berjalan normal di lokal, segera mengeluarkan error 500 setelah penerapan (deployment) adalah karena Vercel Edge memblokir akses ke modul standar Node.js. Saya selalu menjalankan npx vercel build sebelum menekan tombol deploy. Jika Anda tidak mensimulasikan lingkungan berbasis Linux terlebih dahulu, kemungkinan besar Anda akan bergelut dengan runtime error pada jam 3 pagi.
Jika Anda menginginkan operasional yang stabil, lebih aman untuk menentukan preset sebagai vercel biasa daripada vercel-edge di nuxt.config.ts. Tidak semua API perlu dijalankan di Edge. Jangan memanggil variabel lingkungan secara langsung melalui process.env, melainkan standarisasikan dengan useRuntimeConfig milik Nitro. Kebiasaan kecil ini akan menghilangkan 80% runtime error yang terjadi setelah deployment.
Penyebab utama tagihan Vercel yang membengkak adalah waktu eksekusi dan jumlah pemanggilan fungsi serverless. routeRules yang disediakan di Nitro 3 adalah alat paling ampuh untuk memangkas biaya ini secara fisik. Jika Anda menggunakan strategi stale-while-revalidate (SWR) dengan benar, meskipun ada 10.000 permintaan API yang masuk, eksekusi fungsi yang sebenarnya hanya akan terjadi satu kali. Ini adalah cara cerdas untuk memberikan respons cepat dalam hitungan milidetik kepada pengguna sekaligus menjaga dompet Anda.
Berikut adalah pengaturan spesifik untuk mengurangi biaya lebih dari 40%:
routeRules di nuxt.config.ts.swr: 3600 pada jalur tersebut untuk mengaktifkan mode pembaruan latar belakang selama 1 jam.maxAge dan staleMaxAge di dalam opsi cache.Dengan cara ini, Anda akan melihat jumlah pemanggilan fungsi serverless di dashboard Vercel turun secara drastis.
Kesalahan hidrasi (hydration error) yang terjadi saat HTML yang dibuat server bertemu dengan JavaScript di sisi klien membuat aplikasi menjadi tidak stabil. Nuxt 4 dirancang untuk menggunakan deep: false sebagai nilai default saat memanggil useAsyncData untuk mengatasi hal ini. Dengan mengorbankan pelacakan objek yang tidak perlu, memori dapat dihemat dan status server dapat dikirimkan ke klien dengan aman.
Terapkan tiga aturan berikut untuk menangani ketidakkonsistenan data dan mengurangi ukuran payload:
pick saat memanggil API untuk memilih hanya nilai kunci yang benar-benar diperlukan untuk rendering template. Ini saja dapat mengurangi ukuran payload hingga 50%.useId() di tempat yang memerlukan ID unik untuk mencocokkan pengidentifikasi antara server dan klien.<NuxtTime> untuk menanganinya berdasarkan lokal browser.Seiring berkembangnya proyek, memori 8.192MB yang disediakan oleh wadah build Vercel terkadang tidak mencukupi. Tepatnya, ukuran heap default Node.js diatur lebih kecil dari memori yang tersedia, sehingga pengumpulan sampah (garbage collection) menjadi sering terjadi dan akhirnya proses build terhenti.
Untuk meningkatkan kecepatan build dan mencegah kegagalan deployment, segera terapkan pengaturan berikut:
NODE_OPTIONS="--max-old-space-size=4096" ke variabel lingkungan proyek Vercel. Menghilangkan batasan memori heap saja sudah cukup untuk menghilangkan hambatan (bottleneck) pada proses build.npx nuxt analyze untuk memastikan ketergantungan khusus server yang berat tidak tercampur dalam bundel klien, dan isolasi dengan alias #server.server/middleware/, yang dijalankan pada setiap permintaan, ke dalam event handler jalur tertentu.Setelah menyelesaikan konfigurasi lingkungan ini, waktu tunggu pipa CI/CD akan dipersingkat dan tingkat kegagalan deployment akan berkurang secara signifikan.