L’essor des bases de données sans serveur (Partie 1)

En tant que développeurs front-end, nous comprenons le rôle fondamental Les données joue dans nos tâches quotidiennes. Il peut provenir d’une API externe, d’un CMS ou même d’un tableur. Mais Dieu nous en préserve, nous devons parler de la création de bases de données.

Ces jours sont révolus. Les bases de données sans serveur devenant de plus en plus populaires, il n’a jamais été aussi facile de créer une architecture complète avec une mise à l’échelle verticale et horizontale, une haute disponibilité et une cohérence à toute épreuve.

Pour profiter pleinement des avantages d’une telle architecture, il est essentiel de comprendre quelles décisions sont prises pour toi. De la même manière que le mantra « apprendre JavaScript, pas un framework » est devenu populaire, nous devons également comprendre les concepts sous-jacents à l’architecture de base de données afin de les utiliser de manière fiable. Alors, bienvenue dans la première partie de notre « Bases de données pour les développeurs front-end » série.

Cette série ne fera pas de vous un expert des systèmes distribués ou capable d’accéder à un rôle d’administrateur de base de données, mais elle vous éclairera sur les concepts, les termes et les acronymes auxquels vous serez confronté lorsque vous vous préparerez à choisir votre prochaine pile. Voyez-le comme une introduction aux bases de données (sans serveur). Espérons que cela vous donnera un coup de pouce dans le terrier du lapin et vous rendra confiant pour rejoindre des conversations afin d’évaluer les compromis pour différentes solutions.

Feuilles de calcul et systèmes de gestion de contenu

Quoi?! Feuilles de calcul ? Hé bien oui. L’interface utilisateur (vous et moi, ou U et moi, ou UI) est assez similaire à celle d’une base de données. Les feuilles de calcul vous donnent un tableau dans lequel stocker des données. Dans certains cas, ils vous permettront uniquement de définir des types de données spécifiques par colonne. Les familiarités sont là, mais les feuilles de calcul trouvent une fin abrupte une fois que nous avons ouvert le capot.

La disponibilité est discutable : les feuilles de calcul ne sont pas destinées à servez contenu, seulement boutique contenu. Pour commencer, ils n’alimenteront pas une application à mesure qu’elle évolue, et ils peuvent ne pas obéir à certaines meilleures pratiques lorsqu’il s’agit d’assurer l’intégrité des données. Jusqu’à très récemment, ils constituaient le moyen le plus rapide de démarrer avec une couche de données. Mais maintenant, il n’y a pas de point pour une application ne pas pour utiliser une base de données réelle (sans serveur) (plus à ce sujet plus tard).

UN Système de gestion de contenu (CMS) est un autre type de base de données. Le « contenu » est un type particulier de données dans lequel le CMS est spécialisé. Il fournira à l’utilisateur (développeur) suffisamment d’abstractions pour faciliter la gestion de ces données à un point où la base de données sous-jacente n’est pas un problème. Il gérera la délivrabilité, la disponibilité et l’intégrité de vos données. Mais plus l’abstraction est lourde, plus le compromis est élevé. Les types de données sont limités à ce que le CMS vous donnera, la plupart imposant même leur propre architecture pour gérer les relations, les requêtes, les types, etc. Bien sûr, il existe encore des cas d’utilisation significatifs et viables pour les CMS, et ils ne vont pas partout. Donc, tant que vous êtes sûr que c’est ton cas d’utilisation, vous serez bien avec un.

Douleurs de croissance

Si vous choisissez la voie la plus simple et «abstraite» d’une feuille de calcul ou d’un CMS comme source de vérité et que vos données commencent à se diversifier, des obstacles apparaîtront. Le premier problème avec une feuille de calcul concerne généralement l’API sous-jacente, elle n’est souvent pas destinée au trafic de la plupart des applications de taille moyenne, puis il y a les premières conversations de refactorisation.

