Putting REST to rest. Here’s why you should be using GraphQL!

The developer guild has been using REST as an architectural convention for building web services since Web Services became a thing in itself and gained popularity. But over time it has become rigid owing to the need of more flexibility and increased performance requirements by modern web services.

We as users have ever greater expectation from modern web services platform, we expect content to be served faster , in a seamless manner continually, with the rise in competition amongst different platforms , there is also a greater demand for speed , agility and performance.

Enter GraphQL, a modern way to fetch data from server.

So you may ask, what does GraphQL do that REST cannot , how is it going to optimize and improve the entire client server communication and help us build more agile , performant and reliable platforms.

Well here’s why :

• Saves multiple round trips : assuming we have to fetch blogs and the associated comments of each blog, we can fetch both the data sets in the same call instead of making multiple calls.
• Increases flexibility & performance : the client no longer has to request the data in the way the Backend developer designed the API, it has the flexibility to request only the specific fields that it needs thereby reducing the overall payload size as well as increasing the coherence between the view and the result data set requiring less transformations.
• Removes the dependency of the client(front end developers) from server(backend developers) : since the client has complete freedom to request only the fields it requires , and not conform to a rigid data structure provided for by the server, it eliminates the dependency of the backend developer for a front end developer.

GraphQL acting as an intermediary between Client and Server(Pic Credits : www.apollographql.com)

So What is GraphQL?

GraphQL is a query language for your API, and a server-side runtime for executing queries by using a type system you define for your data. … GraphQL isn’t tied to any specific database or storage engine and is instead backed by your existing code and data.

In layman’s terms , GraphQL acts as the intermediary between the client and the server fulfilling whatever request the client has by returning the resource(s) from the server.

You may however ask that why not let the client communicate directly with the server , why do we need an intermediary, well, the client may not necessarily ask for a resource from a single data source, and the server only returns a singular response, so this intermediary combines data from multiple data sources and serves that data in a single call to the client.

Imagine that you have three people who speak three different languages and have different types of knowledge. Then imagine that you have a question that can only be answered by combining the knowledge of all three people together. If you have a translator who speaks all three languages, the task of putting together an answer to your question becomes easy. This is exactly what a GraphQL runtime does.

To perform this operation, it depends on a schema, which is a capabilities document that has a list of all the questions which the client can ask the GraphQL layer. There is some flexibility in how to use the schema because we’re talking about a graph of nodes here. The schema mostly represents the limits of what can be answered by the GraphQL layer.

How does GraphQL work?

• The GraphQL schema : It is a strongly typed schema, which comprises of fields that have types. Types could be primitive(number, string, boolean) or custom(date). This system allows for rich features like having an introspective API and being able to build powerful tools for both clients and servers.
• GraphQL speaks to the data as a Graph, and data is naturally a graph. If you need to represent any data, the right structure is a graph. The GraphQL runtime allows us to represent our data with a graph API that matches the natural graph shape of that data.
• GraphQL has a declarative nature for expressing data requirements. GraphQL provides clients with a declarative language for them to express their data needs. This declarative nature creates a mental model around using the GraphQL language that’s close to the way we think about data requirements in English and it makes working with a GraphQL API a lot easier than the alternatives.

Drawbacks of using REST API’s:

The biggest problem with REST APIs is the nature of multiple endpoints. These require clients to do multiple round-trips to get their data.

REST APIs are usually a collection of endpoints, where each endpoint represents a resource. So when a client needs data from multiple resources, it needs to perform multiple round-trips to a REST API to put together the data it needs.

In a REST API, there is no client request language. Clients do not have control over what data the server will return. There is no language through which they can do so. More accurately, the language available for clients is very limited.

For example, the READ REST API endpoints are either:

• GET /ResourceName - to get a list of all the records from that resource, or
• GET /ResourceName/ResourceID - to get the single record identified by that ID.

A client can’t, for example, specify which fields to select for a record in that resource. That information is in the REST API service itself and the REST API service will always return all of the fields regardless of which ones the client actually needs. GraphQL’s term for this problem is over-fetching of information that’s not needed. It’s a waste of network and memory resources for both the client and server.

One other big problem with REST APIs is versioning. If you need to support multiple versions, that usually means new endpoints. This leads to more problems while using and maintaining those endpoints and it might be the cause of code duplication on the server.

The REST APIs problems mentioned above are the ones specific to what GraphQL is trying to solve. They are certainly not all of the problems of REST APIs, and I don’t want to get into what a REST API is and is not. I am mostly talking about the popular resource-based-HTTP-endpoint APIs. Every one of those APIs eventually turns into a mix that has regular REST endpoints + custom ad-hoc endpoints crafted for performance reasons. This is where GraphQL offers a much better alternative.

We will be covering more on GraphQL in the forthcoming posts so watch out for this space.