paint-brush
Como a Mongoose trará desenvolvedores orientados a JSON para o Apache Cassandrapor@datastax
461 leituras
461 leituras

Como a Mongoose trará desenvolvedores orientados a JSON para o Apache Cassandra

por DataStax5m2023/04/03
Read on Terminal Reader

Muito longo; Para ler

Uma nova parceria entre os projetos de código aberto Stargate e Mongoose criará uma experiência totalmente idiomática para desenvolvedores de JavaScript no Cassandra.
featured image - Como a Mongoose trará desenvolvedores orientados a JSON para o Apache Cassandra
DataStax HackerNoon profile picture



O Apache Cassandra está se tornando o melhor banco de dados para lidar com documentos JSON. Se você é um desenvolvedor Cassandra que acha essa afirmação provocativa, continue lendo.


Em um artigo anterior, discutimos o uso de APIs de dados e modelagem de dados para moldar o Cassandra em uma experiência de desenvolvedor mais idiomática para a maneira como os desenvolvedores pensam, melhorando assim a produtividade do desenvolvedor e preservando o desempenho e a escala razoáveis do banco de dados. É uma ótima hipótese e que precisa ser testada no contexto de um determinado idioma e comunidade de desenvolvedores.


Mongoose , uma biblioteca de mapeamento de dados de objeto geralmente usada com o driver MongoDB, é um projeto de código aberto com uma comunidade significativa de desenvolvedores JavaScript em torno dele. No projeto Stargate , o gateway de dados API de código aberto projetado para trabalhar com Cassandra, fizemos uma parceria com o Mongoose e estamos trabalhando em uma próxima API JSON que será lançada junto com uma versão do Mongoose que funcionará por meio desse JSON API para se conectar ao Cassandra. Isso cria uma pilha de ponta a ponta para desenvolvedores Mongoose que é totalmente de código aberto. É uma mudança de jogo para os desenvolvedores do Mongoose e abre um novo capítulo importante para Cassandra.

Neste artigo, discutirei como fornecer um idioma JSON amigável ao desenvolvedor usando Cassandra junto com Stargate e como estamos trabalhando para fazer exatamente isso para desenvolvedores Mongoose.

Os Cachinhos Dourados das Comunidades JS

Em outubro de 2022, lançamos uma nova versão do Stargate. Com a nova versão 2 , as APIs individuais não são mais incorporadas ao código principal do coordenador do Stargate, mas sim separadas em serviços individuais. Isso melhora a eficiência operacional do Stargate; serviços de API individuais agora podem ser implantados e dimensionados de forma independente. Isso também facilita o desenvolvimento de novos serviços de API. Desde que obedeçam ao limite de serviço, esses serviços podem ser desenvolvidos em paralelo e independentemente do trabalho de desenvolvimento central do Stargate.


Em seguida, procuramos uma experiência verdadeiramente idiomática que pudéssemos oferecer aos desenvolvedores. Com 18 milhões de desenvolvedores, o JavaScript é a linguagem de programação mais popular do mundo, e o JSON é a maneira padrão pela qual os desenvolvedores de JavaScript estruturam os dados. No entanto, 18 milhões de pessoas não são uma comunidade; são muitas comunidades. Precisávamos das “Goldilocks” das comunidades JavaScript — grandes o suficiente para serem significativas, mas pequenas o suficiente para serem focadas. Encontramos a comunidade certa construída em torno do Mongoose, uma biblioteca mapeadora de dados de objeto usada com aplicativos que se conectam ao MongoDB. Mongoose tem várias características importantes:

  • É centrado em JavaScript
  • Goza de ampla adoção, com cerca de 2 milhões de repositórios GitHub listando o Mongoose como uma dependência
  • A liderança ativa do criador do Mongoose, Valeri Karpov, fornece um foco claro
  • É um projeto de código aberto que não possui um banco de dados de código aberto desde a decisão do MongoDB de mudar para um modelo de código compartilhado com sua licença pública do lado do servidor


Os desenvolvedores realmente não interagem diretamente com um banco de dados, mas com um modelo de dados. Na API de documento original do Stargate, a API lida com JSON fazendo com que pareça uma tabela Cassandra tradicional. Isso sobrecarrega os desenvolvedores orientados a JSON para pensar em termos de estruturas de dados do Cassandra e sobrecarrega a lógica de indexação orientada a linhas do Cassandra porque um documento JSON se espalha por várias linhas.


