How to move from REST to GraphQL without rewriting the frontend
Dozens of services change their contract. Does the frontend that uses them have to change on the same day?
The risk in an API migration is that every consumer of the old contract has to change together with the services. If the consumers are a website, an online booking flow and an app, the migration becomes a coordinated release across several teams, all on the same day.
The decision
A gateway in front of the services, exposing to the frontend exactly the contract it already knows, same paths, same error codes, same edge cases, and resolving behind it on the new GraphQL schema. The frontend keeps calling what it called. What changes is who answers.
The pattern has a name, strangler fig with an anti-corruption layer, and a working rule that matters more than the name: every handler is ported one to one, improving nothing during the transport. Even a questionable behaviour, like a retry spanning several weeks, is replicated as is, because it was part of the contract. Improvements come later, with the old already switched off.
What makes the move safe
Three things. The gateway's base set up before the domains: structure, resolvers, logging with context, token and error handling, so that whoever adds an endpoint follows a shape already decided. Parity verified for every handler, on real responses. And cross-review on everything that signs or authenticates: it was in review that a handler migrated in perfect parity turned out to sign tokens with a symmetric key, and moved to asymmetric keys before reaching production.
With the gateway standing, each next domain costs less than the previous one. The old proxy switches off one handler at a time, and nobody notices from the frontend. That is the result you want.
Describe the system. We'll tell you what we see.
Ten minutes, one question at a time. At the end, our honest read of the case. It's the filter, before the call.