Emerging Technology, GraphQL, is a Boon for eCommerce
Moving data from one place to another in the most efficient fashion is a problem that the computing industry has been trying to solve for years. Yes, our networks today are faster and more reliable than ever, but we’re also trying to push more and more data over those pipes. We’re also using more mobile data than ever, and while mobile networks are better than ever, there are also more devices using them every day.
Over the years, we’ve had multiple technologies promising to be more efficient, easier to use, and so on. I’m not going to bore you with the history of data transfer protocols, but the current technology ‘du jour’ is REST or representational state transfer. REST has been consistently increasing in usage over the former most-popular technology, SOAP. This is due to a number of advantages that REST provides; it’s generally easier to work with, and generally uses less data than SOAP because it dispenses with XML.
Today, we’ve got another option which has been growing in popularity over the last few years called GraphQL. Invented at Facebook in 2012, and open-sourced in 2015, GraphQL describes itself as ‘a query language for your APIs’ and provides a way to not only use fewer network resources but also to use fewer front-end resources, improving performance across the board.
The Trouble with REST
REST is a great technology, make no mistake, and GraphQL isn’t a replacement for it, but an augmentation, one which addresses some of the issues inherent in REST’s design.
REST handles data as resources, so each REST endpoint can return resources of a specific data type. Sometimes resources are linked with other resources. For example, when you place an online order through a commerce site, there’s lots of data associated with that order. A pretty common use case is reporting — let’s say we want to get all orders placed in August of 2018 by customers between the ages of 15 and 25. So there are multiple pieces of data we’re asking for — orders, products, and customers. This quickly devolves into multiple calls to the backend for each object. This is commonly referred to as ‘underfetching’ — in other words, not getting back all of the data you need, so having to request more.
Another typical issue with REST is just the opposite — ‘overfetching’. Maybe we just need a list of orders with customer names associated with them. With a traditional REST approach, you’ll end up with all of the blog content too. If your app talks over a mobile network, you definitely don’t want to overfetch.
I’d be remiss if I didn’t mention at this point that REST is just an architectural style. GraphQL has a spec — over 200 pages that go into great detail about how to design your schema. REST is a bit more ‘wild west’ — the only specification you have is whatever the server happens to give you.
Everything Is a Graph
This isn’t going to turn into a discrete math lesson, but it’s an instructive way to think about modeling things. Computer science is all about modeling real-world objects and reasoning about how those objects work together.
In graph theory, a graph is a way to pictorially represent objects and their links to each other (orders to products and customers, etc.). So, we’re giving our data a shape.
One thing that GraphQL helps us do is to specify the shape of the data we’re requesting. If we know what the data we’re going to get back looks like, it’s a lot easier to reason about.
How GraphQL Addresses REST’s Limitations
GraphQL provides answers for REST’s traditional problems of both overfetching and underfetching. How does it do this? It provides an interface for specifying the exact data you are asking for. In other words, it gives us a language for specifying the shape of the data we are requesting.
For example, I can ask for a blog post with its author and content in one network call, and I can ask for exactly the fields I need. This solves two problems: less network traffic so a faster response, but also, since you get exactly the data you need, your front-end logic can be much simpler. No more poring through multiple REST responses for the data you need; you’ll get everything you need back with GraphQL.
Another nice feature that GraphQL provides is introspection. The GraphQL server knows what queries it supports, which means you can query it for supported functions — but it also enables field completion help. So, if I’m writing a GraphQL query, that’s going to reduce my development time since I don’t have to worry about what the right field names are.
Of course, it’s not all fun and games. GraphQL has its downsides too. Since everything is a POST to a single URL, client-side caching becomes problematic. Query complexity can become a problem, too. Since GraphQL hides much of the computational complexity of a query, poorly-written GraphQL queries can lead to bottlenecks and slowdowns.
And of course, add to that the fact that you’ve got another layer in between server and client. More moving parts always means more things to (potentially) break.
Ending Thoughts
GraphQL is still an emerging technology. It won’t replace REST, or SOAP, or really anything else — there will always be use cases for which GraphQL isn’t the right choice.
But I think it does provide a new way to think about how we design and consume APIs. And as a developer, I always like to have shiny new tools in my utility belt.
To learn more about GraphQL, click the link to pre-order the new book, GraphQL for Modern Commerce by Chief Product Officer, Kelly Goetsch of commercetools.
https://ok.commercetools.com/graphql-booklet
David Lilly
David is Senior Solutions Consultant with commercetools. He is an engineer with a passion for creating. Whether it's a custom demo or just a tool to make his life (or someone else's) easier, he loves the act of creation.