Learnings From Refactoring Large GraphQL Backends

We've all faced this predicament. Our products begin as fledgling projects that eventually gain steam. The rising tide of users, with the associated increased demand, propels us into a cycle of adding features only to yank them out in subsequent updates. We might have taken certain tech-related decisions that seemed justifiable at the time, but now they're causing slowdowns.

Faced with such situations, you realize you need to act. Perhaps you've tried streamlining your existing backend but found it too sprawling, too convoluted, or simply too ancient that it'd take an eternity, or it's rooted in obsolete technology. But then it dawns on you that completely rewriting the whole thing from the ground up is also not feasible due to time constraints.

Regardless of the journey that led you here (which is an entirely different discussion), you're forced to seek out a solution. The problem is gradually intensifying, and you're witnessing its impact on your KPIs. You might harbor thoughts of waiting until the next significant milestone when you could hopefully secure more funding and recruit fresh developers to address the problem. But, let's be candid here, how often does that actually pan out?

If you're utilizing GraphQL, I might have a genuine, almost enchanting solution at hand. It's known as GraphQL Federation and, surprisingly, it's yet to be widely adopted, despite its immense potential.

The aspect of GraphQL Federation that truly captivates me is its ability to effortlessly isolate even a single field to a distinct service. You can migrate that particular field or, if you wish, entire mutations or features. That's the crux of it all. You can completely develop a new feature in an entirely new service, potentially on a novel infrastructure or even a fresh database, without the client even batting an eyelid. From their perspective, they're still interacting with the old backend.

So, how does this all pan out? The process is actually quite straightforward, propelled by the might of GraphQL resolvers (and some additional wizardry).

At present, your client is directly communicating with your backend. With Federation, you introduce a service, a router, that is well-versed with the schema of your old GraphQL service as well as the new one(s). Now, when a client shoots a request, the router is smart enough to know where to fetch which fields. This incorporates the full magic of what GraphQL brings to the table.

Armed with this power, you're now ready to elevate your business. Rather than fretting over a full overhaul of your backend, you can persist with fixing bugs and rolling out new features. Your primary focus, however, will now shift towards implementing new features in the new backend. Gradually, as time allows and resources permit, you can migrate existing functionality from the old service to the new. But the best part is, you can do it at your own pace.