Well, welcome to this "wonderful" article about GraphQL!
If you fell here, you are probably learning about GraphQL or researching it.
This is the first of some articles that I will publish here about GraphQL.
Because of this, and in order to provide you with a delicate reading, I will do my best to explain in detail all the concepts that are likely to cause some doubt regardless of your level of familiarity with the topic covered here ...
For this I will use the redundancy methodology that consists of repeating the same thing in different ways and with different examples in order to place the same content in different parts of your brain!
Tip given, let's do it!
Chapter 1: Genesis
In 2012, Facebook decided to rebuild its native mobile apps (iOS and Android).
The applications' performance was not very good because they were having constant crashes. At that time, Facebook had a RESTful server and its data was in FQL tables (an SQL version of Facebook).
Due to the problem with their native applications on mobile versions, Facebook engineers realized that the problem was caused by the way the applications received the data.
(Probably they sat down, had a cup of coffee and discussed the problem)
The engineers then decided to improve the way data was being sent to applications.
This decision resulted in a query language that would describe the features and requirements of the data models for the company's client / server applications.
Chapter 2: The big (or misunderstood) battle
As of September 2016, it was officially ready for use, although Facebook has been using it in production for a few years.
But, on the other hand, there was the REST created in 2000 and that had been in use for a long time.
REST stands for Representational State Transfer, it relies on a stateless, client-server, cacheable communications protocol -- and in virtually all cases, the HTTP protocol is used. REST is an architecture style for designing networked applications.
When GraphQL came into existence, many programmers believed that it came to replace REST.
The controversy was big and sparked debate at conferences, but calling GraphQL a REST killer is an oversimplification. A more subtle view is that, as the Web has evolved, REST has shown signs of tension under certain conditions. GraphQL was created to alleviate this tension (which will be explained in the next chapters).
GraphQL is a syntax that describes how to ask for data, and is generally used to load data from a server to a client.
It’s also a runtime for fulfilling queries with your data. The GraphQL service is transport agnostic but is
typically served over HTTP.
The query is nested, and when it is executed, can traverse related objects. This allows us to make one HTTP request for two types of data. We don’t need to make several round trips to drill down into multiple objects. We don’t receive additional unwanted data about those types. With GraphQL, our clients can obtain all of the data they need in one request.
Whenever a query is executed against a GraphQL server, it is validated against a type system. Every GraphQL service defines types in a GraphQL schema. You can think of a type system as a blueprint for your API’s data, backed by a list of objects that you define.
If you have any questions or suggestions about this article, feel free to post it in the comments!