GraphQL is an open-source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data.
GraphQL was developed mainly to cope with the need for flexibility and efficiency! The goal behind it was to make it omnipresent across web platforms. It solves many of the shortcomings that developers experience when interacting with REST APIs.
Features of GraphQL
GraphQL allows clients to request and manage data from APIs through request-response protocol, which runs on top of HTTP.
- It is a very good fit for complex system and microservices.
- It can fetch data with a single API call.
- The introspection feature of GraphQL allows for navigation into the types and discovering the schema so that apps only ask for what is possible and in the appropriate format.
- It provides detailed error message from the backend including all the resolvers and referring to the exact query part which is at fault.
REST vs GraphQL
Data fetching
REST APIs generally don't provide any proper way for client applications to retrieve or update only the data they care about. This is often described as the “over-fetching” problem.
This happens because the only way for a client to download data is by hitting endpoints that return fixed data structures.
It’s very difficult to design the API in a way that it’s able to provide clients with their exact data needs.
REST causes over-fetching or under-fetching, whereas this isn’t the case with GraphQL. In GraphQL, you get what you ask for.
Smaller payloads
In RESTful API, there are no partial payloads you get everything in every request, every time. So if you don’t need everything, that's unnecessary bandwidth.
In GraphQL, you specify the exact types and fields that you need; and if you don’t need much, that introduces the potential to make your API requests smaller.
Versioning Is Not Required
In REST architecture, developers create new versions due to changes in resources or the request/response structure of the resources over time. Hence, maintaining versions is a common practice.
With GraphQL, there is no need to maintain versions. The resource URL or address remains the same.
Rapid Product Iterations
A common pattern with REST APIs is to structure the endpoints according to the views that you have inside your app.
This is handy since it allows for the client to get all required information for a particular view by simply accessing the corresponding endpoint.
The major drawback of this approach is that it doesn’t allow for rapid iterations on the frontend.
With every change that is made to the UI, there is a high risk that now there is more (or less) data required than before. Consequently, the backend needs to be adjusted as well to account for the new data needs. This slows down productivity.
With GraphQL, this problem is solved, changes on the client-side can be made without any extra work on the server.
Since clients can specify their exact data requirements, no backend engineer needs to make adjustments when the design and data needs on the frontend change.