[nicwolff]

You don't have to "move" to reap GraphQL's benefits – you can just add a GraphQL layer.

I'm backend Systems Architect at a big publishing company, and my current primary project is an aggregating caching GraphQL proxy for our REST microservices.

Our front ends were making too many calls to the REST APIs, so we went overboard embedding related resources – and now they're getting too much unneeded data back, and cache invalidation is a nightmare. Sounds familiar, probably!

So we're building a GraphQL service that stitches those REST APIs together to let the caller request exactly the fields they need, from any API's resource. By caching individual resources, rather than nested multi-resource serializations, we can invalidate easily by UUID on change events – so cache TTLs can be long – and the GraphQL API's field resolvers can assemble complex responses with a few fast Redis MGETs, which are batched by DataLoaders.

This also gives us a place to centralize business logic, rather than having each front end service reimplement field formatting, resource transforms, &c. Since the REST APIs remain available as the source of truth, existing services can migrate to the GraphQL proxy at their own pace, which we hope will be an easy sell since it's so much faster.