Avec un CMS, les API ne sont généralement pas le problème, mais la gestion des données peut l’être. À mesure qu’une application se développe et que les données se diversifient, certaines d’entre elles finissent par ne plus être contenu plus et peut être plus lié à la logique de l’application.

Lorsque les données ne sont pas du contenu, les gérer dans un CMS n’est pas idéal. Il est moins flexible et ne correspond souvent pas au flux de travail propriétaire-équipe. Désormais, s’il est parfaitement possible que d’autres bases de données et CMS coexistent, il appartient aux développeurs de comprendre les avantages et les inconvénients de chaque solution et de décider ce qui convient le mieux à la livraison de leur application et à l’expérience utilisateur.

L’administration de la base de données est difficile

En tant que développeurs front-end, la première fois que nous parlons de bases de données est généralement une conversation sur « relationnel vs non relationnel ». Dès lors, tout en essayant de comprendre les différences, nous entendons vaguement une myriade de termes, tels que ACID, BASE et même CAP Theorem. Cet article sautera une explication approfondie de ces différences. Nous les examinerons de plus près dans la prochaine partie de cette série. Pour l’instant, il suffit de dire que les bases de données « non relationnelles » imposent cohérence éventuelle sur une application.

La cohérence éventuelle peut également être décomposée en une discussion plus longue, mais prenons-la comme ceci :

La cohérence éventuelle signifie que dans certaines conditions particulières, les données reçues sont obsolètes.

Comme les commentaires dans un article de blog, ils n’affecteront pas votre application si quelques secondes après un écrivez vous ne voyez toujours pas le dernier. Mais les mises à jour de mot de passe doivent être fortement cohérent toujours, pas finalement cohérent.

Bien sûr, ce ne sont pas les seules différences. Les performances des requêtes sont différentes entre chaque type de base de données. On peut imaginer qu’être finalement cohérent permet d’être plus rapide lit parce qu’il y a moins d’assurance impliquée.

Plus de douleurs de croissance

Une fois la base de données décidée, l’application peut se développer régulièrement et en douceur pendant un certain temps. À mesure qu’une application grossit, la complexité des données augmente et, à mesure que la complexité des données augmente, la base de données devient plus lente. À grande échelle, comment rendre une base de données plus rapide ?

• Ajoutez-vous plus de ressources à un seul serveur ? (échelle verticale)
• Comment répliquer des données sur un cluster de machines ?
  • Divisez-vous plutôt votre base de données en partitions plus petites (fragments) ? (échelle horizontale, plus à ce sujet dans la partie 2)
• Ajoutez-vous une base de données en mémoire plus rapide devant pour les requêtes courantes ? (magasin clé-valeur)

Ce ne sont pas des questions faciles à répondre. Cela dépend de la base d’utilisateurs, du type de données, de la quantité, de la fréquence et de l’origine des requêtes. Votre base de données est-elle lourde en lecture ou en écriture ? Et bien qu’il y ait une multitude de facteurs qui influent sur cette décision, il y a aussi un coût élevé à faire le mauvais choix.

De plus, certains cas d’utilisation peuvent même nécessiter une recherche plus facile dans les données à partir de l’espace utilisateur. Un moteur de recherche n’est pas un problème facile à résoudre et nécessite souvent un type de base de données supplémentaire pour indexer correctement vos données (si elles sont fragmentées, c’est encore plus difficile). Avoir tout cela autour des données de votre utilisateur apporte également tout un ensemble d’outils juste pour le rendre maintenable.

De plus, garder un œil sur nos bases de données (désormais « infrastructure de données » si nous avons un moteur de recherche dans le mix) nécessite un haut niveau d’observabilité et OLAP (traitement analytique en ligne). Cela introduit un tout nouveau niveau de complexité !

Comme vous l’avez peut-être remarqué, des enjeux très importants sont associés à la création, à la maintenance et à la croissance d’une base de données. Des décisions qui peuvent faire ou défaire une application, des décisions coûteuses à reprendre et qui doivent être prises relativement tôt.

