Most web and mobile applications institute client – server communication. Acquired data are used in the app’s internal processes. Nevertheless, you must know that the beginnings were tough and didn’t provide any models of proceedings. Engineers tried to create a standard which would make the manner of communication more legible and easier to implement. Examples of such standards are REST and SOAP. Unfortunately, nothing in the world is perfect. REST is used most frequently being a main player and overtaking slightly older SOAP. However, years of using REST have shown its shortages which arose due to changes in the world of web and mobile applications. Main instigators of those alterations were mobile apps which constitute larger and larger market share.
Progress = new problems
Mobile devices have become a chief tool for using the internet resources, yet smartphones have limited computing power and memory. Although their efficiency is constantly rising, the level is still much lower than in laptops. Another constraint is the battery that always runs out too soon :). That’s why we want the apps to encumber batteries in the least. After initial analysis, it has been established that a triggering factor can be the amount of uploaded data. We send too much and not use enough of it.
Somebody had to come up with proper solutions. In 2012 Facebook app had a substantial user flow so the server – client data exchange was extremely large.
Facebook programmers decided to solve the problem by creating a new manner of communication which would limit the amount of sent data.
Appropriable reasons were:
- higher usage of mobile apps
- low power devices
- impaired internet connection which makes it difficult to send larger data files
Technical reasons were:
- over-fetching
- under-fetching
- alterations generated in API REST
| You may also be interested in: GraphQL on Android with Apollo Client How did GraphQL let us overtake the REST All you need to know about CloudKit Art |
GraphQL – new solution
So, what is this new Facebook tool? Actually, it’s a query language based on a type scheme created with API. Data is presented in the form of a graph – and that’s where the name came from. The solution was published in 2015 as an open source. Today, it’s developed and available in all popular programming environments. As opposed to REST, GraphQL uses one endpoint which provides all the server-side data. Decisions about the number and type of data are transferred to the client-side which means that the app decides what it wants to get from the server in this particular moment.
Major REST’s problem is a consistent scheme of acquired data. Example: App displays user’s name, so it downloads data from API. In REST, endpoint response has a consistent number of attributes compatible with the user’s data. In GraphQL, we are able to determine what we need from all the available data reducing the business of the response. In the presented example, what’s downloaded from the server is only the user’s name and nothing else. Using such a solution, programmers don’t have to modify the backend and create a special endpoint to provide only the user’s name.
Solved technical problems:
- Over-fetching
The problem lies in downloading data’s structure which consists of a large number of attributes. We have data that will be used in the application.
- Under-fetching
The problem is that downloaded data is insufficient. That’s why we have to send another query to the server and ask for additional data.
In both cases in GraphQL we only download the data we currently need.
Changes in API
Created endpoints in REST approach have a defined structure. To download additional data, programmers have to modify existing endpoints or add supplemental ones to fulfill the needs of the client’s layer. Besides, the client’s layer is not resistant to unexpected changes in endpoints which can lead to instability of the app’s operation. This kind of process is an additional burden also for the client’s budget.
Summing up
GraphQL approach solves basic problems and is used more and more frequently. Will it substitute the REST approach? Rather not, but it’s a stron alternative showing that some elements can be managed better.
