Why IT execs need to consider GraphQL

Enterprise IT has long been a morass of oft-conflicting infrastructure choices, and recent advances have arguably made things worse. Cloud, for example, promised to make everything better, but 10-plus years of cloud-native investments have complicated things by creating a thicket of microservices, APIs, and other “cloud-native best practices.” For those hoping AI might somehow solve all this, well, I’ve got bad news for you: No sane IT person will wire ChatGPT into the CRM or ERP systems, due to lack of governance.

Despite the complexity, and despite a somewhat challenging macroeconomic environment, “You can’t opt out of building great software,” as Apollo GraphQL CTO and Cofounder Matt DeBergalis declared in an interview. Sitting still while fiddling with outdated or overly complicated dials and knobs on your infrastructure simply won’t work.

Not to worry: I bring you hope. It’s called the supergraph, and it builds on a technology developers likely already know and love called GraphQL. I’d argue that GraphQL should be top of mind even for those more comfortable in Armani loafers than Linux t-shirts, precisely because it can make those t-shirt-wearing developers much more productive.

No such thing as new

In enterprise IT, virtually no one has the luxury of building a so-called “greenfield” application. As RedMonk analyst James Governor puts it, “While new technology comes in, it must coexist with and build upon existing skills and existing technology stacks.” It’s why Cobol coexists with Java coexists with Rust. Or why a company might be “all in” on AWS but still run plenty of Azure (not to mention HP-UX, Windows NT, etc., etc.). There is very little subtraction in enterprise IT; it’s nearly always a matter of addition.

Enter GraphQL.

GraphQL is a flexible query language for APIs, enabling developers to stitch together disparate services. Before, developers would spend upwards of two-thirds of their time writing brittle API code to connect all these services. Not good. GraphQL makes those connections to services much more flexible. Yet even this approach falls short.

Things get better when we introduce a supergraph: a unified network or composition layer that gives enterprises a platform view of their microservices, internal and external data sources, etc. In an interview, DeBergalis describes this supergraph as “a composable API layer that acts like a platform.” The cool IT kids like Netflix have been using these supergraphs for years, uncovering significant benefits in the process. As the Netflix Technology Blog explains it, the supergraph “solves many of the consistency and development velocity challenges with minimal trade-offs on dimensions like scalability and operability.”

But it’s no longer just the cool kids. According to Apollo GraphQL, a primary sponsor of GraphQL, half of the Fortune 100 use GraphQL. The reasons are clear, as DeBergalis tells it: “Graph is not only the technical ‘right thing’ for app development, but also a strategic must-do for the enterprise” because until now, developers had to “handwrite a sprawl of countless back ends for front ends or experience APIs.” Switching to a composable “supergraph” API layer helps developers make enterprise infrastructure work for them, not against them.

Yes, even with AI infrastructure such as large language models (LLMs).

Complicating things with AI

As DeBergalis points out, recent advancements in generative AI (genAI) have sparked a massive surge of interest in AI technologies among software engineering and business leaders alike. Everyone is thinking about how to put AI to use, but exactly no one thinks it’s a good idea to directly connect LLMs to enterprise systems. We don’t have good ways of erecting guardrails to ensure the LLM doesn’t inadvertently expose enterprise data. No one has yet solved the problem of prompt injection, for example. Until we do, enterprises will be rightly skittish about how close they allow LLMs to get to their most sensitive data.

Although a federated supergraph doesn’t remove problems with prompt injection, it does introduce improvements. With GraphQL’s query planning and policy engine, it becomes a credible option for connecting LLMs to the data and services users need to provide the next generation of personalized experiences. Some enterprises are already using LLMs to construct queries for the graph, but they’re still relatively limited. And many developers are kicking the tires on ways to feed LLM queries into GraphQL (here’s a good example).

There’s still much to be figured out here, but we’re well underway. Fortunately, developers (and their Armani-wearing execs) don’t need to rip and replace their existing API approach for a GraphQL-powered supergraph. Indeed, DeBergalis and Apollo GraphQL aren’t asking enterprises to dump their decades of API investments. Quite the opposite. They’re trying to make these investments worth more. “In practice, GraphQL means a layer that makes those API’s more valuable,” DeBergalis argues. “REST and GraphQL go really well together.”

So I can have my HP-UX legacy infrastructure and my Google Gemini or Amazon Bedrock models, all connected in useful ways, with ever-improving governance to ensure security? The answers all seem to be yes.