O que é um API Gateway?

Um API gateway é uma porta de entrada gerenciada para as suas APIs — um ponto único que roteia, autentica e aplica rate limit a cada requisição. A ideia é centralização: o trabalho transversal de que todo endpoint precisa (quem é você, a que taxa pode chamar, para onde isso vai, o que aconteceu) sai de N serviços e entra em uma camada de política que os clientes não conseguem contornar.

Principais pontos

O que a porta de entrada faz

A lista de tarefas de um gateway, como configuração em vez de N cópias de middleware — uma rota declarativa típica:

# rota do gateway: uma entrada, política anexada
route: /orders/**
  service: orders-api:8080          # roteamento — a topologia fica privada
  auth: bearer-jwt                  # autenticação na porta
  rate_limit: 100/min per key       # orçamentos antes dos backends
  transform:
    strip_headers: [X-Internal-*]   # traduzir entre a borda e o interior
  timeout: 5s
  observe: log + trace + metrics    # um só lugar para observar tudo

Do lado do cliente, um gateway gerenciado desaparece dentro do SDK — uma chamada, com as checagens da porta aplicadas antes de qualquer código seu rodar:

// JavaScript / Node.js — Back4app JS SDK
// One managed entry point: auth, rate limits, and routing applied per call
const receipt = await Parse.Cloud.run('placeOrder', { cartId: 'crt_812' });
// The platform's gateway verified the session, applied limits,
// and routed to the function — none of it in your code.
console.log(`Order ${receipt.orderId} confirmed`);

// Flutter / Dart — Back4app Flutter SDK
// One managed entry point: auth, rate limits, and routing applied per call
final function = ParseCloudFunction('placeOrder');
final response = await function.execute(parameters: {'cartId': 'crt_812'});
if (response.success) {
  print('Order ${response.result['orderId']} confirmed');
}

// iOS / Swift — Back4app Swift SDK
// One managed entry point: auth, rate limits, and routing applied per call
ParseCloud.callFunction("placeOrder",
                        parameters: ["cartId": "crt_812"]) { result in
  if case .success(let receipt) = result {
    print("Order confirmed: \(receipt)")
  }
}

// Android / Kotlin — Back4app Android SDK
// One managed entry point: auth, rate limits, and routing applied per call
val params = hashMapOf("cartId" to "crt_812")
ParseCloud.callFunctionInBackground<Map<String, Any>>("placeOrder", params) { receipt, e ->
  if (e == null) Log.d("Orders", "Order ${receipt["orderId"]} confirmed")
}

Os quatro parecidos, separados

A descrição canônica do padrão acrescenta a variação que vale conhecer: o Backend for Frontend — um gateway fino por tipo de cliente, cada um moldando respostas para o seu cliente — que troca mais artefatos implantados pelo fim das APIs tamanho-único-que-não-serve-em-ninguém.

As desvantagens, ditas sem rodeios

O gateway centraliza poder, e a centralização cobra de quatro formas. Ponto único de falha: tudo flui por ele — rode-o clusterizado atrás de um load balancer ou aceite que a queda dele é a queda. O novo gargalo: todo time de feature agora abre mudanças de configuração contra um componente compartilhado; governança e ferramentas de self-service são parte da adoção, não extras. O monólito renascido: lógica de agregação acumulando no gateway reconstrói em silêncio a aplicação centralizada que você decompôs — mantenha-o denso em política e magro em lógica. Alastramento de config: centenas de rotas com políticas por rota são um codebase; revise-as como um. Nada disso argumenta contra gateways; tudo isso argumenta contra gateways casuais.

Casos de uso comuns

• Porta de entrada de microsserviços — a história de origem: muitos serviços, uma API coerente, topologia livre para evoluir atrás dela.
• Produtos multi-cliente — web, mobile e parceiros com auth, formatos e limites diferentes — o território do BFF.
• Monetização de API — chaves, planos, quotas e medição de uso impostos em um ponto.
• Migrações — o padrão strangler: o gateway roteia caminhos antigos para o sistema legado e caminhos novos para o substituto, de forma invisível.
• Política de borda — CORS, TLS, higiene de headers e rate limiting aplicados uma vez em vez de N.

Você precisa de um? Matriz de decisão

A resposta sem dono na maioria das páginas de comparação: ainda não é uma arquitetura legítima. Adicione a porta quando houver um prédio atrás dela.

Limitações e trade-offs

• A disponibilidade agora é a disponibilidade do gateway. Clusterize, monitore com health checks e ensaie a falha dele — a mitigação é padrão e não é opcional.
• Um hop de latência, contabilizado com honestidade contra as idas e vindas e o middleware duplicado que ele remove; meça, não presuma em nenhuma direção.
• Agregação é uma ladeira. Compor respostas é legítimo; lógica de negócio no gateway é o padrão ESB usando um crachá novo.
• Opções open-source carregam operação. Existem gateways excelentes em open source (stacks baseados em Envoy e pares) — cada um é um sistema distribuído que você agora roda, atualiza e protege.
• Gateways gerenciados trocam controle por silêncio. A porta operada pela plataforma é a resposta certa exatamente quando operar o gateway seria labuta sem diferencial.

O gateway 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. A camada de gateway vem com a plataforma: toda requisição — REST, GraphQL, SDK ou chamada de Cloud Code, como nas abas de código acima — entra por uma borda gerenciada que autentica sessões e chaves, aplica rate limits por app e roteia para as APIs geradas ou para as suas funções, com a plataforma operando o clustering e a escalabilidade que tornam uma porta de entrada segura. A matriz de decisão colapsa: você ganha as garantias do gateway no primeiro dia, e pula a posse da porta por inteiro.