Dominando o gateway: protocolos, proxies e a malha moderna
SchemaBridge Team · 2026-01-14 · Protocols, REST, API
Um gateway HTTP configurável para a nuvem fragmentada: retries limitados, rate limits por destino e secrets injetados na saída.
A sopa de protocolos: vivendo na era da fragmentação infinita
Se você der ouvidos ao hype, o mundo inteiro é RESTful sobre HTTPS com JSON. Se der ouvidos ao verdadeiro hype, o mundo está migrando para GraphQL ou gRPC. Mas, olhando para a realidade de um cenário de TI corporativo moderno, o mundo é uma sopa de protocolos bagunçada e descoordenada, que atravessa quatro décadas de modismos arquiteturais.
Em uma única organização, você provavelmente tem:
- O moderno: uma frota de apps React conversando com endpoints GraphQL.
- O burro de carga: milhares de microsserviços internos expondo APIs REST.
- Os terceiros: diversos provedores SaaS com rate limits e exigências específicas de cabeçalhos.
Integração é a arte de construir uma ponte sobre essa sopa de protocolos. Tradicionalmente, isso significava escrever "serviços adaptadores" — pequenos e frágeis programas em Node ou Go que não faziam nada além de uma chamada HTTP. Chamávamos isso de "código cola" (veja A crise do código cola), e ele é um fardo enorme para a velocidade da engenharia.
Na SchemaBridge, atacamos isso com o Managed Gateway: um gateway HTTP configurável para APIs no estilo REST que desacopla sua lógica de negócio da implementação específica do endpoint. Ele é deliberadamente um único protocolo bem feito (HTTP com GET, POST, PUT e DELETE); não há cliente GraphQL, gRPC ou SOAP embutido, então esses endpoints são alcançados pela sua superfície HTTP ou não são alcançados.
A arquitetura do Managed Gateway
Um gateway da SchemaBridge é mais do que um proxy. É um intermediário que cuida da "manutenção das conexões" da sua infraestrutura: retries, rate limits e credenciais.
Normalização de respostas: a abordagem JSONata em primeiro lugar
Em vez de escrever código para fazer o parse das respostas, você combina o gateway com uma etapa TRANSFORMATION.
1. Chamada: o vértice GATEWAY chama o serviço externo e devolve o resultado como response.statusCode e response.body. Um corpo JSON chega já parseado; qualquer outra coisa chega como string bruta.
2. Mapeamento: uma transformação JSONata posterior extrai e reestrutura os campos específicos de que seu workflow precisa.
Feito de forma consistente, isso significa que o restante da sua lógica visual só enxerga a forma limpa que você definiu, independentemente da estrutura da fonte subjacente.
Políticas de retry adaptativas: além do limite de 3 tentativas
A maioria dos desenvolvedores usa uma política de "retry fixo": tentar novamente 3 vezes com 1 segundo de espera. Isso muitas vezes faz mais mal do que bem. Se um serviço está fora do ar por causa de carga, uma frota de workers tentando de novo a cada segundo age como um ataque DDoS coordenado e impede que o serviço se recupere.
Os gateways da SchemaBridge fazem retry com backoff e dentro de limites:
- Backoff exponencial: um 5xx, um 429 ou um erro de rede é repetido até 3 vezes, dobrando a espera a cada vez (1 s, 2 s, 4 s). Outras respostas 4xx não são repetidas, porque repetir uma requisição inválida não a corrige.
- Retry-After respeitado: em um 429, o gateway respeita o cabeçalho
Retry-Afterdo provedor (limitado a 30 segundos) em vez de adivinhar. - Admissão adaptativa: para destinos sobrecarregados, o rate limiter por destino da plataforma adapta sua taxa ao que o provedor está de fato aceitando, recuando diante de throttling e se recuperando com os sucessos, para que uma API em dificuldade não seja martelada.
Se um provedor continuar sobrecarregado após os retries HTTP, a etapa é despachada novamente mais algumas vezes pelo controle de admissão (maxAutoRetries, padrão 3). Se continuar falhando depois disso, a etapa falha de forma visível e pode ser reexecutada quando o provedor se recuperar, em vez de ficar em loop para sempre.
Gerenciando a guerra dos rate limits: controle global de concorrência
Todo provedor SaaS tem um rate limit. Alguns são simples (10 requisições por segundo). Se você tem 100 workers executando sua integração, como eles se coordenam para ficar abaixo do limite?
Se cada worker tentar controlar a própria taxa, você inevitavelmente vai ultrapassá-lo e ser bloqueado. A SchemaBridge oferece limites por destino em todo o workspace, aplicados no momento do dispatch:
- Taxa: um token bucket por workspace e destino limita as requisições por segundo somando todos os workers.
- Concorrência: um teto de concorrência por destino (configurável na página Rate Limits) limita quantas chamadas para essa API podem estar em andamento ao mesmo tempo. Todo vértice que chama essa API precisa passar por ele antes de executar.
Comparação: API gateway tradicional vs. gateway da SchemaBridge
| Recurso | API Gateway (Apigee/Kong) | SchemaBridge Managed Gateway |
| :--- | :--- | :--- |
| Foco | Tráfego de entrada (norte-sul) | Chamadas de negócio de saída (egress) |
| Estado | Principalmente por requisição (contadores, caches) | Retries limitados sobre uma execução persistida |
| Lógica | Scripting (Lua/JS) | Visual (JSONata) |
| Identidade | Verificação de autenticação | Secrets injetados na saída ({{ secrets.NAME }}) |
Normalização de payload: a morte do serviço adaptador
Como discutimos antes nesta série, escrever serviços especializados para converter dados é um desperdício de talento de engenharia sênior. Combinar o gateway com uma transformação compartilhada transforma a normalização em uma propriedade do vínculo.
Duas primitivas tornam esse reúso real. Um custom app captura uma única vez a configuração de conexão de um provedor (URL base, cabeçalhos, autenticação) para o seu workspace e a pré-preenche em todo gateway que a utilize. Uma regra de transformação persistida captura o mapeamento uma única vez, sob um ruleId, para que todo workflow que conversa com o mesmo ERP legado o compartilhe. Você levou o "overhead técnico" para a plataforma e manteve a "lógica de negócio" limpa e visual.
Cenário ilustrativo: portando uma API legada para a web moderna
Considere um grupo varejista multinacional modernizando seu sistema de gestão de pedidos.
O desafio
Imagine que seu estoque central fica em um sistema legado instável que abrange milhares de lojas, enquanto seu novo frontend de e-commerce é um app React/Next.js. Ligar esses dois mundos com um conjunto de "microsserviços adaptadores" escritos à mão seria um esforço grande, de vários trimestres.
O jeito SchemaBridge
Em vez disso, imagine a equipe recorrendo à primitiva de gateway da SchemaBridge.
1. Configuração do gateway: em vez de escrever código, eles configuram o sistema legado como um custom app na SchemaBridge, com as credenciais guardadas no cofre de secrets criptografado.
2. Lógica visual: o time de produto constrói diretamente o grafo visual de "Check Inventory".
3. Resiliência embutida: os retries com backoff do gateway absorvem as falhas curtas e transitórias do sistema legado, e os limites por destino impedem que o tráfego do frontend o sobrecarregue.
O resultado plausível
- Prazo: boa parte do que parecia um projeto de adaptadores de vários trimestres poderia virar trabalho de configuração.
- Carga: como a concorrência em direção ao sistema legado é limitada de forma centralizada, um pico de tráfego no frontend ficaria enfileirado na plataforma em vez de derrubar o sistema legado.
O futuro: a empresa agnóstica a protocolos
O protocolo específico de uma API deveria ser um detalhe de implementação, não um bloqueio no roadmap. Ao caminhar para um modelo de domínio do gateway, nos libertamos do "fantasma do legado". Construímos nossa lógica de negócio sobre uma base de verdade limpa e hierárquica, enquanto nossa infraestrutura lida com a realidade bagunçada da nuvem fragmentada.
Checklist de especialista para o design de gateways
Ao projetar sua camada de integração, siga estas heurísticas para suas conexões de saída:
1. Isole o protocolo: sua lógica de negócio nunca deveria conter detalhes de implementação específicos de protocolo. Abstraia-os no gateway e na sua etapa de transformação.
2. Guarde suas credenciais no cofre: nunca cole cabeçalhos de autenticação na configuração. Referencie-os como {{ secrets.NAME }} para que o token seja injetado apenas quando a requisição sai da plataforma.
3. Faça backoff, e limite-o: não se limite a "tentar de novo em 1 s". Use backoff exponencial, respeite Retry-After e limite a concorrência por destino. Se você controla os clientes, adicione também jitter para espalhar retries sincronizados.
Conclusão: a ponte é o gateway
Infraestrutura é a arte de lidar com os detalhes bagunçados para que a lógica possa ser pura. Dominar o gateway é o passo final para desacoplar sua velocidade de engenharia da dívida técnica do passado. Pare de escrever adaptadores e comece a construir pontes.
Veja também, da nossa série "Building the Bridge": Recuperação de erros, sobre tratar falhas como um ciclo de vida de negócio de primeira classe.