There's No Turnkey in Integration

A developer recently published a production API gateway built on Cloudflare Workers and Hono. Auth, rate limiting, caching, proxying, logging. Under 300 lines of TypeScript. Total overhead for cached responses: under 5ms. Cost: $0.30 per million requests.

Read that again. A production API gateway. 300 lines. Five milliseconds.

Now ask yourself: why did your company spend six months evaluating Apigee?

The evaluation trap

Here’s a pattern we’ve seen play out dozens of times over the past 20 years.

A company decides it needs an API gateway. Maybe they’re exposing internal services to partners. Maybe they need rate limiting and auth in front of a legacy backend. The requirement is clear enough.

What happens next is not engineering. It’s procurement theater.

Month one: shortlist. Apigee, MuleSoft, Kong Enterprise, maybe Boomi. Analysts get consulted. Vendor decks arrive. Month two: first PoC. The happy path works. Data flows through the visual mapper. Screens get demoed to leadership. Month three: second PoC with a different vendor, because due diligence. Month four: the first vendor’s PoC hits a wall — SAP IDocs don’t parse cleanly in the visual mapper, a custom protocol needs a workaround that’s “on the roadmap.” Month five: the second vendor offers a discount. Month six: a decision gets made, a contract gets signed, and the actual integration work begins — with a platform that covers 70% of the requirements out of the box.

The other 30% is where the project lives or dies.

The 70/30 wall

Every API management platform gives you an impressive first impression. Routing works. OAuth token validation works. The dashboard looks professional. Rate limiting is a toggle. For a standard REST API in front of a well-behaved backend, these platforms are genuinely good.

The problem is that mission-critical integration rarely involves well-behaved backends.

The 30% that platforms don’t cover is exactly the 30% you bought the platform for: the SAP IDoc format that doesn’t map to JSON without custom transformation. The legacy SOAP service that returns different XML schemas depending on which mainframe partition handled the request. The partner API that requires client certificates rotated on a schedule that doesn’t match your platform’s certificate management. The operational model — who gets paged at 3 AM, how updates get rolled out, what happens when the vendor deprecates a feature you depend on.

These aren’t edge cases. They’re the actual requirements. And they’re invisible in PoC demos because PoCs run on test data against mock endpoints.

ThoughtWorks put it clearly enough when they placed “overambitious API gateways” on hold in their Technology Radar: gateways are becoming “transport software with ambitions to run critical application logic.” Their recommendation — any domain logic should live in applications and services, not in middleware. Authentication and rate limiting belong in the gateway. Business logic and data transformation do not.

Gateway is not API management

Part of the confusion is that vendors bundle two distinct things and sell them as one.

An API gateway is a runtime concern. It sits in the request path and handles routing, token validation, rate limiting, caching. It needs to be fast, reliable, and operationally simple. The Workers/Hono example does exactly this — a middleware pipeline where each step has a single responsibility. JWT verification via Web Crypto API at 1-2ms. Distributed rate limiting via Durable Objects at 5-15ms. Cache lookup at ~1ms. That’s the gateway.

API management is everything else. Token lifecycle — issuing, rotating, revoking API keys. Developer portals where partners self-serve their credentials. Usage metering and billing per consumer. API catalogs, versioning policies, sunset management. An OAuth2 authorization server that issues tokens, not just validates them.

The enterprise platforms bundle both layers. That bundling is the product. It’s how they justify the price point — and it’s how they create lock-in, because once your token lifecycle, your developer portal, and your routing are all in one system, migrating any single piece means migrating everything.

When you separate these layers, each becomes a solvable problem with appropriate tooling. The gateway might be Workers/Hono. Token lifecycle might be Keycloak or Ory Hydra. The developer portal might be a Backstage instance or a custom solution — because no off-the-shelf portal does exactly what your partners need anyway.

There are real trade-offs. Workers won’t give you static IPs — if your compliance requirements mandate egress through specific network zones, you need dedicated infrastructure and that costs more than $0.30 per million requests. Some industries require audit trails that a lightweight gateway doesn’t produce. These constraints are valid. They’re also knowable before you sign a vendor contract — if you do the requirements work first.

Requirements first, tools second

The actual work that determines whether an integration project succeeds or fails happens before any tool gets chosen. It’s the work most teams skip because it’s less exciting than a PoC demo.

What does the operational model look like? Who monitors the gateway at 2 AM? What’s the update strategy — can you deploy independently of the vendor’s release cycle, or are you waiting for their next quarterly patch? What are the integration boundaries — which systems does this gateway sit between, what protocols do they speak, what are their failure modes?

When these questions have clear answers, the tool choice often becomes obvious. Sometimes the answer is 300 lines of Workers. Sometimes it’s an Airflow DAG. Sometimes it’s Apache Camel. And sometimes, yes, it’s Apigee — because the use case genuinely matches 100% of what the platform offers. That’s fine. Apigee is not a bad product. It’s a bad default.

The difference between a 100% match and an 80% match is the difference between a platform that accelerates your team and a platform that becomes the bottleneck your team works around.

The cost of “good enough”

There’s a specific kind of technical debt that API platforms create, and it’s different from code-level debt. When your routing, auth, rate limiting, token management, and developer portal all live in one vendor’s system, every future decision is constrained by that system’s capabilities and release schedule.

Need to support a new protocol? Check if the vendor supports it. Need to change your token rotation policy? Check if the platform allows it. Need to integrate a system that doesn’t have a pre-built connector? Write a custom adapter inside the vendor’s framework, using their SDK, deployed on their schedule.

Integration engineers — whether on your team or at a firm like ours — need freedom to choose the right tool for each layer. That freedom is the first thing a platform purchase eliminates.

Open source helps here. Not as a turnkey replacement — there is no turnkey in integration — but as building material. It requires a team that knows what to build. The “solvable” in “each layer becomes a solvable problem” assumes someone capable of solving it.

300 lines as proof

The Workers/Hono gateway isn’t the point of this article. It’s the evidence.

It proves that when requirements are clear — “I need auth, rate limiting, and caching in front of this API” — the technical solution is often simple. The complexity was never in the gateway. It was in figuring out what the gateway needs to do, how it fits into the operational model, and what happens when things break.

Six months of platform evaluation doesn’t answer those questions. Requirements engineering does. And if you’re going to spend six months on something, spend it there.