Meet Stargate, DataStax's GraphQL for databases. First stop - Cassandra

A flexible API is key to database accessibility and developer friendliness today. Cassandra was lacking in that department, and DataStax is trying to address this with the release of a new API layer called Stargate.
Written by George Anadiotis, Contributor

Open source Cassandra is one of the most successful databases in terms of popularity, according to the DB-Engines ranking. However, it has been plagued by two key issues: It's challenging to run, and not very easy to develop. DataStax, a vendor leading the development of Cassandra and commercializing it, is taking steps to address these issues.

Initially, DataStax brought Cassandra to the cloud, launching its Astra cloud offering Cassandra as a managed service. DataStax also brought Cassandra to the Kubernetes world, and, in fact, it did both of these things together, running Cassandra on top of Kubernetes is how the Astra cloud service works.

However, as Ed Anuff, DataStax's chief product officer, told ZDNet, DataStax still knew it needed to make it easy for developers who are building new applications to work with Cassandra. Enter Stargate.

There's an API for that

DataStax announced what it touts as a new API stack for modern data apps. Stargate, an open-source API framework for data first unveiled this summer, is now generally available in DataStax's Astra cloud database and for free download. The new offering enables developers to build data apps through the API of their choice.

What is this about? When we first saw it this summer, it was not entirely clear to us either. The idea itself makes sense. Developers these days like clean, generic, JSON-friendly APIs to access anything, and that includes databases, too.

As a consequence, this has given birth to a number of middleware implementations that act as the bridge offering a GraphQL API to access various databases -- most prominently, PostgreSQL. Some databases offer a GraphQL layer natively as well. For example, Dgraph, FaunaDB, and MongoDB, with the former being based entirely on a GraphQL variation.


With Stargate, a GraphQL-like API, DataStax aims to address a chronic pain point for Apache Cassandra. (Image: DataStax)

But the thing is that Stargate looked very similar to GraphQL. So the question was: Why reinvent GraphQL? In the time leading to today's announcement, however, things became a bit more clear. As Stargate's architectural elaboration showed, and Anuff verified, Stargate is not out to replace GraphQL, but rather to complement it, while working in tandem with it.

The target audience is the same: 12 million full-stack developers, which is more than half of all the developers in the world. It's worth noting here that Anuff had a previous stint in Apogee, an API management company that Google acquired back in 2016. Until recently, Anuff was with Google, and it seems that DataStax is looking to capitalize on his experience in managing APIs.

Anuff and his former Google colleague Sam Ramji, who is also with DataStax now as its chief strategy officer, had a key insight as Anuff put it: "Software developers don't use a database, they don't use a cloud, and they don't use infrastructure; what they use is the APIs to those."

Stargate is touted by DataStax as the official API of the Astra Cassandra cloud service. A number of early Stargate adopters exist, including names such as Burberry, USAA, and Yelp. Anuff referred to Yelp as a good example of a company that's using open source Cassandra but had to go and build a data gateway. More companies successful with Cassandra had to follow this pattern.

Stargate: A GraphQL for databases?

The idea, and the architecture behind Stargate, is similar to GraphQL. Stargate is an API server of sorts, exposing the underlying Cassandra functionality to developers. This server is based on the concept of a Cassandra coordinator node and is very similar to the "fat client" concept. When Stargate is deployed, it joins the Cassandra cluster as a coordinator node but does not store any data.

Stargate architects note that this design was chosen because coordinator nodes in Cassandra already handle most of the request handling and routing that's needed for a highly available storage proxy and it made sense to reuse that time-tested logic. This architecture allows for compute to be scaled independently of storage; a common model when using cloud infrastructure.

Stargate offers developers a choice regarding how to access Cassandra. They can use a REST API, a GraphQL API, or a schemaless Document API to access data. By using the Document API, developers can store JSON objects in Astra, without doing upfront modeling. Using Stargate means that developers don't have to be exposed to CQL -- Cassandra's native query language -- either.

Support for GraphQL and the Document API were added recently. The vision for Stargate as laid out in its architecture diagram however does not end there. It includes things such as SQL, GRPC, or WebSocket. Anuff verified that it is possible to use Stargate in conjunction with other GraphQL endpoints or systems like Apollo, and people are actually doing this.

So, rather than creating a GraphQL layer to expose Cassandra's functionality, what DataStax has done actually looks more ambitious. Stargate is a GraphQL-like API, that supports GraphQL, but also other APIs, with more coming in the future.


Stargate supports not just GraphQL, but also a schemaless document API, with support for SQL and more APIs like GRPC lined up. (Image: DataStax)

We wondered whether DataStax has the ambition of promoting this beyond Cassandra, as we have the feeling it may be welcome by developers interacting with other databases, too. Anuff said this is something it is wondering about themselves, but for the time being, it is focusing on Cassandra.

The Stargate API is open source, as well as the implementation for Cassandra. It's been designed in a modular fashion and it's licensed under the permissive Apache license, Anuff said, which should make it possible for others to add implementations for other databases too, should they wish to.

Of course, it will take database-specific expertise to be able to do the equivalent of what DataStax did for Cassandra, which is to expose the underlying data structures and query language via a generic API. This might happen if Stargate adopters like it enough to want to extend its use to other databases, too.

It's still early days for Stargate, and we'll have to wait and see how it plays out. On paper, however, it seems like a good move for DataStax, picking up on an established pattern for database access, and enriching it in some interesting ways.

Editorial standards