Ano ang Nireresolba ng Fluid Compute
Ang Vercel Fluid Compute na naging GA sa 2025 ay isang bagong henerasyong execution platform na pinagsama ang mga runtime na dating hiwalay bilang "Serverless Functions" at "Edge Functions." Ang tradisyunal na serverless ay may mabigat na idle billing na "1 request = 1 container," at ang Edge Functions ay may 50MB na code size limit at Node.js compatibility constraint. Ang Fluid Compute ay gumagamit ng "multi-tenant concurrency" model kung saan ang iisang instance ay sabay-sabay na nagpoproseso ng maraming request, at inaalis ang I/O waiting time mula sa billing. Ang resulta ay nagiging posible ang pagsasabay ng mga katangiang dating trade-off — maaaring mapanatili ang DB connection habang nakukuha ang malapit-sa-edge na latency.
Sa Abril 2026, ang runtime option sa next.config.ts ay may tatlong pagpipilian: "nodejs" / "edge" / "fluid." Ang default ng Next.js 16 ay "fluid," at ang mga route sa ilalim ng /app ay tumatakbo sa Fluid maliban kung hayagang isinulat ang `export const runtime = "edge"`. Ang mga Edge Function ay lumipat na sa mas limitadong gamit tulad ng WebSocket termination at minimal-latency API, at ang dating debate ng "edge o Lambda" ay naging "sapat ba ang Fluid, o kailangan ba ng Edge."
RSC Edge Rendering ng Next.js 16
Sa Next.js 16, maaari na ngayong makabuo ng streaming output ng React Server Components (RSC) sa PoP. Partikular, asynchronously sino-flush ang HTML at RSC payload bawat Suspense boundary, na nagpapaikli ng TTFB hanggang mga 40ms. Ang susi ay ang placement ng data fetch. Maaaring magsulat ng server-side fetch sa RSC, pero ang direktang koneksyon sa origin DB ay dapat iwasan; ang pamantayan ay ang paglagay ng Vercel Data Cache (dating Request Memoization) o edge cache layer tulad ng Hyperdrive/PlanetScale Boost.
May mga limitasyon ang RSC na tumatakbo sa Edge Runtime. Hindi magagamit ang Node.js fs/net/child_process, at ang encryption ay sa pamamagitan ng Web Crypto API. Sa pamamagitan ng edge-compatible adapter na idinagdag noong katapusan ng 2025, ang Prisma 6 at Drizzle ORM ay gumagana nang walang pagbabago, pero ang Sequelize at TypeORM ay nananatiling inirerekomenda para sa Fluid. Ang architecture na "RSC para sa Edge, DB writes para sa Fluid" ay ang standard na solusyon ng 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 at Partial Prerendering (PPR)
Ang PPR ay isang feature na experimentally ipinakilala sa Next.js 14, naging stable sa 15, at naging enabled by default sa 16 — ito ay nagde-deliver ng "static shell + dynamic filling" sa isang hybrid ng build time at runtime. Agad na ibinabalik mula sa PoP ang HTML skeleton na nabuo sa build time, habang ang mga user-specific na bahagi (cart icon, recommended products) ay naiwan bilang Suspense boundaries at niflu-flush mula sa server pagkatapos. Nagbibigay-daan ito sa pagpapanatili ng CDN hit rate habang nagbibigay ng personalization.
Ang pitfall sa implementation ay ang "sa sandaling ma-reference ang cookies() o headers(), ang buong tree ay nagiging dynamic." Kapag walang ingat na tinawag ang headers() sa layout, hindi na mabubuo ang static shell ng PPR, at magda-downgrade sa full SSR bawat oras. Dapat regular na i-audit ang ratio ng "Static (prerendered)" at "Dynamic (on-demand)" sa output log ng `next build`, at dapat ma-detect ng CI kapag bumabagsak ang static rate.
Edge Config at CDN-Backed Feature Flag
Ang Edge Config ay isang "read-optimized JSON store" na ibinibigay ng Vercel at maaaring basahin sa loob ng 1ms mula sa Edge Runtime. Ang pagtatayo ng internal na feature flag platform gamit ang Edge Config + Vercel Flags SDK nang hindi gumagamit ng mga SaaS tulad ng LaunchDarkly o Statsig ay naging practical na solusyon sa 2026. Ang writes ay lumalagay sa buong rehiyon sa loob ng ilang segundo sa pamamagitan ng management API, at ang reads ay naka-embed sa Isolate ng runtime kaya walang network RTT.
Pinapamahalaan ng Flags SDK ang A/B testing at flag evaluation gamit ang parehong API, at tinitiyak ang identity consistency sa pagitan ng RSC at client components. Partikular, tinatandaan ng middleware ang user ID sa cookie, sini-evaluate ng RSC ang `flag("new-checkout").bucket(userId)`, at ang resulta ay inililipat sa mga child component bilang searchParams. Nagbibigay-daan ito sa SPA-like experience kung saan ang variant na natukoy sa server side sa unang access ay nananatili kahit sa mga sumunod na navigation — lahat ito ay kumpleto sa edge.
```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); }, }); ```
Ang size limit ng Edge Config ay pinalawak na sa 512KB/store at hanggang 10 stores/project (katapusan ng 2025). Sa practice, ang pangunahing gamit ay ang pag-store ng mga configuration value na may sapat na update frequency ng ilang segundo hanggang minuto — tulad ng "flag definitions," "price tables," at "region-specific prohibited words" — at hindi angkop para sa mataas na frequency na update data tulad ng user profile. Para sa gayon, ginagamit ang KV o Redis.
Observability at Sourcemaps
Ang Fluid Compute ay standard na sumusuporta sa automatic instrumentation ng OpenTelemetry, at sa pag-import lang ng `@vercel/otel` package ay dumadaloy na ang traces sa Datadog/Honeycomb/Grafana Cloud. Kapag tinawag ang fetch sa loob ng RSC, awtomatikong naputol ang span, at ang Web Vitals (LCP/INP/CLS) ay hinihigop bilang hiwalay na stream bilang RUM. Simula 2026, sa pamamagitan ng Vercel Observability Plus, maaaring ligtas na mag-upload ng production sourcemap at resolbahin ang stack trace sa TypeScript line numbers.
Ang error budget operations ay ginagawa sa pamamagitan ng pagtukoy ng SLO gamit ang query language ng Vercel Monitoring (VQL) at pagpapadala ng burn rate alert sa Slack/PagerDuty. Sa pamamagitan ng paglalagay ng p99 latency ng Edge Function, concurrent invocations ng Fluid, at hit rate ng Data Cache sa parehong dashboard, maaaring maaga itong ma-detect kapag bumaba ang static rate ng PPR o tumaas ang cache miss. Sa edge, ang tunggalian ay hindi lamang tungkol sa "bilis" kundi "hindi pagbabago ng bilis."