Apollo, the Greek deity
Apollo, the tooling company behind one of the most popular implementations of GraphQL, is adding new flexibility to its gateway tier that should grease the skids for expanding adoption from workgroup to broader enterprisewide implementations. And, by setting its sights to the enterprise, Apollo is changing the licensing for the family jewels – the gateway, or router tier, that is the key link in connecting queries to data.
The new capability is part of the Apollo Federation 2.0 release; it makes it more flexible for teams to share, pass ownership, and modify or extend on the underlying data models represented by the graph. Previously, each element of the schema could only be owned by a single team; the new version allows for multiple teams to share responsibility.
The guiding notion is that, while strict ownership might work at workgroup level, when extending to wider cross sections of the organization, and wider swaths of data, ownership may need to become more flexible to overcome silos. For instance, the team that initially defines the customer record may not necessarily be the team that owns responsibility for the record as it evolves. Apollo’s v2 relaxes restrictions locking down ownership to enable that ownership to be changed or shifted.
And of course, as responsibility is shared, governance of changes needs to become more explicit. Apollo Federation 2 is adding a feature for specifying approval/review workflows to the process.
Another new feature in the gateway allows schemas to be more readily federated without requiring wholesale rewriting of the schema. For instance, companies that make products may take individual product SKUs and expand them into families of related SKUs; with the new gateway, it becomes easier to evolve schemas to support federation.
The other headlining change is to the licensing. As Big on Data bro George Anadiotis covered in his exhaustive post last summer about Apollo’s funding and origins, Apollo’s business model has been open core. The company’s tooling has three tiers. There is a client where queries are written; Apollo offers a Studio IDE that is open sourced with the MIT license. And it has a back end server that connects incoming queries to the graph, which is similarly MIT licensed.
The family jewels, for which the changes in v2 are about, is the gateway or router. This is the piece with the brains, where query plans are made that performs all the joins. This is the piece that, with this version, is adopting the Elastic license, which in essence prohibits customers from launching their own managed services for hire. Apollo opted for the elastic license because it was less complex than SSPL, the MongoDB-oriented license that, ironically, Elastic adopted for its family jewels (Elasticsearch and Kibana) early this year.
OK, if you want more background on the angst surrounding open source licensing, we’ve got you covered.
But the real story is about GraphQL, the little API that could. Originated as a spec at Facebook, Apollo is one of the commercial firms that have developed implementations of it. Despite its name, GraphQL is not necessarily a graph database query language, although we expect that some graph databases will support it as a front end for simplifying queries. Instead, the graph of GraphQL refers to the underlying graph that maps the target data source, and therefore, lifts all the burden of specifying how to connect with the data from client back to the server. In essence, the graph knows where the data is, and so therefore, your query doesn’t have to physically find it.
GraphQL’s early claim to fame was with mobile applications, which are especially sensitive to the chatter involved with REST queries that often require several rounds of back and forth to get to the data. MongoDB was one of the earliest adopters of GraphQL when it embraced it as part of its Realm mobile development platform.
For Apollo, greasing the skids for federation is essential for scaling use of GraphQL. As the data estate gets broader, and supports more walks of life across an enterprise, schemas are going to evolve faster. And so it grows necessary to facilitate collaboration, and process to support it. The need for a more agile framework for enabling access to data grows with implementation of microservices, which on their own add their share of complexity to software development.
It’s tempting to think that one could represent all, or at least a wide swath enterprise data in a single map. Admittedly, graph is a lot more flexible than the rigid hierarchical or relational approaches to enterprise data models that never could scale in the past. But even though graph is a more flexible means for mapping data, there is always a question of how well tidy concepts will scale in the real world.
The new features are intended to address the challenges of bringing the underlying mapping and definition of schema to, literally a wider world. Consider it a rite of passage for GraphQL.
