Por que os bancos de dados são expostos como APIs?

Um aplicativo não vale muito até que seja colocado em produção. Para os desenvolvedores, chegar a esse ponto rapidamente significa acesso fácil aos dados que eles precisam criar sem ter que se preocupar com os detalhes de criação, gerenciamento e manutenção de bancos de dados.

As APIs se tornaram o padrão de fato para conectar aplicativos a bancos de dados, mas nem sempre foi assim. Aqui discutiremos o que mudou no mundo do software para aumentar a importância de expor bancos de dados como APIs. Também discutiremos o Stargate, o projeto de código aberto que simplifica como os desenvolvedores podem trabalhar com essas APIs (a versão mais recente do Stargate, que inclui melhorias em escalabilidade e flexibilidade, foi lançada recentemente ).

Como construímos software que usa bancos de dados

Os administradores de banco de dados (DBAs) costumavam ser os responsáveis pelas consultas, pois exigia um especialista em banco de dados para projetar a maneira como os desenvolvedores interagiam com os dados. Mas, até recentemente, esperava-se que os desenvolvedores soubessem muito sobre como interagir com bancos de dados, mesmo que não fossem especialistas em SQL, consultas ou modelos de dados.

Eu era um desenvolvedor proficiente na década de 1990, mas os bancos de dados me intimidavam. Levei anos para me sentir confortável trabalhando com SQL. Simplesmente oferecer um “semelhante ao SQL” também não é suficiente. Veja o CQL (Cassandra Query Language), que foi desenvolvido para oferecer uma linguagem de consulta semelhante ao SQL para comunicação com o Apache Cassandra. A ideia era fornecer uma abstração para a comunicação com o Cassandra, tornando mais fácil para aqueles que estão familiarizados com bancos de dados relacionais fazê-lo.

Mas no mundo da rede, temos novos conceitos de identidade, permissões e segurança completamente separados da linguagem de consulta. A noção de um driver simplesmente se comunicando em um protocolo binário não funciona bem na nuvem. HTTP é o protocolo de camada de aplicativo fundamental para a nuvem, mas a maioria das APIs baseadas em HTTP são lentas. Uma opção de baixa latência, como gRPC, é crítica para comunicações em tempo real em sistemas distribuídos.

Como o software fala com o software

A maneira padrão que os clientes ou servidores de aplicativos usavam para se comunicar com os bancos de dados envolvia drivers executados no data center. Agora tudo está rodando na nuvem, mas os desenvolvedores escrevem em uma ampla variedade de idiomas. JavaScript , Python ou qualquer um de vários frameworks diferentes podem ser usados, portanto, os meios pelos quais o software acessa os dados precisam ser abstraídos de maneiras diferentes dos drivers de banco de dados clássicos - usando APIs (JSON, gRPC, GraphQL ou Document) que desenvolvedores estão confortáveis.

A forma moderna que o software fala com o software é uma API; é a camada de abstração que esconde as complexidades do banco de dados.

A natureza dos dados

Os dados costumavam ser muito mais uniformes; ele se encaixa perfeitamente em linhas e colunas nas tabelas do banco de dados. Mas a dinâmica dos dados mudou. Os dados se movem de representações na memória de volta para o banco de dados de maneira contínua, sem muito software interveniente. E estamos lidando com novos tipos de formatos de dados que são muito mais robustos do que os primitivos de dados com os quais as pessoas costumavam lidar — ou a meia dúzia de tipos de dados que o SQL poderia manipular.

APIs de banco de dados

APIs são como os desenvolvedores de hoje trabalham com bancos de dados. Aqui está um resumo do porquê:

• HTTP é o protocolo de rede da nuvem. Muitos desenvolvedores já estão familiarizados com as APIs da Web e o uso de HTTP facilita muito a implantação de aplicativos em nuvem.
• Não há necessidade de instalar e executar bancos de dados localmente. Instalar um banco de dados localmente requer esforço e cria mais um ambiente no qual os problemas precisam ser depurados.

Um portal para simplicidade, escalabilidade e extensibilidade

Um gateway de API de dados é uma parte da infraestrutura de software que fornece acesso a dados por meio de APIs de vários estilos, incluindo REST, gRPC e outros. O gateway abstrai os detalhes de armazenamento e recuperação de dados usando um ou mais armazenamentos persistentes. Isso permite que os desenvolvedores de aplicativos se concentrem em escrever serviços de negócios que acessem dados por meio de APIs fáceis de usar, em vez de aprender as complexidades de uma linguagem de consulta de banco de dados.

