Over the past decade, the web and its data requirements have changed dramatically. When REST APIs came out, SOAP was the predominant methodology for obtaining data from a database. The main thing that allowed REST to take off was its ability to easily communicate data for the frontend to consume.

However, over the years, data requirement complexity has increased. This is increasingly complicated by the different views and user experience requirements for different types of devices and interfaces.

Why is that?

In part, it’s because REST APIs are intricately linked to the frontend views. As frameworks, libraries and platforms come out with new ways to quickly prototype, the backend’s ability to keep up with the speed of changes required is simply not working out with REST.

This is where GraphQL comes in. But what exactly is GraphQL? How does it work? And what’s the difference between REST and GraphQL?

Why GraphQL over REST API?

GraphQL has its origins at Facebook. During the time of its development, Coursera and Netflix were also developing something similar. Why is this important? Because it signifies a problem that REST doesn’t address – the need for APIs to be able to adapt to the rapid changes required by the frontend.

While REST is a robust methodology of creating APIs, it’s not elastic in nature. With increased frontend scopes, along with the growing need for iterations and expectations for rapid feature development, an application stack with REST APIs requires time for coding. Why? Because REST requires individual creation of each API.

For example, let’s take a look at a hypothetical set of endpoints requirements for changing an item in the cart.

v1/get/item/{id}
 v1/post/removeItem/{id}
 v1/post/item/quantity/{quantity}
 v1/post/item/setVariation/{id}
 v1/post/item/removeVariation/{id}

This is just a quick rundown of what APIs could be made. There’s still the cart management itself, shipping details, promotion codes, special user features, cross sells, upsells and whatever else marketing and UX designers can think up to increase sales.

With REST APIs, you need your backend developers to create an endpoint for all your data requirements. But what if you’re still a bit fuzzy on what you want? What if the business decides to change the requirements midway and come up with a new design? What if the design requires a completely different way of thinking about the data?

All these questions need to be addressed by both frontend and backend developers, resulting in a longer time to production and potentially making work completed a sunk cost to the team.

GraphQL addresses these issues by giving the frontend more power when it comes to data needs.

How does GraphQL work?

In a nutshell, GraphQL is a data query language. It lets you interface with a backend implementation that connects up with the database. The backend is still responsible for access controls and deals with how data gets passed between the frontend and the database.

However, GraphQL removes the backend requirement of needing to create specific endpoints for each type of data needed. With GraphpQL, a developer only needs to call a single endpoint and go from there.

This simplifies the process of moving data through APIs and significantly cuts down on the work required every time something new or changes crop up in the specifications.

While GraphQL has been predominantly associated with React, it can be used anywhere and not limited to the library. The association came about due to it being created by Facebook and its initial launched with React.js in 2015 at React.js Conf.

GraphQL allows the frontend to dynamically iterate and design data based on their needs. The frontend developer own needs to send a single request.

Why is being able to dynamically iterate and design data a big thing?

While a REST API may be stateless and creates a structured methodology for accessing resources, its major drawback is the high possibility of over or under fetching.

Why is this a problem?

When it comes to mobile-based devices, data size is crucial to the speed of the application. Unlike desktop-based environments where internet connection is generally more stable, mobile network speeds can vary depending on location, service providers, and service areas. The smaller the dataset, the better chances of your user remaining calm and not get frustrated by the slow load time.

Over fetching data results in unnecessary data being transferred. Under fetching can end up with a n + 1 issue – that is, for every additional piece of data required, an additional call API call is needed. So your API calls can result in a tree of calls, which can slow down the responsiveness of your application because of the wait time in between each API.

In contrast, GraphQL lets a developer create dynamic data based on the view’s requirements and only call what’s needed. The query is based on an understanding of how data is structured. In contrast, a REST endpoint will have specific requirements, meaning that documentation is required for every single endpoint.

GraphQL in the backend is implemented based on the schema called Schema Definition Language (SDL). The schema sets the general structure for accessing data. For example, to access the item’s table, a backend developer can set the SDL for GraphQL to something like this:

 type Item{
     name: String!
     quantity: Int!
     availability: Boolean!
     variations: Boolean!
     variationList: Array!
     maximumPerCustomer: Int!
     unitPrice: Double!
     shippingClass: String!
 }

All the data above will be accessible by the frontend. However, unlike a REST API, where you’ll end up getting everything, including things may not need for your view, GraphQL lets you create queries and filter a return of data based on what your view needs.

For example, a query for just the name and unitPrice might be required for one view, and only name and shipping class is required for another. Rather than the backend needing to create two REST APIs, the frontend developer can create two queries to the same endpoint.

A rundown between REST and GraphQL

REST

• multiple endpoints
• data structure is controlled by the backend
• provides stateless servers and structured access to resources
• frontend has no control over how and what the data looks like
• structured against the view it serves. This means that the backend is required to create new APIs or adjust existing ones to serve the correct amount and type of data. This can lead to longer time to production and slow down the development process.

GraphQL

• single endpoints that take in dynamic parameters
• allows for more dynamic development once implemented
• provides stateless servers and flexible controlled access to resources. While in REST, it’s complete control and the data is given based on what the backend has coded, GraphQL puts controls on what can be accessed but leaves the structure of data to the frontend.
• only sends a single request in the body and includes a query that contains all the data requirements. This brings data into the frontend and reduces the amount of workload required on the backend to adjust to the changing needs of data requirements.
• the root field will return a data field with all the data you want and in the format you need it
• allows for rapid iteration and faster feedback for the business

What does this mean for the future of REST?

REST APIs are still relevant and aren’t going to become obsolete when you wake up tomorrow. A majority of the web is still structured in a RESTful manner. However, GraphQL is making headway into the development world as more and more developers adopt it into their application building process.

GraphQL has been around since 2012 but just started to gain traction in the past few years as developers look for ways to increase their output and overall productivity. REST will still be around, but the space of data access and controls is being shared with GraphQL as the query language becomes more mainstream.

More cloud-based providers are also taking up support for GraphQL as part of their product offering. This reduces the overall time required to get an application built by reducing the task of creating a backend to control data access.