Apakah yang Diselesaikan oleh Fluid Compute
Vercel Fluid Compute yang mencapai GA pada 2025 ialah infrastruktur pelaksanaan generasi baharu yang menyatukan runtime yang sebelum ini dibahagikan kepada "Serverless Functions" dan "Edge Functions". Serverless konvensional memerlukan caj idle yang berat kerana model "1 permintaan = 1 bekas", manakala Edge Functions terbeban dengan had saiz kod 50MB dan kekangan keserasian Node.js. Fluid Compute menggunakan model "multi-tenant concurrency" di mana satu instans memproses berbilang permintaan secara selari, dan mengeluarkan masa menunggu I/O daripada skop caj. Hasilnya, sifat yang dahulunya merupakan pertukaran ganti — mendapatkan kependaman hampir tepi sambil mengekalkan sambungan DB — kini boleh dicapai serentak.
Sehingga April 2026, pilihan runtime dalam next.config.ts ialah tiga pilihan: "nodejs" / "edge" / "fluid". Lalai Next.js 16 ialah "fluid", dan laluan di bawah /app berjalan di atas Fluid melainkan `export const runtime = "edge"` ditulis secara eksplisit. Edge Functions kini terhad kepada penggunaan seperti penamatan WebSocket dan API kependaman amat rendah, dan perbincangan pemilihan konvensional "edge atau Lambda" telah beralih kepada "adakah Fluid mencukupi, atau adakah Edge diperlukan".
Rendering Tepi RSC Next.js 16
Next.js 16 kini boleh menjana output penstriman React Server Components (RSC) di PoP. Secara khusus, ia mengeluarkan HTML dan payload RSC secara tak segerak mengikut sempadan Suspense, memendekkan TTFB hingga sekitar 40ms. Yang penting ialah penempatan pengambilan data. RSC boleh menulis fetch yang selesai di sisi pelayan, tetapi peraturan tetapnya ialah mengelakkan sambungan langsung ke DB asal dan menyisipkan lapisan cache tepi seperti Vercel Data Cache (dahulu Request Memoization) atau Hyperdrive / PlanetScale Boost.
Terdapat kekangan pada RSC yang berjalan di Edge Runtime. `fs` / `net` / `child_process` Node.js tidak boleh digunakan, dan penyulitan melalui Web Crypto API. Dengan penyesuai edge-compatible yang ditambah pada akhir 2025, Prisma 6 dan Drizzle ORM berjalan terus, tetapi Sequelize dan TypeORM masih disyorkan menggunakan Fluid. Seni bina "RSC untuk Edge, penulisan DB untuk Fluid" adalah penyelesaian standard 2026.
```typescript // app/products/[id]/page.tsx export const runtime = "edge"; export const revalidate = 60; export default async function ProductPage({ params }: { params: Promise<{ id: string }> }) { const { id } = await params; const product = await fetch(`${process.env.EDGE_API}/products/${id}`, { next: { revalidate: 60, tags: [`product-${id}`] }, }).then((r) => r.json()); return ( <> <ProductHeader product={product} /> <Suspense fallback={<ReviewsSkeleton />}> <ProductReviews id={id} /> </Suspense> </> ); } ```
Streaming SSR dan Partial Prerendering (PPR)
PPR ialah ciri yang diperkenalkan secara eksperimen dalam Next.js 14, distabilkan pada versi 15, dan diaktifkan secara lalai pada versi 16, yang menghantar "kerangka statik + pengisian dinamik" dalam hibrid masa bina dan masa jalan. Ia segera mengembalikan kerangka HTML yang dijana pada masa bina dari PoP, sambil meninggalkan bahagian khusus pengguna (ikon troli, produk disyorkan) sebagai sempadan Suspense dan mengeluarkannya kemudian dari pelayan. Ini membolehkan kadar paduan CDN dikekalkan sambil mencapai pemperibadian.
Perangkap pelaksanaan ialah "saat merujuk `cookies()` atau `headers()`, seluruh pokok itu menjadi dinamik". Jika `headers()` dipanggil secara tidak sengaja dalam susun atur, kerangka statik PPR tidak akan dijana dan setiap kali akan direndahkan kepada SSR penuh. Log output `next build` harus diaudit secara berkala untuk nisbah "Static (prerendered)" dan "Dynamic (on-demand)", dan CI harus mengesan jika kadar statik menurun.
Edge Config dan Feature Flag Berasaskan CDN
Edge Config ialah "stor JSON yang dioptimumkan untuk bacaan" yang disediakan oleh Vercel, boleh dibaca dalam masa kurang dari 1ms dari Edge Runtime. Membina infrastruktur feature flag dalaman dengan Edge Config + Vercel Flags SDK tanpa menggunakan SaaS seperti LaunchDarkly atau Statsig kini menjadi penyelesaian praktikal 2026. Penulisan merambat ke semua rantau dalam beberapa saat melalui API pengurusan, dan bacaan tidak menimbulkan RTT rangkaian kerana tertanam dalam Isolate runtime.
Flags SDK mengendalikan ujian A/B dan penilaian bendera dengan API yang sama, dan menyelaraskan identiti antara RSC dan komponen klien. Secara khusus, ID pengguna ditetapkan dalam cookie oleh middleware, `flag("new-checkout").bucket(userId)` dinilai dalam RSC, dan hasilnya disebarkan kepada komponen anak sebagai searchParams. Ini membolehkan pengalaman seperti SPA di mana "varian yang ditentukan di sisi pelayan semasa akses pertama dikekalkan selepas navigasi" dilaksanakan sepenuhnya di tepi.
```typescript import { flag } from "@vercel/flags/next"; import { get } from "@vercel/edge-config"; export const newCheckout = flag<boolean>({ key: "new-checkout", async decide({ entities }) { const config = await get<{ rollout: number }>("new-checkout"); const userId = entities?.user?.id ?? "anon"; return hash(userId) % 100 < (config?.rollout ?? 0); }, }); ```
Had saiz Edge Config telah dikembangkan kepada 512KB/stor, hingga 10 stor/projek (akhir 2025). Secara praktikal, ia terutama digunakan untuk menyimpan nilai konfigurasi yang cukup dengan kemas kini dalam lingkungan beberapa saat hingga minit, seperti "definisi bendera", "jadual harga", dan "kata-kata yang dilarang mengikut rantau", dan tidak sesuai untuk data yang dikemas kini dengan kerap seperti profil pengguna. Bagi kes tersebut, KV atau Redis digunakan secara berasingan.
Kebolehmerhatian dan Sourcemap
Fluid Compute menyokong instrumentasi automatik OpenTelemetry sebagai standard, dan surih mengalir ke Datadog/Honeycomb/Grafana Cloud hanya dengan mengimport pakej `@vercel/otel`. Memanggil `fetch` dalam RSC secara automatik memotong span, dan Web Vitals (LCP/INP/CLS) diserap sebagai RUM dalam strim berasingan. Mulai 2026, Vercel Observability Plus membolehkan memuat naik sourcemap produksi dengan selamat dan menyelesaikan surih tindanan pada nombor baris TypeScript.
Operasi belanjawan ralat menentukan SLO dalam bahasa pertanyaan Vercel Monitoring (VQL) dan mengalirkan amaran kadar pembakaran ke Slack/PagerDuty adalah amalan standard. Menyusun kependaman p99 Edge Functions, invokasi serentak Fluid, dan kadar paduan Data Cache pada papan pemuka yang sama membolehkan pengesanan awal penurunan kadar statik PPR atau peningkatan kegagalan cache. Pertarungan tepi bukan sahaja tentang "kelajuan" tetapi juga "kelajuan yang tidak berubah".