O que são Edge Computing e Funções de Edge?

Edge computing é um modelo que executa computação perto de usuários ou fontes de dados; funções de edge são código serverless executado em PoPs de CDN. O termo amplo — definido canonicamente por Shi et al. como computação posicionada perto das fontes dos dados — abrange IoT de chão de fábrica e infraestrutura MEC de telecom. Para quem desenvolve backend, significa algo específico: funções pequenas implantadas nos mesmos pontos de presença globais que uma CDN usa, executando no PoP mais próximo de cada requisição — a evolução da CDN de cachear conteúdo para executar código.

Principais pontos

Uma função de edge, e a camada onde ela vive

// JavaScript — an edge function (web-standard APIs, runs at every POP)
// Gateway logic at the edge; the backend stays the source of truth
export default async function handler(request) {
  const url = new URL(request.url);
  const country = request.headers.get('x-user-country') ?? 'US';

  if (url.pathname === '/' && country !== 'US') {
    return Response.redirect(`${url.origin}/${country.toLowerCase()}/`, 302);
  }
  // Verify a session quickly at the edge; data work goes to the origin
  const auth = request.headers.get('Authorization');
  if (!auth) return new Response('Unauthorized', { status: 401 });

  return fetch(request); // pass through to the origin backend
}

// Flutter / Dart — Back4app Flutter SDK
// The three-layer picture from the client's seat:
// CDN serves static assets · edge handles gateway logic · origin owns data
final query = QueryBuilder<ParseObject>(ParseObject('Post'))
  ..whereEqualTo('status', 'published')
  ..setLimit(20);
final response = await query.query();
// This query talks to the ORIGIN backend — where the database lives.
// Moving it "to the edge" would move the round trip, not remove it.

// iOS / Swift — Back4app Swift SDK
// The three-layer picture from the client's seat:
// CDN serves static assets · edge handles gateway logic · origin owns data
let query = Post.query("status" == "published")
  .limit(20)
let posts = try await query.find()
// This query talks to the ORIGIN backend — where the database lives.
// Moving it "to the edge" would move the round trip, not remove it.

// Android / Kotlin — Back4app Android SDK
// The three-layer picture from the client's seat:
// CDN serves static assets · edge handles gateway logic · origin owns data
val query = ParseQuery.getQuery<ParseObject>("Post")
query.whereEqualTo("status", "published")
query.limit = 20
val posts = query.find()
// This query talks to the ORIGIN backend — where the database lives.
// Moving it "to the edge" would move the round trip, not remove it.

A aba JavaScript é a própria função de edge — Request/Response padrão web, sem framework, interceptando o tráfego antes da origem. As abas de cliente mostram o outro lado da arquitetura: os dados da aplicação continuam fluindo para o backend de origem, porque é lá que o banco de dados mora — a frase à qual este artigo inteiro não para de voltar.

Isolates vs. contêineres: por que o edge inicia em milissegundos

Milhares de isolates compartilham um único processo de vida longa por máquina — o mesmo mecanismo que mantém as abas do navegador separadas — então “iniciar” uma função significa criar um contexto, não dar boot em um runtime. Essa arquitetura, e não pools aquecidos, é o motivo de as plataformas de edge alegarem honestamente cold starts perto de zero. A conta chega na terceira e na quarta linha: uma fronteira de isolamento mais fraca (remendada com mitigações cuidadosas) e um runtime onde boa parte do npm não roda — sem sistema de arquivos, sem módulos nativos, sem avaliação dinâmica, com a superfície portátil agora sendo padronizada como a Minimum Common API.

Edge vs. origem: a divisão das cargas

A parte honesta: seu banco de dados continua em um único lugar

