Passer de frontend à backend - les bases de données

La maîtrise de vos données 👌

Un des pilier d'une application c'est bien la couche de données, d'ailleurs, je pense même que c'est la couche technique (non perçu par le client) la plus importante, et je vais vous expliquer pourquoi.

Les données sont les seuls éléments de votre application dont l'intégrité est un besoin capital et la disponibilité une préoccupation majeure.

Pour le dire simplement, on peut changer la couche graphique (partie frontend) de votre application, on peut changer votre backend (remplacer les API par un nouveau framework, un nouveau langage), mais vos données doivent rester intactes et accessibles.

Il faut que vos données soient sans cesse cohérentes et que l'accès au données soit contrôlé. Tant au niveau de la base elle même (user/password), mais aussi au niveau accès ressource. Un utilisateur peut modifier son compte utilisateur mais pas celui d'un autre. Comprenez qu'il y a des mécaniques de vérification qui devront être pris en compte et surtout mis en place.

Quels sont les points à maîtriser pour déployer notre base de données applicative sereinement ?

Choisir sa base 🤔

Il y existe plusieurs types de bases de données que vous pouvez déployer pour faire votre application. Chacun avec ses avantages et ses inconvénients :

• les bases SQL : efficace pour le calcul et l'association de données inter-table (en gros je peux facilement associer un produit à un utilisateur etc car ces bases de données sont dites relationnelles).
• les bases NoSQL : qui signifie Not Only SQL et pas No SQL... Qui sont des bases orientés document (où il est plus difficile de faire des associations inter-données, mais qui permettent d'avoir une structure plus malléable).

Une des grosses différences entre ces deux types de bases, c'est que les bases SQL ont besoin d'avoir une structure bien définie : un champs possède tel nom et est de tel type (définition des colonnes). SQL est une base pratique pour un projet mature en terme de besoin :

• vous savez quelle donnée vous souhaitez enregistrer,
• vous savez pourquoi vous stockez ces informations
• et quels sont les liens entre ces données.

Alors que la base de donnée documents vous permet d'être beaucoup plus souple : vous pouvez faire évoluer la source de données quand bon vous semble et ajouter des champs à la volée. Il est même possible que dans une source de même type, les documents aient des clés différentes. Ce type de base est parfait dans une phase de rodage du modèle de donnée et de structure. De même, sa performance fait que vous pourrez la garder indéfiniment tant que votre structure est optimisée.

Par exemple, en NoSQL, il est possible d'avoir une source de données Produits, et un produit aurait la clé "size" et un autre produit aurait la clé "quantity" sans la clé size... Je ne recommande pas cette pratique qui crée beaucoup de confusion à la lecture des données et vous force à implémenter beaucoup de vérifications.

Concernant les technologies à votre disposition, pour les bases SQL, les plus utilisés sont les bases MySQL et PostgreSQL . Les deux fonctionnent très bien et possèdent une communauté très active si vous cherchez de la documentation.

J'ai une tendance particulière à aller vers du MySQL pour des projets simples et du PostgreSQL pour des projets plus complexes avec beaucoup plus de données (> 1go).

Pour les bases NoSQL, les plus connus sont MongoDB et les bases Neo4j . J'adore MongoDB, c'est un type de base que j'utilise souvent pour prototyper rapidement.

Pour les bases Neo4j, je dois admettre que je n'y connais pas grand chose car je ne m'en suis jamais servi. Mais le concept est le suivant : essayer de garder les avantages des bases documents en mettant l'accent sur les relations inter-données. Ce qui nous donne une base de données orienté graph (pour faire le lien entre les données). Et ici l'objectif est clair, essayer de faire des bases documents avec les avantages des bases relationnels. Cependant la syntaxe est particulière et il vous faudra apprendre le Cypher, un graph query langage qui vous permet de faire des requêtes.

Le sujet de la base de données est tellement un sujet critique que de nombreux acteurs ont cherché à résoudre cette problématique afin de vous apporter des solutions simples.

Google déploie plusieurs services de données simples en SaaS :

• Firebase : une base documents simple avec une couche socket pour propager des événements
• Firestore : comme firebase mais avec des services en plus comme les notifications, le machine learning, etc...
• Datastore : commence à être abandonné pour firestore (les API sont dores et déjà les mêmes)
• Bigtable : base de données NoSQL pour des grosses opérations (calculs de stats, analyse, etc...)

Amazon aussi met en place plusieurs services :

• DynamoDB : une base documents peu coûteuse et pratique
• DocumentDB : une base de données MongoDB-like (les prix commencent à 190$ environ par mois)
• RDS : une base de données SQL (MariaDB ou PostgreSQL)

Il existe bien d'autres offres en SaaS pour les bases de données, mais je ne vais pas faire une liste exhaustive des possibilités. Je vous ai listé ici les plus utilisés et les plus documentés.

Tous ces services sont managés pour vous, cela signifie que vous n'aurez pas à les tenir à jour en terme de version, de sécurité, d'intrusion, etc... Les providers s'occupent de tout et c'est là l'intérêt. Mais vous l'aurez compris, il s'agit d'un service donc cela vous demandera de mettre la main au portefeuille.

Utiliser un ORM ⚒️

Si vous décidez de partir sur une base déployée par vos soin : SQL ou base document. Vous allez devoir gérer le service, les montées en version, la maintenance etc... Mais pas que !

Côté code, il faut réussir à vous y connecter. Et pour ce faire, il y a des librairies qui gèrent pour vous, de manière simple, les sockets et l'accès aux données.

Ces librairies s'appellent les ORM : Object-Relational Mapping, c'est à dire un objet qui est lié à la donnée depuis le code. Soit une visualisation simplifiée de la donnée afin de la manipuler plus facilement.

Pour les bases SQL, les ORM sont légions :

• Knex.js
• Prisma
• Sequelize

Ces ORM sont très bien documentés et tout ce dont vous avez besoin est à votre disposition. Comment créer un objet, comment écrire, comment lire, comment mettre à jour et comment supprimer... Tout y est !

Pour les bases de données NoSQL, notamment MongoDB :

• Mongoose : l'ORM le plus connu
• Prisma : avec une syntaxe très proche du modèle SQL

L'ORM vous garantie d'accéder à la donnée de manière efficace, sans duplication de code et de cadrer votre utilisation par les conventions. Dans une équipe, cela vous permettra d'avoir un code source organisé et de pouvoir travailler en toute cohésion grâce à une méthodologie commune.

D'une certaine façon, les bases de données SaaS déployés par les providers sont eux-aussi livrés avec des librairies en guise d'ORM. Cela facilitera son intégration et soyez sûr qu'ils aient mis le paquet sur la documentation puisqu'ils souhaite une adoption massive du marché. Ce qui signifie que la qualité du service et de la documentation seront au rendez-vous.

Les points d'attention ⚠️

Après avoir vu les types de base de données et les ORM, il est temps de parler de ce sûr quoi vous devez être vigilent pour vous assurer le maximum de confort et de fiabilité en matière de données.

La performance des bases de données ⚡️

Premièrement je vais aborder le sujet de la performance lorsque l'on fait un choix de base de données.

On s'attend à :

• des réponses rapides
• pouvoir faire des tris rapidement
• pouvoir filtrer les résultats

La performance est souvent un des critères mis en avant pour le choix d'une base de données. Mais sachez que la performance ne dépend pas que de la technologie mais aussi des performances machines.

Une machine avec un SSD, beaucoup de RAM et beaucoup de cores sera forcément plus performante qu'une demi-VM avec une ram ponctionnée et 50% du temps CPU... On va dire que jusque là tout est logique.

Mais il faut savoir que la performance s'entretient ! Il n'est pas rare de voir les performances d'un système de base de données décliner dans le temps.

Pourquoi ?

Tout simplement parce qu'il y a plus de données à traiter...

Que peut-on faire dans cette situation ?

Les indexes 🔍

Y-penser dès le départ en anticipant sur les tables qui vont grossir rapidement, les colonnes clés sur lesquels filtrer, etc... Et mettre en place des indexes. Les indexes vont jouer comme des poids dans la structure de vos données. En gros, ils vont expliquer au moteur de base de données qu'est-ce qui est suffisamment important pour que la base optimise la distribution de cette donnée.

Pour vous illustrer un peu cela :

Lorsque l'on crée une table Users, votre clé primaire ID est indexée par défaut. Autrement dit, lorsque vous recherchez un User, en mettant une condition sur l'ID vous irez beaucoup plus vite que si vous le cherchez par son email.

Maintenant, le système d'indexation n'est pas exclusivement dédié à la clé primaire, vous pouvez très bien indexer n'importe quelle donnée de votre table. Car vous savez que vous vous servirez de tel champs pour vos requêtes. Et cette optimisation prendra certes un peu plus d'espace sur le disque, mais vous sauvera la mise quand vous aurez atteint une taille critique de base.

De plus, le système d'indexes n'est pas réservé aux bases SQL. Vous pouvez tout aussi bien mettre des indexes sur des bases NoSQL. Il faut garder en tête que c'est important et y penser en amont.

Le nettoyage des bases 🧹️

Par ailleurs, il y a aussi à travail à faire quant au nettoyage des données. Lorsqu'un projet va durer dans le temps et risque de fortement grossir, il faut mettre en place des règles de nettoyage de votre base de données.

En PostgreSQL vous avez un système de VACCUM qui va surtout être utile pour la partie disque. Mais entre-nous, il y a moyen d'optimiser tout type de base à condition d'avoir une méthode et de faire des choix.

Sur d'anciens projets, on avait pris l'habitude de garder 1 à 2 ans d'historique en base dite "active" et de basculer le reste en base dite "d'archive". Cela permet de maintenir le volume de données dans une tranche qui fait que le temps de traitement sera impacté dans une moindre mesure.

Après, il faut que le projet s'y prête, mais globalement on a toujours des méthodes qui permettent d'adapter la mise en place de ce genre de bascule. Typiquement, vous pouvez décider que pour les années à archiver, on ne garde en base que les minimum, maximum et moyenne pour certaines métriques, etc...

Je vous le disais, il s'agit de choix, dans le but de garder un applicatif fluide lorsqu'il exécute des requêtes.

Votre trousse de premier secours 🚑

Il est impératif de vous munir d'outils pour des interventions rapides en cas d'urgence. Il vous faut constituer ce que j'appelle la trousse de secours de votre base de données.

Autrement dit, je me prépare souvent une liste de scripts prêt à être exécutés via un CLI (terminal) à tout moment pour me sauver la mise en cas de besoin.

En général il faut que ce genre d'opération mette moins d'une minute à lancer (l'exécution, c'est autre chose...).

Voici la liste de ce que je garde sous le coude en cas de besoin :

• Un script de déploiement de la base
• Un script de backup de votre database
• Un script de restauration votre base
• Un script pour créer vos utilisateurs
• Un script pour mettre à jour un mot de passe utilisateur
• Un script qui permet de feed (mettre en base les données essentiels au bon fonctionnement de votre projet)

Voilà je pense qu'on a fait un peu le tour pour la partie base de données. Comme vous pouvez le voir il y a de nombreux sujets à aborder, et il en reste encore tellement !

Je peux vous rassurer, j'ai commencé de 0 moi aussi, et ces informations deviendront totalement logiques et simples pour vous aussi dans très peu de temps. Il suffit de s'y mettre !

Dans un prochain article on parlera des déploiements, restez connectés ! 😉