At Cogoport, we decided that to keep up with the increasing demands of our customers, it was necessary to change the way we designed our Application Program Interfaces(APIs). Read on to find out more.
Introduction to API
Before getting into the migration, one needs to understand what an API is. The application program interface is a set of protocols that can be defined to act as a messenger between the client and the server. When data is requested, the API needs to take the request to the provider and return with the required data. Each of these interfaces enables frontend and backend of a website to share data among each other.
The use of REST
The Representation State Transfer (REST) protocol is the most popular approach to building APIs and communicating with client applications. In our early days, having a limited number of client applications communicating with the server, REST helped us get up and running very fast. The APIs designed with this method returned data structures as per the requirement.
Although this system efficiently delivered at the beginning, it became quite problematic as our organisation grew. As the number of clients increased, so did the variety of requirements. The client often required only a part of the data stored in the server, but the APIs designed with REST did not have the function of providing so. This often led to cases of over-fetching from the server, which was quite problematic as it degraded the performance of the product. The solution to this problem was revamping the backend for every different request, which would make it a time-consuming process and not efficient at all.
The mobile view of the website was the other problem being faced by us. The data to be displayed on the mobile view of our website was usually different than that shown when the site is open on a desktop. With REST, we had to create separate APIs for both mobile and desktop, which meant writing a considerable amount of code.
Hence we concluded that it was time to try a different approach.
GraphQL to the rescue.
To solve the problem of over-fetching, we required a method that would allow us to design APIs that let the client fetch only the data that is required. We fulfilled this need by using GraphQL, a language launched by Facebook in 2015 to design APIs.
GraphQL allows the backend to develop a schema, which is nothing but a syntax that describes the functionality of the server to the client. With this schema, the server lets the client know all the data it has and the way to fetch it. The client can send in a query of what it requires. These queries can often require data from multiple fields stored in the server. To answer each of them, the server allocates a resolver function to every type of data. Hence, when a client is asking for different kinds of data in a single query, the server can send it systematically.
GraphQL has successfully provided a solution to many of the problems faced by us at Cogoport, while using REST. We no longer have to keep altering the backend for every change we make to the UI. Just a simple schema does all the work. The mobile-view of our website no longer over-fetches as it can request the server for exactly the data it needs.
Implementing a new method for designing our APIs has saved our developers from writing redundant code for the same feature, thus saving a lot of time. GraphQL ensures a smooth transaction of data between the frontend and the backend, making it easier to evolve APIs over time.