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!

GraphQL History

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

In July 2015, the team of Lee Byron, Nick Schrock and Dan Schafer, Facebook engineers, released the first GraphQL specification and the reference for its implementation in JavaScript, called graphql.js.
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).

How does GraphQL work?

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.

GraphQL is often referred to as a declarative data-fetching language. By that, we mean that developers will list their data requirements as what data they need without focusing on how they’re going to get it. GraphQL server libraries exist in a variety of different languages including C#, Clojure, Elixir, Erlang, Go, Groovy, Java, JavaScript, .NET, PHP, Python, Scala, and Ruby.

If you have any questions or suggestions about this article, feel free to post it in the comments!