GraphQL vs REST APIs

REST APIs represent a must these days when it comes to exposing and sharing services to anyone.

REST is simple to use and has its own ecosystem of tools that each actor of a project can share and exchange. Application developers, third-party application developers, project managers, and business actors all can easily discover, test, and use REST APIs.

All this is thanks to portal API solutions, whether through proprietary or open-source solutions.

So, REST has replaced SOAP in the heart of the developers — but is it perfect?

No.

Indeed, REST architectures are not perfectly adapted to all uses and cannot easily solve all problems because:

1. REST is all or nothing. If you request an object, you will spontaneously have all the fields of the object or you will have nothing.

2. REST often requires multiple calls to get the desired data.

3. REST is not designed to easily manage relationships between objects.

4. REST is static. You get the response that the application developer decided to set.

5. REST requires exchanges between developers so that the implemented REST APIs are suitable for all projects.

6. REST doesn't guarantee the type of data exchanged.

This REST mania we are currently living blinds us to the disadvantages of this architecture. It is true that API management solutions have helped popularize REST architectures. They completely corrode UDDI directories and provide new impetus for all projects. However, all this should not obscure an objective criticism of REST architecture.

These six REST defects are addressed by GraphQL, which poses itself as a serious competitor for compensating REST issues.

What Is GraphQL?

GraphQL was created by Facebook in 2012. Facebook was using it for its own needs at first, but the Menlo Park firm decided to release the sources of this project in 2015.

GraphQL is, above all, a query language like SQL where the format of the request is the same as that of the reply. In practice, a GraphQL query looks like this:

And the answer looks like this:

GraphQL queries can be discovered by themselves using a dedicated IDE, simply by using the CTRL + SPACE command to visualize the proposed business objects and associated fields.

It's that simple!

What About Backend Developers?

To date, the approach of projects using GraphQL is to define the data model in the code. Programmatically we define:

• The schema with the objects and types of fields.

• The requests.

• The data source for each business object.

The data source may be:

• A relational database.

• A NoSQL database.

• A REST API.

• The result of a personalized algorithm.

You can also bind business objects together, even if these objects are in two different data sources and technologies. It is then possible to navigate from one business object to another just by playing on the relations between these two objects.

However, you can also introspect databases and APIs (via a Swagger import) directly to quickly expose existing data.

At first, we were able to test GraphQL via the POC that we set up at Astrakhan and could appreciate the power of this technology.

The trend is accelerating. The market counts more and more references, with of course Facebook, but also:

• GitHub.

• Coursera.

• Pinterest.

• Intuit.

• Club Med.

In short, a whole ecosystem that is formed and developed with libraries, frameworks, and tools to enrich the basic solution.

What does this mean from an architectural point of view? Does this mean the death of REST? This is what some articles suggest on the web. Our opinion is much more measured. For us, the appearance of the GraphQL mainly means:

• A coexistence between REST and GraphQL will appear. Developers and architects will position themselves for one or the other according to their needs.

• It will be necessary to consider whether REST and the APIs are necessarily the panaceas for all needs.

• We finally have here the elementary brick of a data layer.

In short, GraphQL is a technology to be taken into account today as far as its integration with the information system. REST APIs are adapted to service-oriented IT as much as GraphQL is adapted to data-oriented IT. In this major service-oriented IT versus data-oriented IT debate, it is perhaps in the form of technological complementarity that we will see these two technologies coexist.