Introduction to GraphQL
REST vs GraphQL

The API-Rest architecture suggests that we should retrieve its data according to the routes we are requesting. Let’s say that you want to get the data for a user in our system with id=1. If we were to ask the API for this data, we would need to make a GET request to /users/1 to retrieve this user’s data.

Now, let’s assume that we have posts associated with this user, and we want to ask the API for both the user and its posts. Given how REST works we would have to query for the user /users/1 and its posts /users/1/posts , no big problem… BUT! We are making two queries to get the data we need, this means that we will have two roundtrips just to get a user and its posts. To solve this, we may have to create a new endpoint to get all the data at once, but we may still have prone issues.

Another big problem with the REST architecture is that we are prone to get more data than we want. Imagine that we have a profile view of our application. This view shows user data like name, nickname, bio, etc.

And posts basic information like title, date of creation, and the number of comments for each post. When we request the API for the posts information for this user we will get all the posts information (title, comments, body, replies, etc.). That’s good, but we only want to display the title, number of comments, and date of creation. So, therefore, the body information is unnecessary.

This problem is called Over-fetching, similarly, we could need certain post data that isn’t provided to us by the queried endpoint and have to make another request to a different endpoint to retrieve the missing data, this problem is called Under-fetching.

GraphQL, on the other hand, arises from the necessity to address both problems by implementing a single endpoint and a query language!

By defining types, queries, and mutations we can ask for whatever data structure and its nested associations in our schema with only a single query.
['Felipe Cabezudo']
['API', 'Rest', 'GraphQL']