Today we are going to explore GraphQL as an alternative to REST API. But before we begin with GraphQL, let’s first understand how the web works.
All of us have been to restaurants at some point of time in our lives. When you visit a restaurant, you first sit down and ask for the menu. The waiter or waitress then brings the menu and hands it over to you. You then scan the menu and decide what you want to eat. Once decided, you again call the same waiter and give them the order. Then the waiter goes back to the kitchen and after some time comes back to serve you some delicious food.
This is exactly what happens on the web too.
On the web, we have a client which is our browser (like Chrome) and the server which is connected to the database. Our client wants to get data from the server similar to you asking for a certain dish to eat from the kitchen. So first it asks for the menu or in technical terms the “endpoints” exposed to ask for data. Then it decides what endpoint it wants to call and sends a request to the server. The server then responds back with the requested data to the client. In this entire scenario, where is the API then? The API is our waiter. Like the waiter, the API exposes the endpoints to us and facilitates the exchange of data between our client and server. The data exchange happens in a standard format called as the JSON format.
Now let’s look at GraphQL. GraphQL is a query language for APIs. So the ‘QL’ stands for query language and ‘Graph’ denotes the way we envision our data which is connected like a graph as you see in their logo here.
So what makes GraphQL different? Well, it’s the way in which GraphQL let’s us interact with our data. Traditional APIs have a fixed format for the data the client can get back but GraphQL gives us the flexibility to ask for exactly what data we need. So it’s like going to a restaurant and asking for the specific toppings we need on our pizza vs choosing a pizza with predefined toppings.
GraphQL was developed by Facebook in 2012 and later open-sourced in 2015. If you look at Facebook on the web vs on your phone, there’s definitely lesser data displayed on the phone due to the size restriction of the device. Hence, the API tailored for the web would return a lot of redundant data which would take even longer time to access on the phone. Plus, phones have low connectivity but people still want instant access to their data and enjoy the same user experience. All these factors contributed to the development of GraphQL within Facebook.
Continued in Part 2
Comments