APIs automáticas sobre o Cassandra aplicadas em um caso de Ecommerce

Para acelerar o desenvolvimento de aplicações e simplificar a arquitetura, a camada automática de APIs transforma um banco de dados num serviço de dados.

O Stargate é uma aplicação open-source que cria uma camada de APIs sobre o modelo de dados do Apache Cassandra. Simples assim…

Ok, explicando um pouco mais, para cada tabela existente no Cassandra são criados endpoints REST e schemas GraphQL para que a interação entre aplicação e banco de dados não seja feita somente por CQL (Cassandra Query Language, ou o SQL do Cassandra).

Por que esta camada é importante

Sob a perspectiva técnica, voltada à operação e deployment dos serviços, esta camada de APIs é importante

1 — Elimina a existência de conexões persistentes entre os serviços e o banco de dados;

2 — Elimina o acoplamento entre microserviços e os dados;

3 — Reduz a dependência e gestão do driver de conexão.

Sob a perspectiva de arquitetura de dados e de software, esta camada:

1 — Ajuda a eliminar os silos de dados, uma vez que todas as aplicações podem consumir dados de diversas aplicações com padrões comuns.

2 — Gerencia a modelagem e os tipos de consumo que podem ser realizados sobre os dados

3- Delega a interação com o banco de dados à um serviço especialista, e com isso pode priorizar as necessidades de negócio nos seus microserviços.

E, para finalizar, sob o ponto de vista da produtividade do desenvolvedor, o Stargate:

1 — Elimina a necessidade de se aprender (e utilizar da maneira correta) a linguagem do banco de dados

2 — Utilizar padrões comuns (REST, GraphQL e gRPC) e já consagrados pelos desenvolvedores, sendo impossível

3 — Reduz código a ser escrito.

Um caso prático com Ecommerce

Nada melhor para entender uma funcionalidade do que um caso prático.

Por isso, aqui vou usar uma implementação de um data provider baseado no DataStax Astra para o NextJs Commerce . Este framework foi criado para acelerar o desenvolvimento destas aplicações com várias funcionalidades deste segmento já implementadas integrada a diversas soluções de ecommerce, como Shopify, BigCommerce, etc… Neste caso, implementamos um provider que consome os dados do Astra através de REST APIs e GraphQL.

O primeiro dado importante para esta aplicação é, claro, o catálogo de produtos. Adequando o esquema de dados do framework com o modelo do Cassandra, temos a tabela:

CREATE TABLE workshop.products (
    productid uuid,
    kind text,
    variantid uuid,
    brand text,
    category text,
    description text,
    descriptionhtml text,
    name text,
    path text,
    price float,
    pricecurrency text,
    sku text,
    slug text,
    vendor text,
    PRIMARY KEY (productid, kind, variantid)
) WITH CLUSTERING ORDER BY (kind ASC, variantid ASC);

CREATE CUSTOM INDEX product_brand_idx ON workshop.products (brand) USING 'StorageAttachedIndex' WITH OPTIONS = {'ascii' : 'true', 'case_sensitive' : 'false', 'normalize' : 'true'};

CREATE CUSTOM INDEX product_category_idx ON workshop.products (category) USING 'StorageAttachedIndex' WITH OPTIONS = {'ascii' : 'true', 'case_sensitive' : 'false', 'normalize' : 'true'};

CREATE CUSTOM INDEX product_slug_idx ON workshop.products (slug) USING 'StorageAttachedIndex' ;

Com a tabela criada, como a aplicação pode consumir os dados?

REST API

As REST APIs são, ainda hoje, o meio de comunicação mais utilizado no mundo (cerca de 93%). E todo desenvolvedor sabe como utilizá-la.

Após criarmos a tabela, todos estes desenvolvedores podem acessar e editar os dados desta tabela através de endpoints como:

Com estes endpoints é possível realizar todas as interações que qualquer aplicação transacional necessita.

Há ainda a possibilidade de paginação de resultados, limitação do numero de registros a retornar e mesmo a seleção de quais campos serão retornados.

Por exemplo, o endpoint GET /rows retorna um objeto com o atributo "count", com a contagem de registros retornados, o array "data", com o conteúdo dos registros, e o "pageState", que é utilizado para pedir os próximos registros se houver necessidade de paginação.

Trata-se de um jeito muito fácil de acessar os dados e também de evitar que queries perigosas para o ambiente sejam executadas. O Cassandra é voltado a grande volumes de dados e aplicações de missão crítica, por isso as queries têm que ser bem pensadas para seguirem as boas práticas de NoSQL e não impactarem o ambiente.

GraphQL

Mas, como neste exemplo estamos falando de ecommerce, temos que levar em conta que esta é uma aplicação que muitas vezes será consumida através de smartphones, por isso uma maneira mais recomendada é utilizar GraphQL.

O GraphQL foi criado justamente para que a aplicação consuma somente os dados que precisa sem a necessidade de se criar múltiplos endpoints sobre o mesmo dado com formatos de retorno diferentes. Então, a aplicação pode pedir menos campos quando está rodando num smartphone e mais dados quando está num computador, sem que isso gere mais endpoints no backend.

A diferença para as REST APIs é que aqui temos somente um endpoint com o método POST, que recebe uma "query", para consultas, ou uma "mutation", para alteração nos dados.

Para fazermos uma consulta, enviamos no body da requisição uma query:

query getProductBySlug ($slug: String) {
    products(options: { pageSize: 10 },
    filter : {slug:  { eq: $slug }} ) {
      values{
          ...ProductResult
      }
    }
  }
  fragment ProductResult on products {
      productid
      kind
      variantid
      name
      description
      descriptionHtml: description
      slug
      vendor
  }

Esta query, pode ter variáveis também, como o campo "slug" utilizado acima. Para isso, no bodyy também é enviado o atributo "variables".

No Postman, fica assim:

No caso das mutations, o endpoint e estrutura das variáveis é o mesmo. A diferença é que mandamos um mutation com o seguinte conteúdo:

mutation updateItemQtyCart ($productid:Uuid, $variantid: Uuid, $name: String, $kind: String) {
    products: updateproducts(
        value: {
            productid: $productid,
            kind: $kind,
            variantid: $variantid,
            name: $name
        }
    ){
        value {
            productid, 
            kind,
            variantid,
            name
        }
    } 
  }

Executando no Postman, e passando as variáveis necessárias, a requisição se completa:

E mais… Além de REST e GraphQL, o Stargate ainda propicia a interação com o banco de dados via gRPC e no modelo de documento JSON, mas isto é tema para outro artigo.

Concluindo

Para utilizar o Stargate na sua instância de Cassandra, é possível executá-los em máquinas específicas, não muito parrudas, junto ao cluster. Estas máquinas não precisam de muitos recursos de disco, mas é fundamental uma conexão de rede rápida, se possível no mesmo rack, com o Cluster.

Mas, se quiser experimentar este serviço de dados sem precisar provisionar toda infra, utilize o DataStax Astra, uma stack de dados construída ao redor do Cassandra e que já tem nativamente o Stargate ativo em todos os bancos de dados provisionados, independente de região ou provedor de nuvem escolhido (sim, o Astra é multi-clou e multi-region).

Mais sobre o Stargate aqui: https://stargate.io/

Mais sobre o DataStax Astra aqui: https://www.datastax.com/products/datastax-astra