What is GraphQL and Why Should You Care?
A new way of connecting data to apps may become the key standard in API best practices.
The GraphQL data query language has been a hot property in mobile app development since it became publicly available a couple of years ago. As with many technologies, there is often more urgency around the idea that organizations should be adopting GraphQL than there is understanding of what it does in practice (microservice architecture is another notable example of this).
The lack of understanding is forgivable given that “GraphQL” is a rather obscure name—conjuring visions of NoSQL databases and other niche technologies. But trying to understand this technology is certainly worthwhile for business and technology leaders focused on software strategies. Furthermore, the potentially significant value of GraphQL is reasonably easy to understand.
What is GraphQL?
GraphQL is less about graphs or databases and more about application development best practices. It simplifies the deployment and maintenance of API endpoints. The role of APIs in connecting backend services to frontend apps or enabling integration of diverse sources of data and functionality is broadly well understood, which is why the value of GraphQL should be relatively easy to grasp.
First, let’s take a quick step back and look at GraphQL’s history. GraphQL began as an internal project at Facebook, in 2012. Back then, the company was having some trouble developing a mobile app that matched the experience its users loved from the web, both in terms of functionality and performance. Clearly, this was a major problem and GraphQL was a big part of the solution.
It wasn’t that Facebook’s developers didn’t know how to build mobile applications, just that rapid evolution and ever-growing complexity made it difficult to fetch all the relevant data consistently. The web version of Facebook was constantly adding new features and evolving core functionality but the difficulty of connecting diverse data sources meant the apps couldn’t keep up.
A smart idea emerged from the Facebook News app team: to build an interface that would provide only as much backend data as was required for any given view. The implementation of this introduced a completely new technical concept: providing a query “shape” that would link the front and back ends via a JSON document expressing the data need of the query, followed by a response in the same shape (but with the values filled in). Like this….
This data “graph” exposes all the backend data that can be queried by the frontend app, through a single API endpoint, which integrates a selection of relevant endpoints. In doing this, GraphQL represents a break from the conventional protocol for creating web APIs—representational state transfer (REST). GraphQL integrates multiple REST API endpoints and hides them behind a virtual graph schema. Crucially, this means that APIs can be evolved behind the GraphQL interface in such a way that the frontend apps to not need to change.
Why Should You Care?
Hopefully, that description helps to make the technical details of GraphQL seem less obscure. If not, don’t worry. We’re less concerned here with those technical details than the real-world value they can deliver to a business. And GraphQL delivered a great deal of value to Facebook in terms of making it possible to keep mobile app functionality and performance on par with the web platform.
Good for them, you may say. But you might also ask why it is it relevant to your organization. The answer to that is quite simple. In 2015, Facebook publicly released GraphQL into open source, making it available for anyone to use in their projects. While GraphQL’s long-term fate may be open to question, there can be no doubting the immediate impact its release had on the API world.
The way GraphQL reimagines REST is significant here. REST is so ingrained that when IT pros refer to “APIs”, they usually mean “RESTful web APIs”. But GraphQL is changing that. Some experts consider it to be a significant evolution of API best practices, which could eventually replace REST. For example, GitHub now uses GraphQL in preference to REST, citing improved flexibility and efficiency.
A Note of Caution
So, could GraphQL empower you to evolve your APIs in ways that will make it much easier to improve app functionality and performance over time? Maybe but not necessarily. Presenting data as a shape is a powerful new concept but it may create a steep learning curve for developers who are used to the conventional tabular manner of presenting data. Initially, this may make it harder to be quick-to-market with new releases.
The other side of the same coin is that GraphQL encourages developers to use the functional programming paradigm. Functional programming is a very effective and well-established method of creating applications but many of today’s app developers are more familiar with the object-oriented approach. Again, this may steepen the learning curve and slow development, at least initially.
Security could be another concern. Because APIs expose backend services, they always create security issues that need to be addressed. The newness of GraphQL and the specific way in which it exposes data could lead to unforeseen vulnerabilities emerging, which smart hackers might be able to exploit. Given the current popularity of GraphQL, API security providers will need to be proactive about addressing this concern.
Still, it is certainly worth exploring what GraphQL can do for your organization. It may not replace REST as the key standard for APIs but it could add real value to your specific use case.