We live in the golden age of cloud computing. For consumers, it’s a wonder. For developers, it’s a complete and utter mess.
For all the problems with monolithic application architectures (and there are many), they’re relatively straightforward: Take an app server and database and wire them to a browser interface. Simple! By contrast, today’s applications depend on an ever-changing array of back-end microservices, first-party and third-party APIs, databases, etc., with an assortment of front-end landing zones for that data (browser, set-top box, mobile app, etc.) Even as React and other front-end frameworks have made front-end development easier, connecting the sometimes bewildering back-end complexity to that front-end experience has gotten harder.
Say a prayer of thanks for GraphQL.
GraphQL, released by Facebook in 2015, serves as a flexible query language for APIs. Unlike SQL, which you’d use to query a relational database, GraphQL allows a developer to query a wide range of data sources, decoupling client (front-end development) from server (back-end development). But as cool as GraphQL is, it’s incomplete without a supergraph. As Apollo GraphQL CTO and cofounder Matt DeBergalis writes, the supergraph is “a unified network of a company’s data, microservices, and digital capabilities that serves as the ‘composition layer’ for the whole organization.”
CEO and cofounder Geoff Schmidt put it this way in an interview: “The supergraph is a living, breathing thing” that enables enterprises to incrementally adapt their infrastructure to ever-changing requirements. Oh, and to tie that new infrastructure to legacy infrastructure because “there’s no such thing as greenfield.”
Supergraphs and greenfield myths
Wait, what? Surely a startup or an individual developer doesn’t have to deal with technical debt the same way an established enterprise does and can focus on greenfield development? “Technical debt” can be a bit of a loaded term, but let’s express it the way RedMonk analyst James Governor did in a recent interview:
Whether you are an individual developer [and] you have learned skills…and now you’re trying to build upon that skill to learn a new framework, or whether you’re a small enterprise and you have built out certain data infrastructure and are trying to figure out how to build some analytics on it, or whether you’re a large enterprise that’s having difficulty in hiring people and really wants to build on the skills that you already have, … the constant is that while new technology comes in, it must coexist with and build upon existing skills and existing technology stacks.
Schmidt learned this the hard way.
Schmidt and DeBergalis cofounded Meteor in the early 2010s to provide an end-to-end JavaScript framework—a “really magical platform for building new apps,” said Schmidt. Developers seemed to agree. In its day, MeteorJS was one of the most popular projects on GitHub and attracted a healthy community to more than 100 regular meetups. The problem, as Schmidt relates, was that Meteor started from a bad assumption. “When we tried to bring Meteor into the enterprise, Meteor was designed for greenfield development [but] we found that nothing is greenfield in the enterprise.”
He continues: “We live in a world where any app you’d want to build draws on a lot of different services and data sources that come from a lot of places. That’s what makes the app valuable. It synthesizes all the stuff in the cloud into an experience you can have.” Again, whether you’re an individual developer, a small startup, or a Fortune 500 behemoth, you depend on a wide array of services outside your firewall, as it were, and all those services make development complicated.
Actually, that’s not quite right. As Schmidt points out, the key insight he and DeBergalis had was that the enterprise needed a better way to connect increasingly powerful front-end frameworks (such as MeteorJS or React) to increasingly powerful but complicated back-end services. “Seeing how hard it was to get Meteor into the enterprise, we started to build the Meteor 2 data system,” he remembers, “which was called Apollo and was based on all the lessons learned from [helping] enterprises … make the Meteor technology work in complex heterogeneous enterprise environments.” They needed a query language for their Apollo supergraph and chose GraphQL.
All this is great. But why should you care?
Supercharging GraphQL
If you’re building applications, whether as an individual developer or for a large enterprise, development isn’t getting any easier. The way forward is pretty clearly headed toward increased complexity through microservices. Developers embrace that complexity because there is so much to gain from the approach, such as increased agility. They want that future.
But getting to that future can be tricky.
Even GraphQL, for all its potential, has been used by many developers to stitch together individual services. What Apollo is trying to land is a graph of graphs, as it were. Using graphs to pull together an increasingly atomized infrastructure is good, but adding a meta-graph, or a supergraph, has the potential to dramatically improve developers’ lives. Why? It’s the easiest way to make use of disparate data sources without having “to create these deep, direct, fragile connections to a particular Oracle database or a particular microservice, or to create a whole new REST endpoint that somebody has to maintain,” says Schmidt.
Importantly, the supergraph approach can be somewhat piecemeal in nature. Walmart, for example, had to figure out how to integrate the mainframes that run their stores with the microservices that run their online fulfillment. Customers didn’t know about this infrastructure problem and may not have even noticed that Walmart had one website for online shopping and one for in-store pickup. But they definitely recognized that reviews available online didn’t show up for in-store pickup. And they would have been frustrated by the different product catalogs hosted with each system. Walmart couldn’t afford to shut down its mainframes, so it used the Apollo supergraph to essentially combine the two systems.
The supergraph approach “doesn’t require a stop-the-world waterfall change,” says Schmidt. It helps organizations seamlessly connect their legacy systems with their newer systems. In the case of Walmart, it meant a front-end developer could say, “Show me the reviews on a product,” and they’d find those reviews wherever they were, including their mainframe. If later they refactored that mainframe to a microservices-based architecture, nothing would need to change on the front end.
Co-opting the cloud
One interesting thing that emerges from all this: The clouds don’t necessarily make things better. AWS, for example, offers AppSync, a great way for an app developer to pull data from DynamoDB and surface it in their mobile app. But what if you want to pull data from DynamoDB, toss in some Azure serverless functions, call some data in your mainframe, plus access data from a Google Cloud service or two? The whole promise of GraphQL and an Apollo-esque supergraph is to tame heterogeneous environments, and that new heterogeneity includes different clouds. It’s going to be difficult for any particular cloud to provide the central routing required.
We have needed a declarative, abstract layer, or a supergraph, to help developers tame the mess that is enterprise IT. For a time, we fooled ourselves into thinking that cloud would fix the problem. It didn’t. It just extended and further complicated enterprise IT. Thoughts and prayers that a supergraph can help. It just might.
Copyright © 2022 IDG Communications, Inc.
