From REST to GraphQL
About GraphQL
GraphQL is a query language for APIs that enables declarative data fetching to give the client the power to specify exactly the data that is needed from the API. It makes it easier to evolve APIs over time.
GraphQL doesn’t have anything to do with databases. It isn’t an alternative to SQL or a brand new ORM.
In our organization, we have been using REST for building APIs from the beginning which was working quite well. But being a fintech company our requirements evolve very rapidly.
Data Fetching with REST vs GraphQL
With a REST API, you would typically gather the data by accessing multiple endpoints. In the example, these could be /users/<id> endpoints to fetch the initial user data. Secondly, there’s likely to be a /users/<id>/posts endpoint that returns all the posts for a user. The third endpoint will then be the /users/<id>/followers that return a list of followers per user.
With REST, you have to make three requests to different endpoints to fetch the required data. You’re also over-fetching since the endpoints return additional information that’s not needed.
In GraphQL on the other hand, you’d simply send a single query to the GraphQL server that includes the concrete data requirements. The server then responds with a JSON object where these requirements are fulfilled.
Using GraphQL, the client can specify exactly the data it needs in a query. Notice that the structure of the server’s response follows precisely the nested structure defined in the query.
We had to expose APIs to different external vendors, we were building our mobile app. Though both of these could have been done by REST APIs, GraphQL seemed to be a better option due to the points below:-
No more Over- and Under fetching
One of the most common problems with REST is that of over-and-under fetching. 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 so that it can provide clients with their exact data needs.
Over-fetching means more data is returned than required, thus increasing the data transfer over the network making applications slower.
Under-fetching means all the data required is not returned, and more requests are to be made to get the required data. Thus increasing response time.
These latencies become more noticeable with a slow network, which might be the case with many mobile app users.
Authorization at a field level
REST APIs give fixed responses for all authorized users with GraphQL you can have authorization at a field level. This is helpful for us in the case of APIs for the external vendor, so they can’t fetch any data they are not authorized to. In the case of REST, we would need to build multiple APIs for restricting this.
Insightful Analytics on the Backend
GraphQL allows you to have fine-grained insights about the data that’s requested on the backend. As each client specifies exactly what information it’s interested in, it is possible to gain a deep understanding of how the available data is being used. This can for example help in evolving an API and deprecating specific fields that are not requested by any clients anymore.
With GraphQL, you can also do low-level performance monitoring of the requests that are processed by your server. GraphQL uses the concept of resolver functions to collect the data that’s requested by a client. Instrumenting and measuring the performance of these resolvers provide crucial insights about bottlenecks in your system.
Self-documenting
Every GraphQL API conforms to a “schema”: the graph data model and what kinds of queries a client can make. This allows the community to build lots of cool tools to explore & visualize your API or create IDE plugins that autocomplete your GraphQL queries and even do “codegen”.
Implementing GraphQL
Having said all of that, it’s easier said than done to move all the API from REST to GraphQL if you already have your infrastructure build. The same was the case with us. Actually, it’s not an either-or choice between REST and GraphQL, they both can co-exist and we went ahead with the same.
There are 2 ways to make GraphQL APIs from existing REST APIs and have both of them in place. They both have their own advantages and disadvantages as discussed below.
Stay tuned for more upcoming blogs on how to implement it, along with some advanced features like field level Authorization with Oauth or JWT or both. Along with centralized logging of all the requests and responses and latencies to be used for the various types of analytics and visualizations as and when required.
Shivam Agrawal
(shivamagrawal1129@gmail.com)
Senior Software Engineer
Indifi Technologies
