Hey Sashko. Nice article!!!
I’d like to pitch in some more pitches for GraphQL too. These are additional added benefits over REST, which I like to think are pretty cool advantages.
Firstly,
Traffic
As a REST based application grows, it usually will get fairly awnery. By that I mean, for every piece or set of data needed, there is another URL to call. So, to put together a page with a lot of data, there can be a large number of API calls (and usually is). Each HTTP Request causes additional traffic. For our homebound computers probably not an issue, but for mobile devices, it certainly can be.
GraphQL’s ability to gather queries to send of in one call reduces bandwidth considerably. Also, should a mobile version need less data, the queries for that use case can be reduced accordingly, but without necessarily needing different versions. More on that later.
You touched it a bit with Graphiql and the available introspection of schema, but this needs a bit more of a push, as it is a huge part of GraphQL’s advantages.
Introspection
There has been attempts to create a type of introspection into REST API’s, but it is all “extras” and it still doesn’t really help the overall concerns frontend devs have, when it comes to building frontends. For instance, still needing to dig through API docs, when things don’t quite make sense, and still running into a wall of “WTF’s” while reading the docs.
With GraphQL, introspection of the schema is baked into the specification. For GraphQL to be successful, the schema must be understood. And more importantly, the query helps directly to understand the format of the response. In other words, GraphQL is very declarative.
Composition (Part 2)
I mentioned composition in the Traffic point above, but there is another advantage to the composition of GraphQL. If you’ve been a frontend developer working with REST, often is the case that you will probably have 4 different files of code open in your editor or IDE, trying to figure out how the API and the front end code/ markup will all work together. In other words, reasoning about code is more difficult.
With GraphQL and because of the new web components concept, GraphQL queries were designed to be written and stored alongside the component code. So, you can have all the pieces of the UI puzzle in one file. This allows for quicker understanding of what is going on, which is great for bug fixing. And it allows for better reasoning of the code in general.
Stonger Typing
I sort of mentioned it earlier, but going through and trying to understand REST API docs (and even worse, writing docs that make sense) is a PITA.
GraphQL is strongly typed, which mean basically self-documenting. If this isn’t a winner, I don’t know what is.
Now, the best advantage for last.
Versioning
One of the biggest issues with interoperating with REST APIs is having to live with version changes. If you switch to a new version, because you need certain new data in one place of your app, or because the API vendor says, “We are deprecating Version X, because of Y”, you might end up with a completely broken application and with an extensive API, you will probably be acting like a chicken without a head. There are ways to improve REST API versioning to reduce the pain, but those kinds of needed efforts are basically whacko compared to GraphQL.
Simply put, GraphQL doesn’t have or need versioning!!! The link to the left is a great explanation of why this is such an advantage.
I also think the explanation the Facebook people gave for why they came up with GraphQL is also a clear and obvious reason. I am going to paraphrase it here. If you have to supply an API, which basically serves the same data, but needs to be in slightly different forms, like for instance, you are doing APIs for both web, mobile native and/or mobile hybrid, versioning will be your achilles heel. You’ll probably need a good number of different versions of the API to the same data source, and this causes technical debt, version conflicts, duplication of work, additional resources-both manpower and system, did I miss anything? Isn’t that enough?
With GraphQL, you can avoid a lot of the above, if not all of it. Of course, Facebook is at a scale, where the savings can really mean a lot. But, some of it is also important to the lone programmer too.
There are even more advantages. I’ve just skimmed over the major ones and I hope I could also help promote what I think is the next best thing to sliced bread! :-)
