I was reading the November 2018 issue of SD Times when I came upon Hasura in their watchlist. Hasura offers GraphQL on top of Postgres. My team used GraphQL in a recent project and I’m very enthusiastic about graphs so the entry caught my eye. From the article: “Why we’re watching: Industry leaders believe GraphQL will soon overtake the market share of REST APIs.” Whoa, what? So time for a little research.
Googling for REST vs GraphQL produced a plethora of results. The quickest and most approachable summary was Is GraphQL a REST killer?.
GraphQL will do to REST what JSON did to XML.
The 3 most important problems that GraphQL solves beautifully are:
- The need to do multiple round trips to fetch data required by a view: With GraphQL, you can always fetch all the initial data required by a view with a single round-trip to the server. To do the same with a REST API, we need to introduce unstructured parameters and conditions that are hard to manage and scale.
- Clients dependency on servers: With GraphQL, the client speaks a request language which: 1) eliminates the need for the server to hardcode the shape or size of the data, and 2) decouples clients from servers. This means we can maintain and improve clients separately from servers.
- The bad front-end developer experience: With GraphQL, developers express the data requirements of their user interfaces using a declarative language. They express what they need, not how to make it available.There is a tight relationship between what data is needed by the UI and the way a developer can express a description of that data in GraphQL.
I really like the thought process of “GraphQL will do to REST what JSON did to XML”. REST did not replace REST, but REST provided much better functionality for a lot of cases than XML did. XML still has its place and as always its “right tool for right job”. The rest of the blog has differing opinions on the GraphQL vs REST and quickly provides a good idea of the limits of GraphQL.
The articles I surveyed fell into two groups: GraphQL rules and GraphQL is another arrow in the quiver.
GraphQL is the better REST: Given that the site is “how to GraphQL” its no surprise that they thing GraphQL is better than REST.
Your API Choice Could Make Or Break Your Company: GraphQL vs REST From a React Developers Perspective: Very favorable because front end changes need way less back end changes.
REST vs. GraphQL: A Critical Review: Excellent set of comparisons. Very favorable to GraphQL considering that most folk don’t do REST right (instead doing RESTful).
Both, REST and GraphQL, are API design architectures which can be used to build web services for data-driven applications. In this tutorial you’ve learned the main difference between those two concepts. The RESTful approach is always limited to deal with single resources. If you need data which is coming from two or more resources (like posts and users) you need to do multi round trips to the server. Furthermore REST requests are always returning the full set of data which is available for a certain resource. There is no way to limit the request to only retrieve a subset of data fields.
The GraphQL approach is much more flexible and is able to overcome the major shortcomings of REST as demonstrated in this tutorial. By using the GraphQL query language you can exactly describe what the response should look like. You’re able to specify which fields should be included to limit the response to the data which is needed. Furthermore you can use the graph and combine connected entities within one GraphQL data query. No additional server round trips needed.
GraphQL APIs can be exciting new technology, but it is important to understand the tradeoffs before making such architectural decisions. Some APIs such as those with very few entities and relationships across entities like analytics APIs may not be suited for GraphQL. Whereas applications with many different domain objects like e-commerce where you have items, users, orders, payments, and so on may be able to leverage GraphQL much more.
In fact, GraphQL vs REST is like comparing SQL technologies vs noSQL. There are certain applications where it makes sense to model complex entities in a SQL Db. Whereas other apps that only have “messages” as in high volume chat apps or analytics APIs where the only entity is an “event” may be more suited using something like Cassandra.
You Might Not Need GraphQL: “A lot of APIs that are merely RESTish could certainly be GraphQL, but an actual REST API with HATEOAS would not make sense trying to jam itself into the GraphQL paradigm. State Transfer and Query Languages are different things, but as I’ve shown, you can blur the lines a little if you’re interested.”
SOAP can be used in enterprise solutions with formal contract-based exchange formats. Also, SOAP APIs perform best when there are acceleration mechanisms implemented on both sides.
GraphQL can show the best performance when the number of queries needs to be reduced to the absolute minimum. With its single query addressing multiple resources, GraphQL can be a good match to this challenge. Also, considering the fact that in GraphQL data is defined on the client side, it can be a good solution for cases when there is no dependency between the client application and the server.
GraphQL vs OData
REST vs GraphQL vs oData: Nice short summary
GraphQL is not OData: After reading this I would definitely lean towards GraphQL over OData.
REST API Industry Debate: OData vs GraphQL vs ORDS: Recommends OData, but has a product that support OData.
GraphQL vs OpenSearch
I found nothing here. My guess is that OpenSearch is really for browsers to call search engines for approximate results whereas with GraphQL,REST, SOAP, ODATA you are looking for very specific data to make an application run.