Pourquoi les bases de données sont-elles exposées en tant qu'API ?

Une application ne vaut pas grand-chose tant qu'elle n'est pas mise en production. Pour les développeurs, arriver rapidement à ce stade signifie un accès facile aux données dont ils ont besoin pour créer sans avoir à se soucier des détails de la création, de la gestion et de la maintenance des bases de données.

Les API sont devenues la norme de facto pour connecter les applications aux bases de données, mais il n'en a pas toujours été ainsi. Ici, nous discuterons de ce qui a changé dans le monde du logiciel pour élever l'importance d'exposer les bases de données en tant qu'API. Nous aborderons également Stargate, le projet open source qui simplifie la façon dont les développeurs peuvent travailler avec ces API (la dernière version de Stargate, qui inclut des améliorations en termes d'évolutivité et de flexibilité, est sortie récemment ).

Comment nous créons des logiciels qui utilisent des bases de données

Les administrateurs de base de données (DBA) étaient auparavant en charge des requêtes, car il fallait un expert en base de données pour concevoir la manière dont les développeurs interagissaient avec les données. Mais jusqu'à récemment, les développeurs étaient censés en savoir beaucoup sur l'interaction avec les bases de données, même s'ils n'étaient pas des experts en SQL, en requêtes ou en modèles de données.

J'étais un développeur compétent dans les années 1990, mais les bases de données m'intimidaient. Il m'a fallu des années pour me sentir à l'aise avec SQL. Offrir simplement un « sosie SQL » ne suffit pas non plus. Prenez CQL (Cassandra Query Language), qui a été développé pour offrir un langage de requête similaire à SQL pour communiquer avec Apache Cassandra. L'idée était de fournir une abstraction pour communiquer avec Cassandra, facilitant ainsi la tâche de ceux qui sont à l'aise avec les bases de données relationnelles.

Mais dans le monde des réseaux, nous avons de nouveaux concepts d'identité, d'autorisations et de sécurité qui sont complètement séparés du langage de requête. La notion d'un pilote communiquant simplement sur un protocole binaire ne fonctionne pas bien dans le cloud. HTTP est le protocole de base de la couche application pour le cloud, mais la plupart des API basées sur HTTP sont lentes. Une option à faible latence, comme gRPC, est essentielle pour les communications en temps réel dans les systèmes distribués.

Comment le logiciel communique avec le logiciel

La méthode standard utilisée par les clients ou les serveurs d'applications pour communiquer avec les bases de données impliquait des pilotes qui s'exécutaient dans le centre de données. Désormais, tout fonctionne dans le cloud, mais les développeurs écrivent dans un large éventail de langages. JavaScript , Python ou l'un des nombreux frameworks différents peuvent être utilisés, de sorte que les moyens par lesquels le logiciel accède aux données doivent être abstraits de manière différente des pilotes de base de données classiques - en utilisant des API (JSON, gRPC, GraphQL ou Document) qui les développeurs sont à l'aise avec.

La façon moderne dont le logiciel communique avec le logiciel est une API ; c'est la couche d'abstraction qui cache les complexités de la base de données.

La nature des données

Auparavant, les données étaient beaucoup plus uniformes ; il s'intègre parfaitement dans les lignes et les colonnes des tables de base de données. Mais la dynamique des données a changé. Les données sont transférées des représentations en mémoire vers la base de données de manière transparente, sans trop de logiciel intermédiaire. Et nous avons affaire à de nouveaux types de formats de données qui sont beaucoup plus robustes que les primitives de données avec lesquelles les gens étaient habitués - ou la demi-douzaine de types de données que SQL pouvait gérer.

API de base de données

Les API sont la façon dont les développeurs d'aujourd'hui travaillent avec les bases de données. Voici un résumé des raisons :

• HTTP est le protocole réseau du cloud. De nombreux développeurs sont déjà familiarisés avec les API Web et l'utilisation de HTTP facilite grandement le déploiement d'applications cloud.
• Il n'est pas nécessaire d'installer et d'exécuter des bases de données localement. L'installation d'une base de données localement nécessite des efforts et crée un autre environnement dans lequel les problèmes doivent être débogués.

Une passerelle vers la simplicité, l'évolutivité et l'extensibilité

Une passerelle d'API de données est un élément d'infrastructure logicielle qui permet d'accéder aux données via des API de différents styles, notamment REST, gRPC et autres. La passerelle extrait les détails du stockage et de la récupération des données à l'aide d'un ou plusieurs magasins persistants. Cela permet aux développeurs d'applications de se concentrer sur l'écriture de services métier qui accèdent aux données via des API faciles à utiliser au lieu d'avoir à apprendre les subtilités d'un langage de requête de base de données.

Stargate est une passerelle API de données open source qui se situe entre une application et les bases de données qu'elle doit interroger. Elle a été introduite pour la première fois en septembre 2020 et Apache Cassandra a été choisie comme première base de données en partie parce qu'elle résout les défis d'évolutivité et de disponibilité les plus difficiles au monde.

Une passerelle d'API de données est un moyen puissant de permettre à vos développeurs de travailler dans des cadres et des structures qu'ils connaissent bien, offrant une gamme de compromis entre productivité et performances. Stargate offre la puissance de Cassandra en présentant REST, Document et GraphQL comme de simples API. Il offre également un ensemble de bibliothèques gRPC pour effectuer CQL sur gRPC comme une alternative plus simple, légère et plus conviviale pour le cloud aux pilotes natifs pour CQL sans sacrifier les performances.

Cette année, l'équipe d'ingénierie Stargate de DataStax a travaillé sur une mise à jour architecturale de Stargate. Stargate v2, comme nous l'appelons, est sorti en octobre 2022 . Sur la base des commentaires de la communauté des développeurs de Stargate , dans Stargate v2, nous avons apporté des mises à jour importantes qui facilitent l'utilisation par les développeurs et la contribution de la communauté au projet. Plus important encore, l'API gRPC hautes performances de Stargate v2 peut offrir une vitesse équivalente aux pilotes de base de données natifs. Cela permet aux développeurs d'utiliser des protocoles réseau compatibles avec le cloud comme HTTP pour connecter des applications et des bases de données, sans perte de performances sur le fil.

Extensible et adaptable

Aucune stratégie descendante ou saveur d'API du mois n'a jamais survécu au contact avec un grand nombre de développeurs. L'un des principaux objectifs de Stargate v2 est de permettre à la communauté d'ajouter rapidement et facilement de nouveaux services d'API en facilitant la compréhension, le débogage, l'amélioration et l'extension de l'implémentation elle-même.

L'ajout d'un nouveau service API est maintenant beaucoup plus simple, et le code source des services REST, GraphQL et Document API fournit aux développeurs un exemple de code instructif qui montre à quoi devrait ressembler un service API fini.

Le niveau d'API doit être multimodèle ; les développeurs veulent trouver leur API préférée facilement disponible, plutôt que d'être obligés d'adapter leur travail de développement à une API différente. Et si l'API n'est pas disponible, le niveau API devrait pouvoir s'adapter.

Nuage natif

Lancer du code devant une base de données se fait depuis des années. Mais en fait, construire une plate-forme qui peut évoluer avec votre base de données - et être adaptable et fiable - est quelque chose de nouveau. Si vous utilisez Cassandra, vous êtes probablement déjà une application à forte croissance ou aspirez à le devenir. Ainsi, tout ce qui se trouve devant doit faciliter un environnement à forte croissance. Stargate a commencé sa vie comme un fork du code coordinateur de Cassandra, il hérite donc d'une grande partie de la fiabilité et de la disponibilité pour lesquelles Cassandra est bien connue.

Le niveau API doit être entièrement capable de fonctionner à grande échelle, donc un autre objectif de Stargate v2 était de le rendre plus convivial pour le cloud. Plusieurs changements pour faciliter l'évolutivité de Stargate incluent :

• Stargate est désormais entièrement conteneurisé et s'exécute dans des pods Kubernetes, ce qui donne aux opérateurs plus de contrôle sur la façon dont les charges de travail peuvent évoluer.

• Les services API ont été déplacés du nœud Stargate monolithique vers des microservices séparés, ce qui permettra à chaque API d'être mise à l'échelle indépendamment.

• Les nœuds de stockage et les nœuds de coordination sont indépendamment déployables et évolutifs, ce qui donne également aux opérateurs plus de contrôle sur la façon dont les charges de travail peuvent évoluer.

  
  

Si une charge de travail est gourmande en requêtes ou en stockage, elle peut être ajustée sans recourir à la mise à l'échelle de l'ensemble du cluster dans son ensemble.

Développer avec quelque chose de familier

Les services de données cloud sont devenus le thème dominant dans le monde de la technologie, il n'est donc pas surprenant que les développeurs aient tendance à penser en termes d'abstractions de données comme JSON au lieu d'idiomes propres à des bases de données particulières. Stargate est l'aboutissement de beaucoup de travail acharné pour rencontrer les développeurs là où ils se trouvent, leur permettant de travailler dans des cadres et des structures avec lesquels ils sont familiers.

En savoir plus sur Stargate ici .

Par Ed Anuff.