Graphql – Changing and Improving the Way Applications Communicate

It will not be long before the next generation will be buying crypto and checking their unit trust balance in the Fortnite lobby in between games. This will be enabled through many technological advances.

The one we are discussing today is the way data is transferred (read, updated, added/removed) between applications and the companies that own them. Application programming interfaces (API) are the architecture that define this data communication and, as these standards have developed, processing requirements and data storage requirements have become less arduous.

The leader in the pack in terms of “’lightweight’ resource usage is GraphQL, an open-source data query and manipulation language. Its ecosystem’s foundation is its specification and a collection of tools that has been created around it.

It is not new – time moves fast. Facebook developed it in 2012 and used it only internally for mobile application development. In 2015 it was ‘open sourced’ and today it is looked after by the GraphQL Foundation (https://graphql.org/foundation/) which oversees its further development.

So why am I writing about it now? A typical roadmap to a technological adoption will follow the following uptakes 1) hobbyists/personal projects, 2) implementation across multiple languages, 3) implementations across start-ups and small companies, 4) medium-sized companies and used in product development, 5) large corporations and tech giants.

GraphQL has reached level 5. Currently it is used by GitHub, Pinterest, Shopify, Microsoft to name but a few and most recently, as of March 2022, Salesforce.

In looking for a way to fetch data more efficiently from Salesforce I came across their GraphQL documentation and started reading and looking at ways to implement it.

How does it differ from a traditional REST API?

• One of the major advantages is that with GraphQL you can query and only have returned that specific data. If you only want two fields related to a specific client incident, then that is what you get. A traditional REST API would return to you ALL the fields associated with the incident. That could be 100+ fields. Now you must do something with all that data you didn’t want to begin with. This is referred to as data over fetching (under fetching is also an issue).
• The above makes GraphQL faster than other API methodology when returning data.
• GraphQL is a strongly typed language which amongst other things means code errors are picked up before the program runs and not during it.
• A great set of tools have been built around GraphQL which has made it very developer friendly.
• GraphQL has a single end point as opposed to REST API which has multiple endpoints. This means that all your data can be fetched in a single request.

Two sides of the coin: requestor (client) and provider (GraphQL host)

I have looked at GraphQL so far from the data “request” perspective. Where a company such as Salesforce or Microsoft have set up a GraphQL API that you can use to query and manipulate data (read, update, add).

As an example, if we wanted to include data from Salesforce related client incidents into a client portal, the most efficient way to do this would be to request the exact data we are after through a GraphQL query from the portal to the Salesforce GraphQL server. You will get exactly the data you want, no under or over fetching and as a result no additional processing or data storage would be required.

The other side of the coin is the organisation that sets up the GraphQL architecture so that your clients can have an efficient method to access to the data they wish too.

In building the GraphQL API an organisation is creating a model that integrates all their systems into one model. It unifies these systems and once done removes the complexity of the underlying system. Once the work is complete, querying the data becomes seamless through the API.

When comparing applications or providers, I look at what functions they offer me to get my data back from them. I do not want to have to email them or rely on rigid predefined reports. I want to be able to “plug into” my data querying it in a flexible, timeously manner. If it comes down to two applications/providers and they are similarly matched on other comparison points, and one offers either a REST API or a GraphQL API, I will most certainly choose the one with the API.