GraphQL is a relatively new API technology, but only a few of the common concerns are justified, expains Martin Buhr
GraphQL has recently become a source of much hype in our world of application programming interfaces (APIs). Originally developed in 2012 by software engineers at Facebook as part of a mission to build a better API for the news feed, GraphQL helped to overcome issues with the social media giant's native mobile apps crashing from multiple REST calls.
Traditionally, REST has been the de-facto standard for determining what an API looks like, serving as a set of rules that developers follow when creating an API. It is a useful tool for developer ecosystems looking to quickly onboard and work with an API, and can provide a very clear and specific interface to data.
GraphQL is the (relatively) new kid on the block - an alternative to other architectural styles like REST and RPC.
The difference is that GraphQL operates as a query language for your API, and a server-side runtime to execute queries by using a type system you define for your data. It isn't tied to any specific database or storage engine, and is instead backed by your existing code and data.
With the ongoing adoption of cloud services by companies and the architectural changes this entails, GraphQL is becoming a popular choice. It powers almost all of Facebook's data fetching and is used in production by some of the world's leading companies, such as Airbnb and IBM.
The benefits of a combined approach
The implementation of this technology for development teams only familiar with building RESTful services can be daunting. There are often fears over the time it will take to learn GraphQL, or limitations associated with an unknown approach.
However, there are multiple benefits of an approach combining REST and GraphQL, which will make the time and resource investment worthwhile.
Crucially, GraphQL can facilitate data fetching with just a single API call, which is particularly useful for data queries where multiple microservices are queried.
It acts as a 'smart' endpoint, living between the client and one or more data sources, receiving client requests and fetching the necessary data requested all at once. With REST, on the other hand, you'd need to perform two REST API requests if you wanted to request information from two objects.
Click here to access Delta's API research
GraphQL therefore uses its query language to tailor the request to exactly what you need, from multiple objects down to specific fields within each entity. This limits the amount of processing required, and when adopted at scale this can really add up in terms of savings.
The intuitiveness of GraphQL also allows for introspection so that developers can retrieve the schema associated with a GraphQL endpoint. This means that, unlike REST, GraphQL can autogenerate API documentation. The GraphQL API is tightly coupled with code, so once a field, type, or query changes, so do the docs - resulting in key time savings for developers.
Addressing implementation pain points
A key challenge that arises for businesses when considering GraphQL implementation is around legacy IT infrastructure and services. If legacy services are in play, likely with their code written in REST, businesses may be worried about the build, support and infrastructure cost of overhauling these.
Let's say you have different apps consuming your RESTful APIs, in an API portfolio where a single RESTful API may be used by many different teams or departments. You could likely achieve multiple benefits from using GraphQL to expose your company's data. However, it may not be feasible to rewrite the API in GraphQL and force the frontend consumers to adopt the new API.
In this case, developers need to adopt a solution that can stitch together all the existing services being used, including legacy code written in REST. This would allow multiple data sources, from different backends, to be funnelled together and made available in a unified GraphQL format.
At Tyk, we call this concept a universal data graph: a way to take all the data in your organisation, without having to change it, and access it all through a single interface with all the benefits of full lifecycle API management.
By combining GraphQL and REST services you can reap the benefits of both approaches concurrently; with REST providing a limited, simple choice of access and GraphQL providing a wider choice to utilise where appropriate.
To use a metaphor, REST is like a menu in a good restaurant, offering a small, but high-quality selection. GraphQL is like the kitchen: a pantry full of exotic ingredients where the chef has the control to pick the right ones to create and innovate as they desire.
Other pain points of implementing GraphQL may include concerns around the time it will take the team to learn the new technology, or limitations it might present further down the line, post-adoption. In some cases, a company may belatedly discover that it doesn't support some edge cases or a future roadmap for the system.
Although adopting GraphQL does carry those risks, companies can work with an API management provider to make the initial proof-of-concept and the production implementation of the new technology faster and easier. Using an API management platform may also allow in-house developer teams to tap into a wider network of skills, knowledge, and infrastructure to support them in building what they need.
Ultimately, with GraphQL, there is a learning curve, which isn't nearly as established as REST APIs, but that learning curve is worth it.
GraphQL is well-positioned to become the go-to technology for data access across all platforms. Although the technology is relatively new, the rate of adoption across various industries is impressive.
Using the right API management platform to leverage the benefits and power of GraphQL will allow businesses to ride the wave of this new technology, in turn putting the infrastructure in place they need to steal a march on their competitors.
Martin Buhr is CEO & co-founder of Tyk
