Je me pose toujours la question de la pertinence d'une BD qui stocke à la fois des paramètres de config et de session
Et c'est en effet une très bonne question, sauf qu'il faut voir l'application comme une boite noire qui expose une API REST.
J'utilise la BD pour la configuration de certains aspects parce que c'est le meilleur moyen que j'ai trouvé pour avoir une configuration pérenne et dynamique, tout en gardant le principe KISS dans un coin de la tête.
Mais tout ce qui est configuration des modules: CRUD des modules backend utilisateurs ou clients, CRUD des plugins, CRUD des schémas d'authentification, tout se fait via l'interface graphique d'administration, parce que ces parties-là sont plus complexes à configurer et qu'une UI qui t'accompagne en te disant ce que tu as le droit de faire ou non, c'est plus simple à utiliser qu'un fichier de config à plat ou un fichier XML pour lequel il faut lire et comprendre la doc. Ca permet aussi d'avoir plein de modules qui "juste marchent" sans forcément avoir à tout comprendre, typiquement les schémas HOTP/TOTP ou Webauthn.
Ensuite, il faut voir que la config en BD n'est lue qu'au démarrage de l'application, puis "mappée" en mémoire, ou rechargée lorsqu'on modifie la config via les API. Donc la question de distinguer la BD de config de la BD de session ne se pose pas trop non plus je pense.
Et comme toute la config stockée en BD est accédée entièrement via les API REST, tu as la possibilité d'automatiser l'administration via des scripts qui font des appels HTTP à l'ancienne.
A-t-on besoin d'une base de donnée relationnelle, donc avec transaction ?
Ca aussi c'est une bonne question!
Au début de mon ère néo-productiviste libriste avec les API REST en C, je me demandais justement si j'allais pas directement taper sur des bases de données NoSQL comme MongoDB, qui est d'ailleurs un peu la seule que je connais pour l'instant, et encore très peu, plutôt que de rester sur les vieilles techno à grand-papa comme le SQL. À l'époque, j'entendais parler du NoSQL partout sans trop savoir c'est quoi, et moi aussi je voulais être copain avec le nouveau gars cool de l'école.
Sauf que justement je ne connais pas tant que ca le NoSQL, et mon approche de modélisation était et est encore très modèle relationnel. Quand je pense à une structure de données à persister, je vois facilement son schéma SQL dans ma tête. J'aime bien utiliser des technos récentes mais quand c'est justifié, pas juste pour utiliser des trucs hype. J'ai donc préféré rester sur mon approche à l'ancienne qui ne m'a posé aucun problème. Je ne critique même pas le NoSQL, je dis juste que j'en ai pas encore l'utilité.
Les transactions SQL ne sont pas utilisées dans Glewlwyd, l'architecture REST et la façon dont sont identifiées les données permet de l'éviter.
Je ne connais ni Riak, ni Etcd, merci pour l'info.
Dans la mesure où je fais Glewlwyd avant tout pour moi, sur mon temps libre, je préfère utiliser des technos que je connais et que je maîtrise.
Par contre, si quelqu'un me propose un patch ou de l'aide pour migrer sur une autre persistance qu'une base SQL, je suis preneur!
[^] # Re: Base de données
Posté par Babelouest (site web personnel) . En réponse au journal Sortie de Glewlwyd 2.0, serveur SSO. Évalué à 5.
Et c'est en effet une très bonne question, sauf qu'il faut voir l'application comme une boite noire qui expose une API REST.
J'utilise la BD pour la configuration de certains aspects parce que c'est le meilleur moyen que j'ai trouvé pour avoir une configuration pérenne et dynamique, tout en gardant le principe KISS dans un coin de la tête.
Glewlwyd utilise un fichier de config au format libconfig, ce fichier contient la configuration dite statique et hardcore de Glewlwyd, avec notamment l'url externe, le chemin local vers les fichiers statiques du front-end, le chmin local vers les modules ou encore la connexion vers base de données.
Mais tout ce qui est configuration des modules: CRUD des modules backend utilisateurs ou clients, CRUD des plugins, CRUD des schémas d'authentification, tout se fait via l'interface graphique d'administration, parce que ces parties-là sont plus complexes à configurer et qu'une UI qui t'accompagne en te disant ce que tu as le droit de faire ou non, c'est plus simple à utiliser qu'un fichier de config à plat ou un fichier XML pour lequel il faut lire et comprendre la doc. Ca permet aussi d'avoir plein de modules qui "juste marchent" sans forcément avoir à tout comprendre, typiquement les schémas HOTP/TOTP ou Webauthn.
Ensuite, il faut voir que la config en BD n'est lue qu'au démarrage de l'application, puis "mappée" en mémoire, ou rechargée lorsqu'on modifie la config via les API. Donc la question de distinguer la BD de config de la BD de session ne se pose pas trop non plus je pense.
Et comme toute la config stockée en BD est accédée entièrement via les API REST, tu as la possibilité d'automatiser l'administration via des scripts qui font des appels HTTP à l'ancienne.
Ca aussi c'est une bonne question!
Au début de mon ère néo-productiviste libriste avec les API REST en C, je me demandais justement si j'allais pas directement taper sur des bases de données NoSQL comme MongoDB, qui est d'ailleurs un peu la seule que je connais pour l'instant, et encore très peu, plutôt que de rester sur les vieilles techno à grand-papa comme le SQL. À l'époque, j'entendais parler du NoSQL partout sans trop savoir c'est quoi, et moi aussi je voulais être copain avec le nouveau gars cool de l'école.
Sauf que justement je ne connais pas tant que ca le NoSQL, et mon approche de modélisation était et est encore très modèle relationnel. Quand je pense à une structure de données à persister, je vois facilement son schéma SQL dans ma tête. J'aime bien utiliser des technos récentes mais quand c'est justifié, pas juste pour utiliser des trucs hype. J'ai donc préféré rester sur mon approche à l'ancienne qui ne m'a posé aucun problème. Je ne critique même pas le NoSQL, je dis juste que j'en ai pas encore l'utilité.
Les transactions SQL ne sont pas utilisées dans Glewlwyd, l'architecture REST et la façon dont sont identifiées les données permet de l'éviter.
Je ne connais ni Riak, ni Etcd, merci pour l'info.
Dans la mesure où je fais Glewlwyd avant tout pour moi, sur mon temps libre, je préfère utiliser des technos que je connais et que je maîtrise.
Par contre, si quelqu'un me propose un patch ou de l'aide pour migrer sur une autre persistance qu'une base SQL, je suis preneur!