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.”
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.
