The power and challenges of GraphQL

The Intellyx take on Nacelle and the modern approach to headless and composable commerce - Part 1

Written by: Jason Bloomberg, Managing Partner & Analyst, Intellyx

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.
                                                                                                      – GraphQL.org

Since Facebook released the GraphQL spec to the world in 2015, people’s opinions about it have been dramatically divided.

Giving clients the power to ask for what they need from servers – perhaps the most important phrase in the standard definition above – represents a paradigm shift in how software implements integration in distributed environments.

On the other hand, GraphQL’s detractors point out that implementations of the language fall short of its promise and that in real-world scenarios, performance and complexity limitations outweigh its strengths.

Both sides have a point. To get to the bottom of this controversy, we need to place GraphQL in context. How does it differ from integration paradigms that came before? What problems remain, and how can we solve them?

On the shoulders of giants

GraphQL owes much of its design to the two integration paradigms that preceded it: SOAP-based Web Services and REST. Each of these approaches solved a raft of problems while leaving others unresolved. Just as REST addressed many issues with Web Services, so too does GraphQL resolve problems with REST.

To understand the context of GraphQL, let’s look at the table below.

Comparing GraphQL to web services and REST (source: Intellyx)

Paradigm

SOAP-based Web Services arose in the early 2000s, leveraging the text-based XML standard that became prominent in the 1990s. Abstracting arbitrary endpoints via XML provided a simple, common interface standard that was both technology and language-independent.

REST, in turn, leveraged HTTP to provide a lightweight, web-friendly approach to integration that resolved many of the challenges of Web Services. REST heralded a new era of simplified programmability for integration.

However, Web Services and REST require developers to code endpoint behavior on the server. Clients could only request data the server was already prepared to deliver. GraphQL turned this pattern around. With GraphQL, the request specified the data the client required – and it was up to the server to return just those data, no more and no less.

Endpoints

Instead of hard-coding clients to server endpoints, Web Services sought to make them discoverable. Clients could look them up in a registry and bind to them at runtime – at least in theory.

In practice, however, discoverability proved too difficult to be practical in most situations. REST solved this problem in a dramatic fashion by assigning any server endpoint a URL (or more generally, a URI).

Binding to an endpoint was as simple as performing a GET operation on a URL – something the web was already very good at.

Where REST fell short, however, was in situations where the client needed data from multiple URLs, requiring multiple round trips to the server.

Now it’s GraphQL’s opportunity to shine, as a GraphQL API requires only a single endpoint to handle any queries from clients.

Joins

Combining data from different sources has always been a knotty distributed computing problem. Web Services required developers to build joins on the ESB, creating SQL query strings to send to the underlying database.

REST added the ability for clients to perform joins at the cost of multiple queries to the server as well as processing and memory burdens on the browser.

GraphQL doesn’t have a comprehensive answer to the problem of joins. Without the appropriate server-side infrastructure to support them, clients must select a workaround to combine data from different sources.

Performance Bottleneck

>Every distributed computing deployment has some bottleneck – one part of the implementation that slows everything else down. With Web Services, it’s the overhead of parsing and transforming XML. REST suffers under the burden of multiple round trips between client and server.
GraphQL, in turn, suffers from inefficient APIs. Typical implementations of GraphQL leverage REST under a façade, returning far more data from the back-end sources than the client requires. The client gets the data they want but at the cost of GraphQL server memory leaks, poor performance, and scalability issues that lead to errors.

Resolving the Challenges of GraphQL

Providing joins that follow the request-centric GraphQL paradigm, as well as the related problem of building efficient APIs, is now the crux of the GraphQL challenge.

These problems affect some GraphQL deployments more than others. Of particular concern: use cases that require joined data from multiple back-end data sources, for example, with e-commerce.

The solution is to build GraphQL infrastructure from the ground up to address the challenges of GraphQL – a challenge Nacelle addresses by optimizing how the back-end platform ingests, transforms, and indexes data for even the most complex GraphQL queries and joins.

The Intellyx Take

Both Web Services and REST dramatically simplified the challenge of integration while kicking the can down the road on specific problems that plagued each approach.

The proverbial can has now arrived at the feet of GraphQL. GraphQL’s request-centricity promises to shift the power to the client where it belongs, especially for today’s digitally savvy organizations with a renewed focus on customer needs.

The question for today: will the technology community kick the can down the road once more, leaving some future integration paradigm to address GraphQL’s shortcomings?

Not if Nacelle has anything to do with it.

Copyright © Intellyx LLC. Intellyx retains final editorial control of this article. Nacelle is an Intellyx customer. No AI was used in the production of this article.