Stargate é um gateway de API de dados de código aberto que fica entre um aplicativo e os bancos de dados que ele precisa consultar. Foi introduzido pela primeira vez em setembro de 2020 e o Apache Cassandra foi escolhido como o primeiro banco de dados em parte porque resolve os desafios de escalabilidade e disponibilidade mais difíceis do mundo.

Um gateway de API de dados é uma maneira poderosa de permitir que seus desenvolvedores trabalhem em estruturas e estruturas com as quais estão familiarizados, oferecendo uma variedade de compensações entre produtividade e desempenho. Stargate oferece o poder do Cassandra apresentando REST, Document e GraphQL como APIs simples. Ele também oferece um conjunto de bibliotecas gRPC para fazer CQL sobre gRPC como uma alternativa mais fácil, leve e compatível com a nuvem para drivers nativos para CQL sem sacrificar o desempenho.

Este ano, a equipe de engenharia do Stargate na DataStax tem trabalhado em uma atualização de arquitetura para o Stargate. Stargate v2, como estamos chamando, foi lançado em outubro de 2022 . Com base no feedback da comunidade de desenvolvedores do Stargate , no Stargate v2 fizemos algumas atualizações significativas que facilitam o uso dos desenvolvedores e a contribuição da comunidade com o projeto. Mais importante ainda, a API gRPC de alto desempenho do Stargate v2 pode oferecer velocidade equivalente aos drivers de banco de dados nativos. Isso permite que os desenvolvedores usem protocolos de rede compatíveis com a nuvem, como HTTP, para conectar aplicativos e bancos de dados, sem perda de desempenho na conexão.

Extensível e Adaptável

Nenhuma estratégia de cima para baixo ou sabor de API do mês sobreviveu ao contato com um grande grupo de desenvolvedores. Um dos principais objetivos do Stargate v2 é permitir que a comunidade adicione novos serviços de API de forma rápida e fácil, tornando a própria implementação mais fácil de entender, depurar, aprimorar e estender.

Adicionar um novo serviço de API é muito mais simples agora, e o código-fonte para os serviços REST, GraphQL e Document API fornecem aos desenvolvedores um código de exemplo instrutivo que mostra como deve ser um serviço de API finalizado.

A camada de API deve ser multimodelo; os desenvolvedores desejam encontrar sua API preferida prontamente disponível, em vez de serem forçados a adaptar seu trabalho de desenvolvimento a uma API diferente. E se a API não estiver disponível, a camada de API deve ser capaz de se adaptar.

Nuvem nativa

Jogar código na frente de um banco de dados é feito há anos. Mas, na verdade, construir uma plataforma que pode escalar com seu banco de dados — e ser adaptável e confiável — é algo novo. Se você estiver usando o Cassandra, provavelmente já é um aplicativo de alto crescimento — ou aspira se tornar um. Portanto, tudo o que estiver à sua frente deve facilitar um ambiente de alto crescimento. O Stargate começou como uma bifurcação do código coordenador do Cassandra, portanto herda muito da confiabilidade e disponibilidade pelas quais o Cassandra é bem conhecido.

A camada de API deve ser totalmente capaz de operar em escala, portanto, outro objetivo do Stargate v2 era torná-lo mais compatível com a nuvem. Várias mudanças para facilitar a escalabilidade do Stargate incluem:

• O Stargate agora é totalmente conteinerizado e executado nos pods do Kubernetes, o que dá aos operadores mais controle sobre como as cargas de trabalho podem ser dimensionadas.

• Os serviços de API foram transferidos do nó monolítico Stargate para microsserviços separados, o que permitirá que cada API seja dimensionada de forma independente.

• Os nós de armazenamento e os nós coordenadores podem ser implantados e escaláveis de forma independente, dando também aos operadores mais controle sobre como as cargas de trabalho podem ser dimensionadas.

  
  

Se uma carga de trabalho for intensiva em consultas ou armazenamento, ela poderá ser ajustada sem recorrer ao dimensionamento de todo o cluster como um todo.

Desenvolvendo com algo familiar

Os serviços de dados em nuvem se tornaram o tema dominante no mundo da tecnologia, portanto, não é surpresa que os desenvolvedores pensem em termos de abstrações de dados como JSON, em vez de expressões exclusivas de bancos de dados específicos. Stargate é o culminar de muito trabalho árduo para encontrar os desenvolvedores onde eles estão, permitindo que eles trabalhem em estruturas e estruturas com as quais estão familiarizados.

Saiba mais sobre o Stargate aqui .

Por Ed Anuff.