Nossa nova API JSON parte desse modelo de dados e, em vez disso, depende de um modelo de dados que chamamos de “super trituração”. Você pode aprender mais sobre super retalhamento assistindo à palestra de Aaron Morton no recente evento Cassandra Forward . Resumindo, aproveitamos a natureza de coluna larga do Cassandra para armazenar um documento por linha, sabendo que uma linha do Cassandra pode lidar com documentos muito grandes. Também temos um conjunto de colunas nessa linha que são explicitamente para armazenar características de metadados padrão de um documento JSON. Agora temos algo mais facilmente indexável, bem como um meio de preservar e recuperar metadados.


Em seguida, usaremos esse modelo de dados com nossa nova API JSON, usando a mesma especificação mQuery que o Mongoose usa como nosso requisito de orientação para quais chamadas a API precisa suportar. Quando concluído, isso deve permitir que qualquer um dos mais de 2 milhões de aplicativos dependentes do Mongoose sejam executados no Cassandra de código aberto ou no serviço Cassandra hospedado do DataStax, Astra DB , com apenas uma alteração na configuração.


Com o Mongoose e a nova API JSON, forneceremos uma experiência totalmente idiomática para desenvolvedores JavaScript orientados a JSON, dando a eles a escala e o desempenho do Cassandra sustentando um modelo de dados JSON autêntico.


O criador do Mongoose, Karpov, também falou no recente evento Cassandra Forward (você pode assistir ao replay aqui ), demonstrando um aplicativo de comércio eletrônico simples que usa a versão Stargate do Mongoose, Stargate de código aberto e a versão DataStax Enterprise (DSE) do Cassandra. Você pode baixar o código de trabalho para este aplicativo e as peças de plataforma de suporte do GitHub . Embora tenhamos código suficiente para executar este aplicativo, ainda não concluímos o código. Por exemplo, estamos executando contra o DSE agora porque precisamos da indexação anexada ao armazenamento (SAI), que funciona com o DSE e está planejada para ser lançada no Cassandra 5.0 ainda este ano.

Contribuindo de volta para Cassandra

O Cassandra não é um software estático; é um projeto de código aberto vibrante e em evolução. Portanto, também continuamos uma longa tradição do Cassandra de usar recursos como SAI que emergem do lado do cliente para promover mudanças no lado do banco de dados. não apenas melhorar a API JSON do Stargate e o cliente Mongoose, mas também adicionar novos recursos poderosos ao Cassandra Query Language. Este é um ótimo lembrete de que engenheiros de dados e desenvolvedores de aplicativos não são duas comunidades diferentes, mas coortes complementares da comunidade Cassandra estendida.


E JSON é apenas o primeiro passo. Essencialmente, o que teremos feito é pegar os blocos de construção de Cassandra, Stargate e um modelo de dados Cassandra razoavelmente eficiente e construir um banco de dados de documentos com o qual você interage por meio de uma API JSON. Em outras palavras, usamos super trituração para criar um banco de dados específico que atende melhor à comunidade de desenvolvedores Mongoose.


Com a arquitetura modular do Stargate v2 e o ponto de prova do Mongoose para a abordagem idiomática, estamos prontos para assumir novas comunidades de desenvolvedores que se organizam em torno de um determinado idioma de desenvolvimento de software. O processo pelo qual aproveitamos Cassandra para Mongoose é repetível - e é um que repetiremos. Ao fazer isso, expandimos drasticamente o número de desenvolvedores e casos de uso que o Cassandra pode abordar, que é o tipo de objetivo digno de um projeto de código aberto.


Saiba mais sobre o DataStax .



Por Mark Stone. Mark é gerente de produto da DataStax. Ele é um veterano em tecnologia com muitos anos de experiência em gerenciamento de produtos, gerenciamento de programas e gerenciamento de pessoas. Sempre trabalhando como parte do tecido conectivo entre as partes interessadas nos negócios e as partes interessadas técnicas, Mark adora defender a experiência do desenvolvedor em plataformas de tecnologia e ajudar as organizações a encontrar os desenvolvedores onde quer que estejam.