Edge Functions vs Serverless Functions: Quando (e como) usar cada arquitetura na Vercel

Se você está construindo sistemas corporativos de alto desempenho usando Next.js na Vercel (e nós já explicamos por que focamos 100% no ecossistema Next.js e React), eventualmente você vai esbarrar em uma decisão técnica crítica: onde o seu código backend deve rodar?

Na era moderna da computação em nuvem, nós não alugamos mais "servidores inteiros" (EC2) que ficam ligados 24 horas por dia ociosos. Nós enviamos o nosso código para a nuvem e ele é executado apenas quando um usuário faz uma requisição.

Dentro do ecossistema da Vercel, existem dois motores principais para executar esse código: Serverless Functions e Edge Functions. Escolher o motor errado pode resultar em latência severa (Cold Starts) ou limitações de banco de dados.

Neste artigo técnico, vamos destrinchar como cada arquitetura funciona por debaixo dos panos, quando usar cada uma, e implementar um Middleware de Autenticação real rodando no Edge.

---

1. Serverless Functions: O Padrão Confiável (Node.js)

As Serverless Functions tradicionais (também conhecidas como AWS Lambda, já que a Vercel roda sobre a infraestrutura da AWS) são pequenos ambientes virtuais rodando Node.js completo.

Quando o seu usuário clica em "Finalizar Compra", a Vercel "acorda" uma Serverless Function em uma região específica (por padrão, Washington, D.C., EUA, ou São Paulo, BR). Ela executa o seu código pesado de backend, salva no banco de dados e "morre" logo em seguida. Esse tipo de processamento robusto é fundamental para a Anatomia de um SaaS Escalável.

Vantagens:

• Poder Total: Você tem acesso a 100% das APIs do Node.js (fs, crypto, child_process).
• Ecossistema NPM: Qualquer pacote do NPM funciona perfeitamente aqui.
• Tempo de Execução Maior: Permite processamentos longos (como gerar relatórios PDF ou processar pagamentos pesados). Limite de 10 a 60 segundos no plano Pro.

O Calcanhar de Aquiles: O Cold Start

Como a função "dorme" quando não está sendo usada, a primeira pessoa que acessar o sistema de manhã vai sofrer o chamado Cold Start (Partida Fria). A infraestrutura leva cerca de 1 a 3 segundos apenas para ligar o contêiner Node.js antes de rodar o seu código. Em um SaaS B2B exigente, 3 segundos de tela branca é uma eternidade.

---

2. Edge Functions: Velocidade da Luz (V8 Runtime)

Para resolver o problema do Cold Start e da distância física, a Vercel introduziu as Edge Functions.

Ao invés de rodar em um servidor centralizado nos EUA ou em São Paulo, o seu código é distribuído para dezenas de servidores ao redor do globo (na "Borda" da rede — The Edge). Além disso, elas não rodam Node.js completo. Elas rodam sobre a V8 Engine (o mesmo motor super leve que faz o Google Chrome funcionar).

Vantagens:

• Zero Cold Start: As Edge Functions ligam em frações de milissegundo. É literalmente instantâneo.
• Proximidade Geográfica: Se um usuário em Tóquio acessar seu site, o código backend roda em Tóquio. Se for em Londres, roda em Londres. A latência de rede é quase inexistente.
• Ideal para Interceptações: Perfeitas para middlewares, redirecionamentos A/B testing e validação de tokens.

Limitações Críticas:

• Não é Node.js: Você não pode usar pacotes NPM que dependam de APIs nativas do Node (fs, path). Você está limitado às Web APIs padrão (fetch, Request, Response).
• Tempo de Execução Estrito: O código não pode demorar para rodar. Se o seu script passar de 30 milissegundos de processamento de CPU, a Vercel corta a execução. Elas foram feitas para serem incrivelmente rápidas.

---

3. Resumo da Arquitetura: Quando usar o quê?

Use o padrão Edge quando a velocidade for inegociável e a lógica for leve:

• Middlewares do Next.js (middleware.ts).
• Validação de Autenticação (JWT) e Autorização pré-renderização.
• Geolocalização e Redirecionamentos de Idioma (i18n).
• Rate Limiting (bloqueio de bots usando Redis).

