What is GraphQL
It is a specification laid out by Facebook which proposed an alternative way to query and modify data. Think of it is an as a complimentary of REST/RPC.
Now head here and read the original graphQL documentation. It will take 2-3 hours tops but is a worthy read. This will help you build some impressions on it and help contrast against mine below:
Why use GraphQL
Core advantage
- Instead of defining custom backend rpc/rest endpoints for every data-shape, graphql allows you to build a more general endpoint which give frontend/mobile engineers freedom and query and play with the data. It might be less efficient, add a bit more complexity (need for things like data-loader), harder to standardize and control client-contracts for. What it looses in complexity and control, it gains in flexibility and freedom - provided your data model is worth of a graphql-ish query
- How to tell if my data-model graphql-ish?
- Are there complex relationships between your models? Is there a need for client to traverse multiple relationships in a single call?
For eg, if you are yelp, think about the following queries you might need: - get the reviews left by all the folks who live in my town
- get the top 3 rated reviewers from the places that I've reviewed recently
- In a traditional world, these would need 2 separate backend endpoints. With GraphQL on the server side, you can implement a schema that abstract your business-domain and allows the client to interact (query/write) directly.
Other Advantages
- The GraphIQL (ide for graphql) enables callers to play around, explore and just request what they need. The shape of the response matches the shape of the calls. This removes building special endpoints per use case.
- Might be a natural way to query data models which resemble a graph
- No versioning or anything (I feel this is also a con)
Now the downsides:
- FB released just the GraphQL spec. The implementations are community driven. Reading reddits, seems like the docs may not be of the highest standards.
- Again, this might improve over time.
- Opening up backends to unhealthy query patterns that might increase load on the system. Generally, if a feature requires an an bad-query (say multiple joins, costly queries, etc.) that gets factored into the cost of the feature. But with GraphQL abstracting all this, it might be hard to capture this in planning stages.
- An opposing thought is that APIs should be client driven and clients know best what they want. Backends can monitor call patterns and optimize those expensive calls.
My overall impressions is that GraphQL is not a magic pill for all scenarios. It fits some use cases very well: if your model is heavy AND involves complex relationships AND clients are dynamic and want flexibility in how the query this data - then GraphQL might be worth giving a try.
