Edge Functions vs Serverless: O Que Muda na Prática

O cold start que ninguém menciona no pitch de vendas

Uma Serverless Function na AWS Lambda (runtime Node.js 20) com um bundle de 5 MB leva entre 300 ms e 800 ms no primeiro cold start, dependendo da região e da memória alocada. Uma Edge Function na Cloudflare Workers ou no Vercel Edge Runtime inicia em menos de 10 ms. Essa diferença parece encerrar a discussão: edge ganha. Só que a história não termina na latência de boot.

Edge Functions rodam em um runtime restrito. Sem fs, sem net, sem child_process, sem acesso a TCP arbitrário. Serverless Functions rodam um Node.js completo (ou Python, Go, Java, Rust). A escolha entre as duas não é sobre qual é "melhor": é sobre qual conjunto de restrições você aceita em troca de qual benefício.

O que cada uma é, sem marketing

Serverless Functions executam em containers efêmeros em data centers específicos (us-east-1, sa-east-1, eu-west-1). O provedor gerencia o scaling, mas a função roda em uma região fixa. O runtime é completo: Node.js com acesso a todas as APIs nativas, incluindo binários compilados via layers.

Edge Functions executam em pontos de presença (PoPs) distribuídos globalmente, usando runtimes leves baseados em V8 isolates (Cloudflare Workers, Deno Deploy) ou versões restritas do Node.js (Vercel Edge Runtime). O código roda perto do usuário, mas dentro de um sandbox com limites rígidos de CPU, memória e APIs disponíveis.

Critério	Serverless (Lambda/Cloud Functions)	Edge Functions (Workers/Vercel Edge)
Runtime	Node.js, Python, Go, Java, Rust completos	V8 isolates ou Node.js restrito
Cold start típico	300-800 ms (Node.js), 1-5 s (Java)	< 10 ms
Tempo máximo de execução	15 min (Lambda), 60 min (Cloud Run)	30 s (Cloudflare), 25 s (Vercel Edge)
Memória máxima	10 GB (Lambda)	128 MB (Workers), 1 GB (Vercel)
APIs Node.js disponíveis	Todas	Subconjunto (sem fs, net, child_process, dgram)
Localização	Região fixa	PoPs globais (300+ locais)
Acesso a banco relacional	Direto via TCP	Via HTTP/WebSocket (Neon, PlanetScale, Supabase)
Preço por invocação (referência)	~$0.20/1M (Lambda)	~$0.50/1M (Workers paid)

Quando edge resolve e quando atrapalha

Edge Functions brilham em lógica leve que precisa rodar perto do usuário. Três cenários onde a escolha é clara:

Rewrite e redirect com lógica: verificar um cookie de A/B test e redirecionar antes de o request chegar ao origin server. Isso é o que o Next.js Middleware faz na edge.

// middleware.ts (Vercel Edge Runtime / Next.js Middleware)
import { NextRequest, NextResponse } from "next/server";

export function middleware(request: NextRequest) {
  const bucket = request.cookies.get("ab-bucket")?.value;

  if (!bucket) {
    // Atribui bucket no primeiro acesso para manter consistência durante a sessão
    const assigned = Math.random() > 0.5 ? "control" : "variant";
    const response = NextResponse.next();
    response.cookies.set("ab-bucket", assigned, { maxAge: 60 * 60 * 24 * 30 });
    return response;
  }

  if (bucket === "variant") {
    return NextResponse.rewrite(new URL("/landing-variant", request.url));
  }

  return NextResponse.next();
}

export const config = {
  matcher: ["/landing"],
};

Autenticação e autorização antes do origin: validar um JWT e rejeitar requests inválidos antes de consumir compute no backend.

// Cloudflare Worker: validação de JWT na edge
// Usa Web Crypto API (disponível em V8 isolates, sem dependência de node:crypto)
export default {
  async fetch(request: Request): Promise<Response> {
    const authHeader = request.headers.get("Authorization");
    if (!authHeader?.startsWith("Bearer ")) {
      return new Response("Unauthorized", { status: 401 });
    }

    const token = authHeader.slice(7);

    try {
      const payload = await verifyJwt(token);
      // Propaga identidade para o origin via hea

---

Leia o artigo completo em [https://www.vivodecodigo.com.br/infra/edge-functions-vs-serverless-o-que-muda-na-pratica](https://www.vivodecodigo.com.br/infra/edge-functions-vs-serverless-o-que-muda-na-pratica)