GraphQL is an open-sourced query language for Web APIs created by Facebook in 2012. It's neither an architectural pattern nor a web service. It acts an intermediary which helps in querying the data received from various datasources. These datasources can be databases or web services.
React is used in various projects these days for creating a user friendly UI. Most people are using Rest Api's to retrieve and publish data, but GraphQL makes it much easier to merge and mutate data from discrete REST resources into the right shape for our UI.
GraphQL is a query language which lets you write queries using an object structure rather than a text string.
So rather than using an SQL query like:
‘SELECT name, id, description FROM projects’
You would simply describe the object and the fields you’d like from that object you like, so:
{projects {idnamedescription}}
A large number of posts that explain “How to GraphQL” focus on the easy query structure. The thing that made it all “click” for me was when I realized that all of the requests are sent to a single /graphql endpoint.
Why does this matter? The actual transmission of requests and data is abstracted away. We no longer have to worry about things like response codes and planning out our urls like: /project/item/somethingElse/youGetThePoint
Alright, so why should one use GraphQL?
It’s easier. It’s an abstraction. Unlike REST, one of the core ideas of GraphQL is related to solving these issues. Every call returns only the data that is specified in the request. This has a few benefits. Firstly, it completely solves the reactjs over-fetching problem by putting it entirely in the client’s hands. Secondly, it removes the need for multiple requests by allowing the client to ask for everything they need all at once. We’re now able to mark a field as deprecated, which lets new integrators know that they should not to use it, and then grab a list of all the existing integrations and get in touch with them to offer an upgrade path.
All the solutions discussed above have some similar rest API tooling available and relatively healthy communities around them, but GraphQL seems to go above and beyond the other two. Coming out of Facebook, GraphQL has mostly been adopted within the react community, which is very large and very active. This means there’s loads of great tools available to make the developer experience as good as it can be.
Chances are, if you have a stable RESTful service, there’s probably not a strong case for chucking all of that work out. It’s stable and tested, why introduce change and risk?
The real power of GraphQL to me is, being able to implement certain design patterns on new or existing web services.
It is technically true that any of these patterns could be implemented with a different tool. I’d argue that using GraphQL would make most sense in implementing these patterns, because the request/manipulation of data (query) is completely decoupled from the execution of those actions (resolvers).
Example Use Case: We had a UI that used to show projections and predictions using charts. So there were a large number of Rest Api's needed to be created, so as to show data on that UI. For Java developers it took a certain amount of time to create those Api's with different endpoints. Now with GraphQL, it has become easy for me as a UI developer, as I now I have a single endpoint with which I could fetch data and update on the UI.