Stargate APIs for Cassandra

Stargate provides a data gateway with REST, GraphQL, and Document APIs in front of your K8ssandra-managed Cassandra database. Stargate is deployed by a K8ssandra Operator install, based on the Stargate Custom Resource Definition (CRD).

If you haven’t already installed a K8ssandraCluster using K8ssandra Operator, see the local install topic.

Introduction

Stargate is an open source data gateway that sits between your app and your databases. It brings together an API platform and data request coordination code into one OSS project.

Stargate is a framework used to customize all aspects of data access. It is deployed between client applications and a database to provide an abstraction layer that can be used to shape your data access to fit your application’s needs.

Many companies already build applications against Cassandra databases using the native Cassandra Query Language (CQL) API. With Stargate, Cassandra is available to a whole new class of applications through its many data API gateways. Instead of writing CQL, developers may opt for REST, GraphQL, or even Document endpoints that are all backed by the high performance and availability of Cassandra. K8ssandra has optional charts for the automated deployment and configuration of Stargate alongside Cassandra data nodes.

Architecture

Stargate is organized into modules comprised of three broad categories:

• API extensions — responsible for defining the API, handling and converting requests to database queries, dispatching requests to persistence services, and returning and serving response to clients. Currently there are extensions for CQL, and REST and GraphQL APIs for CRUD access to table data. These extensions use the Authentication Extensions and the Persistence Extensions.

• Persistence extensions — responsible for implementing the coordination layer to execute requests passed by API services to underlying data storage instances. The Persistence extensions are currently Cassandra-centric. The extensions for Cassandra 3.11 and 4.0 use Cassandra’s coordinator to do the majority of the work.

• Authentication extensions — responsible for access control to Stargate’s APIs. This extension stores generated access tokens in the database.

Here’s how the modules fit together:

Deploying Stargate

In order to deploy Stargate, you’ll need to include the Stargate component in your K8ssandraCluster custom resource (CR). For example:

apiVersion: k8ssandra.io/v1alpha1
kind: K8ssandraCluster
metadata:
  name: demo
spec:
  cassandra:
    ...
  stargate:
    size: 1

The above manifest will deploy one Stargate pod per datacenter. The Stargate pods will be deployed in the same Kubernetes namespace as the Cassandra pods. The Stargate pods will be exposed via a Kubernetes service of type LoadBalancer. The service will be named <clusterName>-<dcName>-stargate-service.

Stargate’s configuration can be set at the datacenter level, or at the cluster level. The following example shows how to set the configuration at the datacenter level:

apiVersion: k8ssandra.io/v1alpha1
kind: K8ssandraCluster
metadata:
  name: demo
spec:
  cassandra:
    serverVersion: 4.0
    datacenters:
    - metadata:
        name: dc1
      size: 3
      stargate:
        size: 1
    - metadata:
        name: dc2
      size: 3
      stargate:
        size: 2

The above example will deploy one Stargate pod in dc1 and two Stargate pods in dc2, along with 3 Cassandra pods in each datacenter.

Next steps

• For comprehensive information about Stargate, visit the stargate.io site.
• For details on the API calls, see the Stargate API reference.
• For an introduction to using Stargate with K8ssandra, see Develop with Stargate APIs.
• For reference details, see the K8ssandra Operator Custom Resource Definitions (CRDs).
• For information about using a superuser and secrets with Stargate authentication, see Stargate security.
• Also see the topics covering other components deployed by K8ssandra.
• For information on using the deployed components, see the Tasks topics.