Gateway Mastery: Protocols, Proxies, and the Modern Mesh
SchemaBridge Team · 2026-01-14 · Protocols, REST, API
One configurable HTTP gateway for the fragmented cloud: bounded retries, per-destination rate limits and egress-time secrets.
The Protocol Soup: Living in the Era of Infinite Fragmentation
If you listen to the hype, the world is all RESTful over HTTPS with JSON. If you listen to the true hype, the world is moving to GraphQL or gRPC. But if you look at the reality of a modern enterprise IT landscape, the world is a messy, uncoordinated soup of protocols spanning four decades of architectural fashion.
In a single organization, you likely have:
- The Modern: A fleet of React apps talking to GraphQL endpoints.
- The Workhorse: Thousands of internal microservices exposing REST APIs.
- The Third-Party: Various SaaS providers with rate limits and specific header requirements.
Integration is the art of building a bridge across this Protocol Soup. Traditionally, this meant writing "Adapter Services"—tiny, fragile Node or Go programs that did nothing but make an HTTP call. We called this "Glue Code" (see The Glue Code Crisis), and it is a massive burden on engineering velocity.
At SchemaBridge, we attack this with the Managed Gateway: a configurable HTTP gateway for REST-style APIs that decouples your business logic from the specific endpoint implementation. It is deliberately one protocol done well (HTTP with GET, POST, PUT and DELETE); there is no built-in GraphQL, gRPC or SOAP client, so those endpoints are reached through their HTTP surface or not at all.
The Architecture of the Managed Gateway
A SchemaBridge Gateway is more than a proxy. It is an intermediary that handles the "Connection Maintenance" of your infrastructure: retries, rate limits and credentials.
Response Normalization: The JSONata-First Approach
Instead of writing code to parse responses, you pair the gateway with a TRANSFORMATION step.
1. Call: The GATEWAY vertex calls the external service and hands back the result as response.statusCode and response.body. A JSON body arrives parsed; anything else arrives as a raw string.
2. Mapping: A downstream JSONata transformation extracts and reshapes the specific fields your workflow needs.
Done consistently, this means the rest of your visual logic only ever sees the clean shape you defined, regardless of the underlying source structure.
Adaptive Retry Policies: Beyond the 3-Retry Limit
Most developers use a "Fixed Retry" policy: retry 3 times with a 1-second delay. That often does more harm than good. If a service is down due to load, a fleet of workers retrying every second acts like a coordinated DDoS attack and keeps the service from recovering.
SchemaBridge Gateways retry with backoff, and within bounds:
- Exponential Backoff: A 5xx, a 429 or a network error is retried up to 3 times, doubling the wait each time (1s, 2s, 4s). Other 4xx responses are not retried, because repeating a bad request does not fix it.
- Retry-After Respected: On a 429, the gateway honours the provider's
Retry-Afterheader (capped at 30 seconds) instead of guessing. - Adaptive Admission: For overloaded destinations, the platform's per-destination rate limiter adapts its rate to what the provider is actually accepting, backing off on throttling and recovering on success, so a struggling API is not hammered.
A provider still overloaded after the HTTP retries is re-dispatched a few more times through admission control (maxAutoRetries, default 3). If it is still failing after that, the step fails visibly and can be retried once the provider recovers, rather than looping forever.
Managing the Rate Limit War: Global Concurrency Control
Every SaaS provider has a rate limit. Some are simple (10 requests per second). If you have 100 workers running your integration, how do they coordinate to stay under the limit?
If each worker tries to track its own rate, you will inevitably go over and get blocked. SchemaBridge provides workspace-wide, per-destination limits enforced at dispatch:
- Rate: A token bucket per workspace and destination caps requests per second across every worker.
- Concurrency: A concurrency ceiling per destination (configurable on the Rate Limits page) caps how many calls to that API can be in flight at once. Every vertex calling that API has to get through it before it runs.
Comparison: Traditional API Gateway vs. SchemaBridge Gateway
| Feature | API Gateway (Apigee/Kong) | SchemaBridge Managed Gateway |
| :--- | :--- | :--- |
| Focus | Inbound Traffic (North-South) | Outbound (egress) business calls |
| State | Mostly request-scoped (counters, caches) | Bounded retries on top of a persisted run |
| Logic | Scripting (Lua/JS) | Visual (JSONata) |
| Identity | Auth Verification | Secrets injected at egress ({{ secrets.NAME }}) |
Payload Normalization: The Death of the Adapter Service
As we discussed earlier in this series, writing specialized services to convert data is a waste of senior engineering talent. Pairing the gateway with a shared transformation turns normalization into a Property of the Link.
Two primitives make that reuse real. A custom app captures a provider's connection setup (base URL, headers, auth) once for your workspace and pre-fills it into every gateway that uses it. A persisted transformation rule captures the mapping once, under a ruleId, so every workflow that talks to the same legacy ERP shares it. You've moved the "Technical Overhead" into the platform and kept the "Business Logic" clean and visual.
Illustrative Scenario: Porting a Legacy API to the Modern Web
Consider a multi-national retail group modernizing its order management system.
The Challenge
Imagine its core inventory lives in a flaky legacy system spanning thousands of stores, while its new e-commerce frontend is a React/Next.js app. Bridging the two worlds with a set of hand-written "Adapter Microservices" would be a major, multi-quarter effort.
The SchemaBridge Way
Instead, picture the team reaching for the SchemaBridge Gateway primitive.
1. Gateway Configuration: Rather than writing code, they configure the legacy system as a custom app in SchemaBridge, with its credentials held in the encrypted secret store.
2. Visual Logic: Their product team builds the visual graph for "Check Inventory" directly.
3. Built-in Resilience: The gateway's backoff retries absorb the legacy system's short, transient failures, and per-destination limits keep the frontend's traffic from overwhelming it.
The Plausible Result
- Timeline: Much of what looked like a multi-quarter adapter project could become configuration work instead.
- Load: Because concurrency toward the legacy system is capped centrally, a traffic spike on the frontend would queue at the platform rather than knock the legacy system over.
The Future: The Protocol-Agnostic Enterprise
The specific protocol of an API should be an implementation detail, not a roadmap blocker. By moving toward a model of Gateway Mastery, we free ourselves from the "Legacy Ghost." We build our business logic on a foundation of clean, hierarchical truth, while our infrastructure handles the messy reality of the fragmented cloud.
Expert Checklist for Gateway Design
When designing your integration layer, follow these heuristics for your outbound connections:
1. Isolate the Protocol: Your business logic should never contain protocol-specific implementation details. Abstract those into the gateway and its transformation step.
2. Vault Your Credentials: Never paste auth headers into configuration. Reference them as {{ secrets.NAME }} so the token is injected only when the request leaves the platform.
3. Back Off, and Cap It: Don't just "Retry again in 1s." Use exponential backoff, honour Retry-After, and cap concurrency per destination. If you control the clients, add jitter too, to spread out synchronized retries.
Conclusion: The Bridge is the Gateway
Infrastructure is the art of handling the messy details so that logic can be pure. Gateway Mastery is the final step in decoupling your engineering velocity from the technical debt of the past. Stop writing adapters and start building bridges.
See also, from our Building the Bridge series: Error Recovery, on handling failure as a first-class business lifecycle.