O Que o Fluid Compute Resolve
O Vercel Fluid Compute, que entrou em GA em 2025, é uma plataforma de execução de nova geração que unifica os runtimes antes separados em "Serverless Functions" e "Edge Functions". As Serverless Functions antigas tinham um custo alto de cobrança por idle ("1 requisição = 1 container"), enquanto as Edge Functions eram limitadas por um teto de 50 MB no tamanho do código e por restrições de compatibilidade com o Node.js. O Fluid Compute adota um modelo de "multi-tenant concurrency", onde uma única instância processa múltiplas requisições em paralelo, excluindo o tempo de espera de I/O da cobrança. O resultado é que características antes antagônicas — manter uma conexão com o banco de dados e ter latência próxima do edge — podem agora coexistir.
Em abril de 2026, a opção `runtime` no `next.config.ts` tem três escolhas: `"nodejs"`, `"edge"` e `"fluid"`. O padrão do Next.js 16 é `"fluid"`, e as rotas dentro de `/app` rodam sobre Fluid a menos que você escreva explicitamente `export const runtime = "edge"`. As Edge Functions ficaram restritas a casos de uso como terminação de WebSocket e APIs de latência mínima, e o debate antes travado entre "edge ou Lambda" mudou para "o Fluid é suficiente ou preciso do Edge?".
Renderização RSC no Edge com Next.js 16
O Next.js 16 passou a gerar o streaming de saída dos React Server Components (RSC) nos PoPs (Points of Presence). Concretamente, ele faz flush assíncrono do HTML e do payload RSC por fronteira de Suspense, reduzindo o TTFB para cerca de 40 ms. O ponto crucial é o posicionamento do data fetching. No RSC, você pode escrever um `fetch` que se resolve inteiramente no servidor, mas a regra é não conectar diretamente ao banco de dados de origem — deve-se usar o Vercel Data Cache (antes chamado Request Memoization) ou uma camada de cache no edge como Hyperdrive/PlanetScale Boost.
O RSC rodando no Edge Runtime tem restrições. `fs`, `net` e `child_process` do Node.js não estão disponíveis, e a criptografia deve passar pela Web Crypto API. Com o edge-compatible adapter adicionado no final de 2025, o Prisma 6 e o Drizzle ORM funcionam como estão, mas Sequelize e TypeORM ainda têm o Fluid como opção recomendada. A arquitetura padrão de 2026 é dividir os papéis: "RSC no Edge, escrita no banco no Fluid".
```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 e Partial Prerendering (PPR)
O PPR foi introduzido experimentalmente no Next.js 14, estabilizado no 15 e habilitado por padrão no 16. É uma funcionalidade que entrega "shell estático + preenchimento dinâmico" em um híbrido de build time e runtime. O esqueleto HTML gerado no build é retornado imediatamente pelos PoPs, enquanto as partes específicas do usuário (ícone do carrinho, produtos recomendados) são mantidas como fronteiras de Suspense e enviadas pelo servidor em flush posterior. Isso permite manter a taxa de cache CDN e ao mesmo tempo personalizar.
A armadilha de implementação é que "no momento em que você referencia `cookies()` ou `headers()`, toda aquela árvore se torna dinâmica". Chamar `headers()` inadvertidamente no layout faz com que o shell estático do PPR não seja gerado, rebaixando para SSR completo em cada acesso. Deve-se auditar regularmente a proporção de "Static (prerendered)" e "Dynamic (on-demand)" nos logs do `next build` e detectar quedas na taxa estática no CI.
Edge Config e Feature Flags com Suporte de CDN
O Edge Config é um "armazenamento JSON otimizado para leitura" fornecido pela Vercel, que pode ser lido a partir do Edge Runtime em menos de 1 ms. Construir uma infraestrutura interna de feature flags com Edge Config + Vercel Flags SDK, sem recorrer a SaaS como LaunchDarkly ou Statsig, é a solução prática de 2026. A escrita ocorre via API de administração e se propaga para todas as regiões em poucos segundos; a leitura é incorporada ao Isolate do runtime e não gera RTT de rede.
O Flags SDK trata A/B testing e avaliação de flags pela mesma API, mantendo a identidade consistente entre RSC e componentes client. Concretamente, o middleware fixa o ID do usuário em um cookie, `flag("new-checkout").bucket(userId)` é avaliado dentro do RSC, e o resultado é passado como `searchParams` para os componentes filhos. Isso realiza, com execução totalmente no edge, uma experiência semelhante à de uma SPA — em que a variante decidida no servidor na primeira visita é mantida nas navegações subsequentes.
```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); }, }); ```
O limite de tamanho do Edge Config foi expandido para 512 KB por store e 10 stores por projeto (final de 2025). Na prática, o uso central é armazenar valores de configuração que precisam ser atualizados em intervalos de segundos a minutos — como definições de flags, tabelas de preços e palavras bloqueadas por região. Dados com atualização de alta frequência, como perfis de usuário, devem usar KV ou Redis.
Observabilidade e Sourcemaps
O Fluid Compute tem suporte padrão para instrumentação automática com OpenTelemetry; basta importar o pacote `@vercel/otel` para que os traces fluam para Datadog, Honeycomb ou Grafana Cloud. Chamar `fetch` dentro de um RSC cria automaticamente um span, e as Web Vitals (LCP, INP, CLS) são coletadas como RUM em um stream separado. A partir de 2026, o Vercel Observability Plus permite fazer upload seguro de sourcemaps de produção e resolver stack traces com números de linha TypeScript.
Para a gestão do error budget, a prática padrão é definir SLOs com a linguagem de consulta do Vercel Monitoring (VQL) e enviar alertas de burn rate para Slack/PagerDuty. Colocar lado a lado no mesmo dashboard a latência P99 das Edge Functions, as concurrent invocations do Fluid e a taxa de hit do Data Cache permite detectar precocemente quedas na taxa estática do PPR ou aumentos de cache miss. No edge, a batalha não é só por "velocidade", mas por "manter a velocidade estável".