A seção que os explicadores de fornecedores omitem. Mover a computação para o edge não move os dados — apenas realoca a ida e volta de usuário → servidor para função → banco de dados, e para cargas tagarelas isso é um rebaixamento: uma função de edge a 5 ms do usuário fazendo cinco consultas sequenciais a um banco a 150 ms de distância gasta 750 ms onde uma função regional co-localizada com o banco gastaria ~5. A aritmética explica a correção silenciosa da indústria — grandes plataformas de edge passaram a recomendar seus runtimes regionais para a maioria das cargas e adicionaram opções de fixar funções perto do banco de dados, a admissão mais forte possível de que localidade de dados vence localidade de computação. As correções parciais, em ordem de praticidade: rode código pesado em dados na origem (a tabela de divisão acima); agrupe tudo em uma única ida e volta quando o código de edge precisar tocar dados; e replique leituras para fora via caches chave-valor de edge — trade-offs de consistência eventual inclusos. Funções de edge vencem quando terminam no edge; no momento em que ligam para casa a cada requisição, a geografia deixa de estar do seu lado.

Quando edge é over-engineering

A maioria das aplicações é um backend CRUD com uma base de usuários regional — para elas, um backend em uma única região mais uma CDN para assets estáticos é mais simples e, com frequência, mais rápido de ponta a ponta do que uma camada de edge que faz ida e volta ao mesmo banco. Funções de edge conquistam seu lugar quando a lógica termina no edge, para uma audiência globalmente distribuída, em um caminho visível na latência — três condições, todas obrigatórias. O modelo de custo conta a mesma história pelo outro lado: plataformas de edge cobram por requisição mais milissegundos de CPU (barato para lógica fina de gateway), enquanto funções regionais cobram duração de relógio — incluindo o tempo que seu código passa esperando o banco de dados ao lado do qual deveria estar sentado.

Casos de uso comuns

• Portões de autenticação — verifique um token de sessão no PoP; requisições não autenticadas nunca cruzam o oceano.
• Geo-personalização — idioma, moeda e roteamento de compliance decididos a milissegundos do usuário.
• Buckets de A/B e de features — atribuição de cookie no edge, consistente antes mesmo de a página carregar.
• Rate limiting e defesa contra bots — absorva o abuso no perímetro, com contadores por PoP em KV de edge.
• Edge computing amplo — o sentido IoT/telecom: sensores de fábrica e infraestrutura 5G processando localmente, a profundidade de outro artigo reconhecida em uma linha.

Você deveria usar funções de edge? Matriz de decisão

Limitações e trade-offs

• O runtime é um subconjunto. Só APIs padrão web; ORMs com bindings nativos, bibliotecas de imagem e código dependente de sistema de arquivos não rodam — confira a árvore de dependências antes de se comprometer.
• Os tetos de CPU são rígidos. Dezenas de milissegundos de computação é o orçamento; funções de edge moldam o tráfego, não o processam.
• O estado mora em outro lugar por design. Toda necessidade stateful roteia para a origem ou para um KV de edge com semântica de consistência eventual — nenhum dos dois sai de graça.
• Depurar é distribuído. Reproduzir um bug que só ocorre em um PoP sob uma geografia é uma disciplina à parte; logar centralizadamente a partir de todo lugar é a mitigação.
• O pêndulo balança. Padrões edge-first já foram revertidos uma vez; trate o edge como ferramenta precisa para lógica de gateway, não como identidade de arquitetura.

Edge no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. No desenho de três camadas que este artigo traça, o Back4app é a origem bem-feita: o banco de dados e a lógica de negócio em Cloud Code moram juntos — a co-localização que torna o trabalho com dados rápido — atrás de uma CDN que serve arquivos e assets estáticos dos mesmos PoPs que uma camada de edge usaria. Funções de edge então se encaixam na frente como lógica fina de gateway onde as três condições valem: um redirect aqui, uma checagem de token ali, repassando a uma origem que é dona dos dados e aplica ACLs em toda requisição. A lição de arquitetura que a seção honesta ensina — computação perto do usuário, trabalho com dados perto dos dados — é exatamente essa divisão, com cada camada fazendo a parte que a geografia favorece.