Use o padrão Serverless (Node.js) quando precisar de processamento denso:

• Conexão direta com Bancos de Dados Relacionais complexos via ORM (Prisma, TypeORM).
• Geração de PDFs ou manipulação pesada de imagens.
• Comunicação com APIs legadas que demoram para responder.

---

4. Mão no Código: Middleware de Autenticação no Edge

Vamos ver como isso funciona na prática. No Next.js, o arquivo middleware.ts roda exclusivamente no Edge Runtime.

Abaixo, temos um exemplo de Clean Code de um middleware que intercepta todas as requisições das rotas /dashboard. Ele verifica se o usuário possui um Token JWT válido nos cookies. Como roda no Edge, o usuário malicioso é barrado em 10 milissegundos, antes mesmo de tocar nos servidores principais ou no banco de dados.

// src/middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
import { jwtVerify } from 'jose'; 
// Biblioteca JWT leve, compatível com Edge (V8)

// O segredo deve estar definido nas variáveis de ambiente da Vercel
const JWT_SECRET = new TextEncoder().encode(process.env.JWT_SECRET_KEY);

export async function middleware(request: NextRequest) {
  // 1. Extrair o token do cookie do usuário
  const authToken = request.cookies.get('app_session')?.value;
  const loginUrl = new URL('/login', request.url);

  // Se não houver token, redireciona imediatamente 
  // (Tempo de resposta: ~15ms global)
  if (!authToken) {
    return NextResponse.redirect(loginUrl);
  }

  try {
    // 2. Validar a assinatura criptográfica do Token
    // Utilizamos 'jose' pois a biblioteca 'jsonwebtoken' 
    // padrão depende de APIs nativas do Node
    const { payload } = await jwtVerify(authToken, JWT_SECRET);

    // 3. Se o token for válido e pertencer a um Admin, injetamos headers customizados
    if (payload.role === 'admin') {
      const response = NextResponse.next();
      response.headers.set('x-user-role', 'admin');
      return response;
    }

    // Fluxo normal permitido
    return NextResponse.next();
    
  } catch (error) {
    // Token expirado, forjado ou inválido. O Edge bloqueia o 
    // acesso antes de consumir processamento backend.
    console.warn('Tentativa de acesso não autorizada interceptada.');
    return NextResponse.redirect(loginUrl);
  }
}

// 4. Configuração de rotas para otimização extrema
// Definimos exatamente quais caminhos ativam esta Edge Function
export const config = {
  matcher: ['/dashboard/:path*', '/settings/:path*'],
};

Como Forçar o Edge em Qualquer Rota ou API

Por padrão, todas as suas Páginas (App Router) e APIs no Next.js rodam no modo Serverless (Node.js) para garantir compatibilidade máxima com pacotes do mercado. Mas e se você criar uma API de consulta extremamente simples e quiser que ela rode na velocidade do Edge?

Você não fica refém do padrão. O Next.js te dá o poder de forçar o motor. Basta adicionar esta linha mágica no topo de qualquer arquivo page.tsx ou route.ts:

export const runtime = 'edge';

export async function GET() {
  return new Response("Essa API roda no Edge em milissegundos!");
}

Por que esse código é poderoso?

Se este código estivesse rodando em um servidor legado ou mesmo em uma Serverless Function comum, um ataque de força bruta tentando acessar /dashboard geraria milhões de invocações de banco de dados e Cold Starts, possivelmente derrubando a aplicação ou gerando uma conta astronômica de AWS.

Rodando no Edge, essas requisições inválidas morrem na "fronteira" da rede da Vercel (em servidores espalhados pelo mundo perto do atacante), com um custo computacional beirando o zero.

---

5. Escalando com Sabedoria

O ecossistema Vercel com Next.js abstrai completamente a dor de gerenciar infraestrutura, mas exige inteligência na hora de orquestrar a lógica de negócios. Ao dominar a separação entre Edge (velocidade) e Serverless (potência), o seu SaaS ganha a resiliência de um monolito corporativo e a agilidade de uma startup.