GraphQL is everywhere these days. From Facebook’s original usage of it to some more funky usages like databases, GraphQL is loved by so many developers that we are starting to use it in areas nobody would’ve thought of initially.
Every technology has its use cases for which it is ideal, for which it can work, for which it plain sucks, and everything in between. As developers, we want to pick the right tool for the job, which means understanding our use case and think about what tech might work best for it. This includes the features of the technology itself, but also how familiar we are with it, the community around it, and much more.
I recently spent some time thinking about where GraphQL shines most. We could call it the GraphQL “Sweet Spot”.
Anything close to the middle is where I think GraphQL is a perfect fit. Going towards the exterior of the circle, it’s where I think GraphQL can be used, but maybe it doesn’t benefit from the same advantages. Maybe we can think of it as different “tiers”.
Before we explore these tiers let me make something clearer: even if certain usages of GraphQL are outside the so-called “Sweet Spot”, it doesn’t mean they are completely invalid. It mostly means you might get less of its benefits, or have to invest more tooling to make it more appropriate. It might also mean I’m just behind the times ;).
Tier one use cases for GraphQL is using it as an internal API for supporting multiple clients. This is the original Facebook use case and we can expect GraphQL to be optimized for it. So what’s that use case exactly?
We were frustrated with the differences between the data we wanted to use in our apps and the server queries they required. [Source]
Pre-GraphQL, similar concerns were highlighted by Daniel Jacobson. Daniel’s articles are still some of my favorites out there:
REST APIs are excellent at handling requests in a generic way, establishing a set of rules that allow a large number of known and unknown developers to easily consume the services that the API offers.
In this model, everyone knows how to behave and it can be incredibly powerful. The API providers establish a set of rules and the API consumers must…