Les bases de données sans serveur sont amusantes

En raison de toute la complexité mentionnée ci-dessus, de nombreux investisseurs et incubateurs ont les yeux tournés vers les startups créant des bases de données sans serveur. Il s’agit d’une toute nouvelle catégorie de bases de données. Les concepts des traditionnels s’appliquent toujours, mais différemment.

Bases de données sans serveur

Pour comprendre ce qu’est vraiment une « base de données sans serveur », nous devons d’abord déconstruire le terme. C’est une blague courante que « sans serveur » est un abus de langage. Pourtant, le but d’une architecture sans serveur est d’abstraire du consommateur (développeur) la complexité de la gestion de la fiabilité du site et de la maintenance du serveur fournie par un fournisseur sans serveur, tel que Netlify, Vercel, Amazon Web Services (AWS) et tant d’autres. . J’ai tendance à aimer La définition de Xata de « base de données sans serveur ».

Une «base de données sans serveur» fait pour les bases de données ce que sans serveur fait pour les serveurs. La complexité est levée (à des degrés divers selon la plateforme choisie). Certains, comme Supabase et Firebase, offriront une multitude de fonctionnalités liées au serveur à coupler avec votre base de données ; d’autres, comme AWS Aurora ou PlanetScale, visent à faciliter l’utilisation et la mise à l’échelle des bases de données PostgreSQL et MySQL. Et enfin, il y en a d’autres qui font entièrement abstraction de la base de données, comme Xata. Ils vous fournissent un SDK de type ORM, conservent la base de données derrière une API et sont capables d’offrir un ensemble complexe de fonctionnalités de base de données, contournant les limitations actuelles des bases de données relationnelles et non relationnelles traditionnelles.

Une fois que nous arriverons à la prochaine partie de cette série, nous parlerons de différents types de bases de données. Ensuite, vous serez prêt à ouvrir le capot sur n’importe quelle offre de base de données sans serveur que vous souhaitez et à comprendre les différences par vous-même. En attendant, restons superficiels.

Batteries incluses

Ne prenez pas le préfixe « sans serveur » à la légère ; ces bases de données sont d’une race différente. Elles sont capables d’offrir des garanties et des performances que les bases de données « traditionnelles » nécessitent des efforts pour atteindre, parfois même pas. En effet, sur les bases de données sans serveur, le travail a été effectué, mais pas par votre équipe.

De la même manière que « sans serveur » signifie que vous n’avez pas besoin de gérer votre serveur, « base de données sans serveur » signifie que vous n’avez pas besoin de gérer votre base de données. La plateforme s’en chargera pour vous.

Pour cette raison, les décisions concernant l’évolutivité et la délivrabilité sont souvent prises en dehors de votre équipe. Ce que votre équipe obtient, c’est l’assurance que toute demande recevra une réponse dans les meilleurs délais et que les données respecteront les garanties de cohérence. Encore une fois, différentes solutions ont des compromis différents. Il est important de vérifier ce que chaque offre impose avant de se lancer.

À la prochaine

J’espère que cela a suffi à éveiller votre curiosité. Ceci est le premier article d’une série en 3 parties. Dans les prochaines, nous couvrirons des informations plus détaillées sur les bases de données réellement sommes. Plus précisément, nous examinerons :

• Schémas,
• Théorèmes et modèles,
• Types de bases de données,
• tout ce que vous suggérez dans les commentaires ci-dessous!

Toutes ces connaissances nécessaires vous permettront de choisir la meilleure solution pour votre application. Comprendre les compromis des différentes solutions sans serveur et s’entourer du bon type d’aide est essentiel pour configurer votre application pour réussir. Contactez-moi si tu as besoin de quoi que ce soit entre-temps. Sinon, rendez-vous dans quelques jours !

Lectures complémentaires sur Smashing Magazine

(yk, il)