Edge functions: o que muda rodar código mais perto do usuário

Já falei aqui sobre as camadas de cache do Next.js, e uma delas, o Full Route Cache, guarda uma rota já renderizada. Edge function resolve um problema parecido, mas do outro lado: em vez de guardar uma resposta pronta, ela executa código de verdade, só que o mais perto fisicamente possível de quem fez a requisição, em vez de rodar numa região central só.

Onde o código roda normalmente

Numa função serverless tradicional (tipo uma AWS Lambda comum), você escolhe uma região pra hospedar, digamos us-east-1, na Virgínia. Toda requisição, não importa de onde no mundo ela vem, viaja até essa região específica pra ser processada. Se o usuário está no Brasil, essa viagem de ida e volta até os Estados Unidos adiciona uma latência real, perceptível, antes mesmo do código começar a rodar.

O que muda com edge

Uma edge function roda numa rede distribuída de servidores espalhados geograficamente, em várias cidades ao redor do mundo. Quando a requisição chega, ela é atendida pelo servidor mais próximo do usuário, não por uma região central única. Um usuário no Brasil é atendido por um servidor no Brasil (ou perto), um usuário na Europa é atendido por um servidor na Europa, cada um com uma latência de rede bem menor, porque a distância física até o servidor é bem menor.

// exemplo de edge function no Next.js
export const runtime = "edge";
 
export function GET(request: Request) {
  return Response.json({ mensagem: "respondido perto de você" });
}

Essa única linha, export const runtime = "edge", já muda onde essa função é executada, de uma região central pra rede distribuída.

Por que isso importa de verdade

A diferença fica mais visível em operações rápidas e frequentes: verificar um cookie de autenticação, redirecionar baseado em localização, aplicar um teste A/B, validar um token antes de deixar a requisição continuar. Esse tipo de checagem, feita antes mesmo da página renderizar, se beneficia bastante de rodar perto do usuário, porque cada milissegundo daquela latência de ida e volta se soma diretamente ao tempo que a pessoa espera até a página começar a aparecer.

Pra uma operação que já é naturalmente mais lenta, tipo uma consulta pesada num banco de dados centralizado numa única região, a vantagem de edge diminui bastante: não importa quão perto do usuário o código rode, ele ainda precisa viajar até o banco, que continua numa região fixa. Nesse caso, a latência de rede até o banco domina o tempo total, e rodar o código mais perto do usuário resolve só uma fração pequena do problema.

As limitações que vêm junto

Rodar numa rede distribuída de edge não é o mesmo runtime completo do Node que você usa localmente. O runtime de edge é bem mais restrito: geralmente não dá acesso a módulos nativos do Node (tipo fs, pra ler arquivo do sistema), o tamanho do próprio código tem limite mais apertado, e nem toda biblioteca do ecossistema JavaScript funciona nesse ambiente, principalmente as que dependem de recursos específicos do Node.

// isso quebra numa edge function
import fs from "fs";
 
export const runtime = "edge";
 
export function GET() {
  const dado = fs.readFileSync("./arquivo.json"); // erro: fs não existe aqui
}

Esse tipo de limitação existe porque o ambiente de edge prioriza inicializar extremamente rápido, em qualquer um dos vários servidores espalhados pelo mundo, e abrir mão de parte do runtime completo é o preço técnico dessa velocidade.

Quando vale a pena

Edge function compensa quando a lógica é leve, executa rápido, e o ganho de latência de rede realmente importa pra experiência (autenticação, redirecionamento, personalização simples baseada em localização). Não vale a pena forçar em processamento pesado, que depende de biblioteca específica do Node, ou que de qualquer jeito precisa esperar uma consulta lenta num banco centralizado, porque nesses casos a limitação do runtime custa mais do que o ganho de latência compensa.

Fechando

A ideia central não é que edge seja "melhor" que serverless tradicional em todo lugar, é que resolve bem um problema específico: distância física entre usuário e servidor pesando na experiência. Pra lógica leve e frequente, essa proximidade faz diferença real, perceptível. Pra tudo que já depende de algo lento e centralizado por natureza, como um banco de dados numa única região, o ganho fica pequeno, e as limitações do runtime deixam de compensar.