O edge runtime: quando ajuda e quando só move o problema

O discurso do edge compute é simples: rode seu código no data center mais próximo do usuário e toda resposta fica mais rápida. O discurso é verdadeiro para uma classe estreita de código e enganoso para a maior parte do que um produto faz. Já vi times moverem uma aplicação para o edge, comemorarem a demo e depois voltarem em silêncio três meses depois.

O motivo é geografia. Seu código se moveu. Seu banco não.

O que o edge runtime é de fato

No Next.js, o edge runtime é um ambiente JavaScript restrito construído sobre Web APIs. Sem módulos do Node.js, sem sistema de arquivos, sem sockets TCP crus, um limite pequeno de bundle e cold starts muito rápidos. Roda nos pontos de presença de um CDN ao redor do mundo em vez de em uma região só.

Essas restrições são o ponto. Como o runtime é pequeno, ele inicia em milissegundos em qualquer lugar. Como não pode abrir um socket, não pode usar um driver de banco tradicional, e fala com dados por HTTP. Isso serve para uma consulta chave-valor e é uma restrição séria para qualquer coisa relacional.

O próprio framework ficou mais cuidadoso com isso. A camada de interceptação de requisições que antes era só edge agora roda no runtime Node.js por padrão, justamente porque a maioria dos times precisava de acesso ao banco ali e o edge não conseguia dar.

Quando ajuda

O edge brilha quando a decisão pode ser tomada com o que já está na requisição. Redirecionar por país. Reescrever uma URL com base em um cookie para um teste A/B. Verificar um token de sessão assinado, sem consulta ao banco, para barrar usuários anônimos antes de chegarem à origem. Adicionar headers de segurança. Servir uma variante personalizada de uma página em cache onde a personalização é o valor de um header.

Em todos esses casos, o código precisa da requisição, talvez de um pequeno armazenamento de config replicado globalmente, e nada mais. A resposta é mais rápida porque a viagem até a região de origem sumiu, e essa viagem custa de 100 a 300 milissegundos para um usuário do outro lado do planeta.

Também ajuda em conteúdo estático com toques dinâmicos leves, como um site institucional que troca a moeda por região, onde o conteúdo pesado vem do cache do CDN e a função de edge apenas o decora.

Quando move o problema

Agora pegue uma página de produto que roda três queries contra um banco em uma única região. No servidor de origem, cada query custa um milissegundo de rede porque o banco está no mesmo prédio. No edge, cada query cruza o oceano. Três queries sequenciais de um ponto de edge longe do banco custam mais do que o render inteiro na origem teria custado.

Você não deixou a página mais rápida. Moveu a latência do trecho usuário-servidor para o trecho servidor-banco, multiplicou pelo número de queries e tornou mais difícil de depurar. Essa é a falha que mais vejo, e a demo esconde porque a demo roda na mesma região do banco.

Bancos replicados globalmente resolvem isso no papel e criam um problema de consistência na prática. Uma escrita em uma região leva tempo para chegar às outras, e uma aplicação que lê a própria escrita de outra região vê o valor antigo. É um trade-off real que alguns produtos deveriam fazer. Não é algo que você deveria descobrir depois de mover para o edge.

A regra de decisão

Uso uma pergunta. Este código precisa falar com um armazenamento de dados de região única mais de uma vez por requisição? Se sim, rode na região de origem, ao lado dos dados, e use o CDN para aquilo em que ele é bom. Se não, o edge é uma boa casa para ele.

A maior parte de uma aplicação responde sim. As partes que respondem não são pequenas, valiosas e merecem ir para o edge de propósito. O erro é mover tudo e torcer para a geografia se resolver sozinha. Não se resolve. Dado tem localização, e a computação deveria estar perto dele.