Rest or GraphQL?

That is the question…

REST. To tell the truth, I have always considered that it was an essential standard that responds very well to current architectural issues. I have nevertheless been repeatedly confronted with its limits and for several months I have often heard of GraphQL as a successor that could fill in some of the shortcomings of REST. The presentation "GraphQL, the future of REST" given by François Zaninotto, during the Blend Web Mix 2017 conference in Lyon, was an opportunity for me to learn a little more about this technology. Here is a summary of what I took away.

The hegemony of REST

Type applications SPA (Single Page App) and API-centric architectures are the norm today and in this domain REST is THE standard. This success, REST owes it to its simplicity and efficiency. Five http verbs: GET, POST, PUT, PATCH and DELETE, for the four persistence operations (Create, Read, Update, Delete) necessary for communication between client and server. But although universally embraced by the web, REST is not free from flaws.

The limits of REST

The first problem often encountered with REST API, this is the large size of some server responses. When you want to retrieve a particular resource, the server returns all the details of it. For example, if we ask for information about a user simply to display his first and last name, the server also sends us back his date of birth, his address, his telephone, etc. It's annoying on the front end because we find ourselves with superfluous information but above all this sometimes generates server responses with a large volume of data and therefore a longer transfer time which degrades the user experience (especially in the case of a mobile application with a low speed connection). This is called theover fetching.

The second problem is that very often, for the needs of the application, the Front developer must recover heterogeneous resources and quickly finds himself making a multitude of requests (sometimes independent and not parallelizable) and then crossing the results to achieve the desired final display. This is especially the case for an application with a complex data model. In this case, we are talking aboutunder fetching.

To overcome this kind of problem, the Front developer must then turn to the Back developers of the API to request specific entry points for certain use cases. This then generates additional development and maintenance costs and complicates the development process.

GraphQL and its benefits

GraphQL is a technology developed internally at Facebook since 2012 and made public in 2015. Unlike a REST API, an API developed according to the GraphQL specification has only one entry point (of type POST). Data is no longer seen as independent resources accessible via different entry points but in the form of a graph.
The schema that describes this data then serves as a contract (and documentation) between the client and the server. The definition language of this schema uses strong typing allowing better error management and therefore testing and validating its queries more easily. As such, the graphical interface GraphiQL is an indispensable tool for exploring and testing requests sent to the API.

The client is then able to write a request (in a language that looks very much like JSON) allowing it to retrieve, with a single call, the precise data it needs. This solves the over-fetching and under-fetching issues encountered with a REST API. GraphQL's flexible approach is a major advantage in the development process, as the Front end no longer needs to request specific entry points for application GUI needs.

On the server side, for each type of data accessible via the API, a resolver function will be implemented to query the database (or another data source like another API, because resolvers can be asynchronous!) and produce the response. Note that GraphQL is a specification and that its implementation has been ported to the main server languages: Java, NodeJS, Python, etc.

The disadvantages of GraphQL

Although GraphQL seems an ideal solution, François Zaninotto underlined the fact that it can be complex to implement and that due to its youth, it still presents significant uncertainties and risks.

Thus, issues related to API security and optimization appear complex. Indeed, the great flexibility of GraphQL presents a certain downside because any client of a public API is then able to address extremely complex queries that would take a long time to be resolved. The risk of malicious users trying to bring down the server by flooding it with requests (DOS attacks) seems even greater than with a REST API. It seems that solutions are proposed by GraphQL but unfortunately the time allowed did not allow François Zaninotto to address this subject in more detail...

The future of REST?

A series of questions was then submitted to the audience, these should make it possible to determine whether GraphQL really constitutes a better choice than REST according to the business issues of each one. Because even if REST is aging and has certain limits, its maturity and simplicity still make it a very good solution to application needs. So it looks like it can be said that even though GraphQL looks very promising, it hasn't buried REST yet!

François Zaninotto published a series of very detailed articles, a must read if you want to know more about GraphQL: https://marmelab.com/blog/2017/09/03/dive-into-graphql.html

Maxime Chasles, ReactJS Developer