Gone are the days of statistical web pages. The Internet is facing a huge mass of end devices, and all of these devices have the same interest in uploading data as quickly as possible. We need high-performance applications and a good, ever-improving infrastructure to do that graphQL could be involved.
In addition, fast mobile apps make users happy and bring more money to providers. The history of the internet and the future of the internet have been and always will be about the fast delivery of data from the server to the client.
What is GraphQL?
“GraphQL is a query language for APIs and a runtime for performing these queries with existing data” (https://graphql.org/).
GraphQL is transport-independent but is usually provided over HTTP. The great thing about GraphQL is that only the required data can be requested.
Traditionally, data has been consumed through REST (Representational State Transfer) APIs. It is common to provide and deliver complete entities in the REST process. And here is exactly what GraphQL is trying to solve
Often, we only need a small part of the entities and we still receive them in full. This leads to so-called “overcrowding”. Sometimes we need more entities, so the so-called “under fetching” occurs at every request.
The GraphQL API provides developers with a single point of entry where the query can request customized data. A developer can describe the required data with a syntax.
Here, the query is nested and several associated objects can be delivered. Each query to the GraphQL endpoint is validated with a type system. Individual services define types in the GraphQL Schema. The type system can be considered a model for API data.
The origins of GraphQL
Facebook invented GraphQL in 2012. At that time, Facebook launched its app in the App Store, and in doing so, they realized that the app generated a lot of requests to their API. At this time, the Facebook application was very poorly rated, due to the fact that it was slow and consuming too much energy.
In the world of REST APIs, Facebook has had to make a lot of requests to different endpoints. They had a cascading effect on endpoints. Facebook engineers have realized that they need to improve the way the server sends data to the client.
The initial GraphQL specification and reference implementation of GraphQL in JS was released in July 2015. By 2016, GraphQL had left the preview stage, which meant that it was officially ready for production. Today, many different companies use GraphQL in their production.
History of data transport
To understand the new idea behind GraphQL, we need to first look at how data transport worked in a historical context – thinking about data transport and understanding how data is exchanged between systems.
Remote procedure call
James E. White developed the basic idea of RPC in 1976. RPC stands for Remote Procedure Call. A client sends a request to do something to a remote system. Clients and servers differ, but the request/response pattern was fundamentally the same.
SOAP
After that, Simple Object Access Protocol (SOAP) appeared at Microsoft in the late 1990s. SOAP uses HTTP for transport and XML to encode a message. It also used a type system, but SOAP complicated implementation.
REST
So in 2000, REST was defined by Roy Fielding. His idea was a resource-oriented architecture in which web resources are used to perform operations such as GET, PUT, POST, and DELETE.
It is not a protocol or a standard. You can imagine it as a set of architectural constraints. The developer can implement REST in their APIS in a variety of ways.
At first, developers used REST with XML, but soon after, JavaScript Object Notation was popularized by Douglas Crockford. It is a much more elegant data format that can be analyzed and consumed by many different languages.
There is also a clear separation between Client and Server within the REST architectural style. REST is the most convenient technology to use so far.
But everything has its drawbacks, and in the following, we want to look at them.
REST Disadvantages
Even though I am writing about the disadvantages of REST, REST is not dead and will probably not die soon. He is good at doing his job.
Excessive takeover
As mentioned above, REST has a problem with overloading. Excessive obtaining describes the situation in which you request data, for example, for an author of a book.
Then you’ll probably get an ID, a name, and maybe their birthday. But there may be more data stored for the author, and the server will return each field, even if the client does not need it
Insufficient takeover
Underfetching describes the exact opposite of over-etching. Too little information is returned, so more endpoints need to be queried to collect the appropriate data.
For example, you want to get more details from the author’s book. Therefore, you may be asked to call the author API first, which returns all author data and a series of endpoints for more information about the book.
Endpoint management
Today, modern web applications are heavily data-driven, requiring the retrieval and combination of many different data and data sources. The developer must call many other endpoints to collect the required data. All of these endpoints need to be managed.
REST is, for this reason, lacking in flexibility. The developer must maintain the endpoints, add new ones, and delete the old ones. Because GraphQL provides a single endpoint, you do not need to manage endpoints
Network request
Another point is the network load produced by calling many endpoints for data collection, even if you don’t need them all.
REST is static
The data is stored in a specific way, and the developer will get the data this way. Adjusting something is associated with more significant effort. For example, the developer must remove the API version if it adds additional fields not previously included for a POST endpoint.
Version
The above point has already shown us the problem of static implementation of REST. The developer needs versions to manage it and there is probably no right way to do it.
“It’s probably the easiest thing to do.”
(Issue # 5, https://leapgraph.com/what-graphql-solves/)