GraphQL (query language) was the brainchild of Facebook and was open sourced in 2015.
Many of the apps and websites we use are built on GraphQL, including Twitter, AWS and GitHub.
Goetsch writes as follows…
GraphQL is a layer that sits on top of REST APIs, any application or data store — and it makes the process of data retrieval and extraction across multiple APIs easy.
Say you’re a developer for a retailer tasked with rendering a page for a product. You’ve already built a catalogue of 300 REST APIs and now need your product detail page to access data including product description, price and similar item information.
It may be 10 APIs, could be 200.
You could individually call each API one-by-one, but that could take a while… and calling many different APIs, which exist with a minor or major variation can be difficult in a microservices environment. You might not know which ones to call and which ones would provide the freshest data – the warehouse management system, or the Enterprise Resource Planning (ERP) system, or other?
One query to rule them all
With GraphQL, to consume REST APIs, you simply submit one query describing the information you need… and then the GraphQL layer does the legwork, making direct calls to the individual APIs.
As a result, you get back one JSON object with the exact data you requested, no less, no more. You can think of it like a SQL query where you make a request to a database, ‘select X from table 1 and join it with table 2’.
GraphQL solves a lot of headaches for developers. As well as being able to render webpages, app screens and other experiences in the first instance faster, there is no problem of under- or over-fetching data.
Under & over-fetching data
Under-fetching data can be a common issue with REST APIs and kit will especially affect devices with limited processing power like old smartphones connected to high-latency, low-bandwidth cellular networks. Making lots of HTTP requests can mean significantly increased page loading speeds.
Data over-fetching can cause severe performance issues too, for example building your product page for a smartwatch. You’d only need the product name, image and price but could get back a hundred fields.
GraphQL offers numerous advantages.
Since it is the GraphQL layer that calls all the APIs and not the developer, there is less code to maintain. Plus, as GraphQL makes all its requests within a datacentre where latency is almost zero and computing power is virtually endless, applications are loaded faster for the end-user.
And because GraphQL is the layer that decouples back-ends from front-ends, it is easy and quick for developers to change things, useful for IT teams under pressure to continually test and launch new improvements.
What else ya got?
What else should developers know about GraphQL?
GraphQL is not a product or implementation, it is a specification, so it makes no difference which programming language you use. You as the developer write the code that conforms to the specification. Imagine it like HTML whereby individual browsers implement the code that renders a web page. Furthermore, it is a supplement to REST APIs – it doesn’t replace them.
As is the case with most tech, there are downsides. GraphQL is a layer that needs to be maintained, the user is responsible for security, and it can be a challenge to combine several GraphQL endpoints and schemas.
However, the benefits of GraphQL far outweigh the costs.
In an increasingly competitive marketplace commerce players need to leverage the tools that enable them to be as agile as possible, save time and deliver superior customer experience.
When building commerce applications, GraphQL is the ideal tool for the job.