Présentation rapide de RootDB, une application auto-hébergeable open-source (AGPLv3), permettant de générer des rapports à base de requêtes SQL.
Sommaire
Genèse du projet
Pour les besoins d'un client, il fallait que je génère rapidement des statistiques d'usage diverses et variées (à bases de tableaux et graphiques), à partir de plusieurs base de données relationnelles classiques et que j'intègre ces rapports dans un backoffice.
Le premier réflexe fut de me tourner vers une solution que j'ai utilisée pendant une dizaine d'années auparavant et qui se nomme MyDBR. Cela répondait parfaitement à son besoin tout en étant abordable. MyDBR, bien maitrisé, permet de faire énormément de choses, mais l'interface est vraiment datée et l'accès aux fonctionnalités des bibliothèques graphiques se fait par l’intermédiaire de wrappers en SQL.
J'ai cherché des alternatives, auto-hébergeables, simples à mettre en place, maintenues et avec la même logique pour la création de rapport mais je n'ai pas trouvé mon bonheur. Il y a, évidemment, pleins de solutions qui existent mais il y avait toujours quelque chose qui n'allait pas après essai, que ce soit dans la manière de générer des rapports ou bien les pré-requis, parfois compliqués, pour l'hébergement.
D'ou l'idée de créer, avec un collègue, notre propre solution de reporting - parce que pourquoi pas, finalement.
Open-source
Ce projet n'était pas open-source à la base et nous pensions simplement vendre des licences d'utilisation.
Sauf qu’aujourd’hui beaucoup de monde utilise le cloud, et ce dernier vient avec ses solutions intégrées de reporting, limitant de fait l'intérêt de ce genre de projet. Pour faire bref, je reste convaincu que tout le monde n'est pas sur le cloud et que ce genre de solution peut encore intéresser quelques personnes.
À cause des doutes sur la pertinence même du projet, je n'ai jamais sérieusement cherché du financement, ce qui ne m'a jamais permis d'être à temps plein dessus. Nous avons donc mis du temps avant de produire quelque chose d'exploitable dans un environnement de production : un an et demi environ.
À cela s'ajoute le fait que ce projet n'existerait pas sans toutes les briques open-source sur lesquelles il se base. Et comme c'est l'open-source qui me fait vivre depuis un certain nombre d'années, il me semblait finalement bien plus naturel de rendre ce projet open-source (licence AGPLv3) que d'essayer de le vendre en chiffrant le code source.
RootDB ?
Étant familier du SQL et du JavaScript, nous voulions avoir une solution qui ne mette pas de bâtons dans les roues du développeur, à savoir :
- utiliser principalement le SQL pour la récupération et le traitement des données ;
- avoir un accès intégral à la bibliothèque graphique choisie ;
Ce choix de préférer un environnement de développement de rapport orienté développeur est assumé, d'où le nom du projet.
Fonctionnalités
Je ne vais pas vous présenter toutes les fonctionnalités car le site web principal et l'instance de démonstration les présentent déjà correctement. Je vais donc plutôt mettre en avant les spécificités du projet.
Websocket
Les requêtes SQL peuvent prendre du temps à tourner, surtout si les tables ne sont pas correctement optimisées. Par conséquent l'interface repose lourdement sur les websockets afin d'éviter les problèmes de timeout. Quand un rapport est exécuté, l'exécution des différentes requêtes est dispatchée de manière asynchrone et les vues affichent des résultats uniquement quand les données arrivent sur le websocket du rapport.
D'une manière générale toute l'interface est rafraichie par websocket.
Bibliothèques graphiques au choix
Nous donnons accès à Chart.js ou D3.js, sans limitation, sans wrapper. Il est donc possible de se référer directement à la documentation officielle de ces deux bibliothèques.
Onglets & Menu
Nous aimons bien les menus. :)
C'est simple, élégant et permet d'accéder à beaucoup d'options de manière claire.
L'interface repose sur une barre de menu principale dynamique et une barre d'onglets dans lesquels s'affiche les différentes parties de l'application. Il est donc possible d'ouvrir plusieurs rapports (ou le même) dans le même onglet du navigateur web.
Cache
Il existe deux niveaux de cache :
- un cache utilisateur, pratique pour cacher des résultats de manière temporaire afin de partager des résultats avec un autre utilisateur.
- un cache système (jobs) ou il est possible de générer du cache de manière périodique. Nécessaire pour des rapports qui utilisent de très grosses tables qu'il n'est parfois pas possible d'optimiser.
Paramètres en entrée
Il est très facile de générer ses propres paramètres afin de filtrer les rapports, que ce soit sur une plage de date, une liste d'options sortie d'une base de données, des cases à cocher etc.
Liens entre rapports
Que ce soit avec Chart.js ou bien un tableau, vous pouvez créer des liens entre vos rapports ou bien sur le même rapport pour faire des rapports de type drill-down.
Hébergement
Côté API, RootDB est une application Laravel qui fonctionne sur du PHP en version 8.2.x (voir 8.3.x, mais pas encore bien testé) et utilise Memcached pour la gestion du cache.
Le serveur de websocket est propulsé par Laravel Reverb.
Côté Frontend, il s'agit d'une application React classique, en TypeScript, qui utilise PrimeReact pour la suite de composants prêt-à-l'emploi.
Conclusion
Concernant les fonctionnalités que nous aimerions mettre en place petit à petit :
- une interface de configuration pour Chart.js - afin de, quand même, rendre plus simple la configuration des charts, tout en laissant la liberté au développeur de coder en javascript les fonctionnalités avancés ;
- un nouveau type de connecteur pour supporter Microsoft SQL Server ;
- une fonctionnalité d'auto-rafraichissement des rapports ;
- l'import asynchrone de gros fichiers CSV ou Excel.
Nous pouvons aider à l'utilisation, par l’intermédiaire :
- d'un salon discord mais ce n'est pas forcément idéal pour ce genre de projet. Je suis donc entrain de regarder du côté de Matrix, éventuellement ;
- un forum classique.
Voilà, c'était une brève présentation de RootDB.
C'est un projet qui n'a pas encore été testé par beaucoup de monde, d’où cette présentation pour le faire connaitre un peu plus.
Aller plus loin
- Site web officiel (1134 clics)
- Dépôt github (186 clics)
- Documentation (50 clics)
- Instance de démonstration (348 clics)
# Par rapport à Metabase ?
Posté par ff9097 . Évalué à 9.
Je connais Metabase dans le même genre (ou alors je me trompe). Est-ce que RootDB réponds au même besoin ?
[^] # Re: Par rapport à Metabase ?
Posté par gyan000 (site web personnel) . Évalué à 8.
Oui, effectivement, RootDB fait partie de la même catégorie d'application.
Mais, comme indiqué dans la dépêche, il faut voir ce projet comme une version plus moderne, niveau interface, de MyDBR donc il faut connaitre le SQL et le JS contrairement à Metabase qui, en cachant par défaut la partie technique, permet à des non-développeurs de générer leur dashboard.
RootDB.. c'est plus root :)
[^] # Re: Par rapport à Metabase ?
Posté par xandercagexxx . Évalué à 1.
Y a-t-il dans vos cartons, l'idée futur de quand même permettre à des non-dev de s'occuper des dashboard, ou c'est clairement pas une option que vous souhaitez ajouter au produit ?
Définir un besoin n'est pas tjrs simple, surtout pour du rendu graphique. Et les dev, ont aussi souvent pas envie de faire les graphiques "marketing" 😁 (ça dépend des dev, mais quand on parle business/marketing, cest pas forcément là que l'on trouve le plus de dev 😁 ).
[^] # Re: Par rapport à Metabase ?
Posté par gyan000 (site web personnel) . Évalué à 3.
On a fait notre MyDBR-like, qui nous convient, certes - et c’était l’objectif initial, mais oui, clairement on est conscient de cette problématique d’accessibilité pour les non-développeurs. D’ou l’idée de commencer par une interface graphique pour configurer les graphiques de Chart.js: pouvoir sélectionner les jeux de données, les trier, créer de liens, ajouter des labels etc, sans code. C’est un travail que nous avons commencé très récemment.
Ensuite, d’un point de vue technique, étant donné que nous stockons déjà côté API une structure des bases de données associées aux connecteurs, ce qui permet d’avoir un peu d’auto-complétion, on envisage également un générateur de requêtes à la Metabase & co - mais je sais pas du tout quand ce genre d’outil arrivera.
# Beau projet
Posté par Bruno (Mastodon) . Évalué à 3.
L'interface m'a fait penser à Apache Superset mais bon c'est un tableau de bords graphique ;-)
[^] # Re: Beau projet
Posté par gyan000 (site web personnel) . Évalué à 5.
Je dirais que tous les dashboards se ressemblent d’une manière générale, mais à première vue c’est vrai que c’est plutôt ressemblant au niveau de la présentation des vues…
Promis on l’a pas fait exprès :)
# Docker or not docker, et autres questions.
Posté par xandercagexxx . Évalué à 1.
Super intéressant même si je suis pas du tout dev (donc moins exploitable par moi directement). Je me dis que cela pourrait peut être remplacer notre Redash au boulot même si cela veut dire que je ne serais plus en mesure de m'occuper du "rendu graphique".
Redash tourne sur du docker chez nous. C'est proposé nativement avec RootDB ? Ou c'est dans les cartons chez vous ? Ou on peut contribuer pour ajouter ça ?
Y a-t-il possibilité de définir la durée de rétention des données ? (Dans une db par exemple). Le cas d'usage : on veut pouvoir générer un graphique sur l'évolution des résultats dans le temps (ce que ne permet pas redash par exemple, et cest bien chiant 🤔 ).
Peut-on créer un graphique qui serait le résultat d'un requêtage sur différentes DB ? (Redash le permet mais cest pas "simple" à faire, voir même plutôt compliqué).
Côté config des graphiques, c'est des fichiers de "conf" spécifique genre un par dashboard ? Que l'on peut"modifier" à la volée ?
Est-il possible de gérer des droits d'accès avec compte utilisateur pour rendre la lecture et le rafraîchissement des données possible à un "simple lecteur" ? (Accès pour un client à un dashboard spécifique, partager le rendu avec un accès public).
Possibilité de limiter l'accès en requêtage à certaines bdd ? (pas vraiment vraiment le cas avec redash).
Vous proposez des contrats de support pour les entreprises ? (Cest envisageable pour vous ?).
En tout cas, ça semble bien intéressant. 👏👏👏👏
[^] # Re: Docker or not docker, et autres questions.
Posté par gyan000 (site web personnel) . Évalué à 2.
Il y une image docker prête à l’emploi et en mettant un proxy nginx devant pour gérer les connexions TLS, ça doit fonctionner de base - je pense.
Je comprends la problématique de rétention des données, mais moins le cas d’usage sur l’évolution des résultats dans le temps ?
En l’état il n’y a pas de mécanisme de gestion de retentions des données avec ce projet, mais en définissant clairement le besoin, ça doit pouvoir s’envisager.
Pas vraiment, désolé :/
Si les base de données sont du même type, par exemple 3 bases de données mysql/mariadb, sur le même serveur, alors oui, il est possible d’écrire des requêtes SQL utilisant ces 3 bases de données.
Mais au delà de ça, non. Ceci dit, nous sommes conscient de cette problématique et j’aimerai bien pouvoir y répondre un jour quand l’architecture pour mettre ça en place sera bien claire dans ma tête :)
Les graphiques sont générés par du code javascript modifiable à la volée. Une vue = son code javascript. Quand une vue est créée, avec un type de graphique sélectionné au préalable, du code SQL et javascript est automatiquement ajouté pour avoir une vue fonctionnelle - de base. Cela permet de guider le développeur sur la manière d’écrire sa requête SQL pour récupérer les données.
Il est possible de restreindre l’accès des rapports à un ou plusieurs groupes d’utilisateurs et/ou à un ou plusieurs utilisateurs spécifiques. Un utilisateur peut avoir qu’un rôle viewer, ne pouvant donc qu’afficher les rapports auxquels il a accès, rien de plus.
Les rapports sont également intégrables dans un site externe, avec un lien semi-public, c’est à dire que le rapport n’est affichable que pour une liste de domaines autorisés. (typiquement on autorise que le domaine du site web qui intègre le rapport) Dans cette situation, le rapport s’affiche directement dans le site web externe, sans avoir besoin de se logger.
Après, il doit être possible de mettre en place un véritable accès public à un rapport, sur RootDB directement, ne nécessitant pas de compte pour être visionné.
Non, je pars du principe que les restrictions d’accès doivent se faire au niveau des utilisateurs enregistrés, dans les bases de données directement, et qui sont utilisés pour configurer un connecteur côté RootDB.
Après il y a une fonctionnalité qui n’est pas encore activée mais déjà fonctionnelle, en réalité, c’est que RootDB permet de gérer une ou plusieurs organisations. Le terme est peut-être mal choisi mais l’idée c’est que une organisation = son lot d’utilisateurs, développeurs, connecteurs, afin que tout soit bien distinct. (seul le
super-adminpeut gérer les organisations) Cela pourrait peut-être répondre au besoin, à voir.Le projet est tout frais, donc il n’y a pas d’offre de support bien établie mais oui c’est envisageable, il faut voir de quoi on parle précisément. Si t’entends par support, ajouter des fonctionnalités manquantes, oui, clairement ça peut m’intéresser. :)
En tous cas, merci pour toutes ces questions. C’est toujours intéressant d’avoir ce genre de retour, ça permet d’avoir des pistes sur les fonctionnalités à intégrer.
[^] # Re: Docker or not docker, et autres questions.
Posté par xandercagexxx . Évalué à 0.
Merci pour les retours détaillé. J'ai vu qu'il y avait déjà pas mal de réponses sur le site web, mais la au moins c'est plus "clair" pour moi 🤓
Je vais voir en interne chez nous pour mieux formuler certaines questions/cas d'usage, et on remettra les questions ici (ou directement sur le forum/github).
Sur la durée de rétention, par exemple, tu peux avoir une requête en db qui te donne le nombre de compte utilisateur crée/activé chaque jour.
Si tu veux avoir une vue dans la durée (évolution du nombre d'inscriptions sur un temps long (plusieurs années) il faut faire une requête qui va aller regarder la date de chaque création de compte (et regrouper par jour / années). Alors que si l'on a fait la requête 1 fois par jour pour un dashbord, finalement en stockant juste le résultat de la requête, on peut voir l'évolution dans le temps, sans avoir une longue requête sur la bdd de l'outil en prod. Ça veut dire aussi, que l'on peut garder un historique de l'évolution des inscriptions, même si l'instance du produit a été supprimé (dans le cas où tu as le méme outils déployé pour plusieurs clients, et que tu souhaiterais pouvoir évaluer "après coup" comment l'outil a été utilisé ou non).
[^] # Re: Docker or not docker, et autres questions.
Posté par xandercagexxx . Évalué à 0. Dernière modification le 04 mai 2024 à 16:24.
Y a t'il un paramètre à activer pour afficher la structure de la base de données sur laquelle on est connecté ?
Et dans la même approche, y a t'il un paramètre à activer pour avoir de l'auto complétion quand on écrit une requête sql ?
Les 2 questions sont pour une connexion avec des bases postgresql.
Je suis en train de faire un essai rapide en local avec docker, et je suis surpris de pas avoir cette facilité dans l'écriture d'une requête (mais essai super quick donc je suis peut être passé a côté de quelque chose).
Bon weekend
[^] # Re: Docker or not docker, et autres questions.
Posté par gyan000 (site web personnel) . Évalué à 2.
Non, tu n'es passé à côté de rien !
Une fois le connecteur configuré, tu dois avoir de l'auto-complétion. Et la console SQL doit t'afficher sur la gauche toute l'arborescence de ta base de données.
Si ça ne fonctionne pas… c'est un bug.
Et je viens de me rendre compte qu'il est indiqué nulle part, maintenant, que le support de PostgreSQL est expérimental. (c'était indiqué clairement sur une autre page du site web avant que le projet ne passe open-source)
Je n'exploite pas de base de données Postgre en production donc c'est pas bien testé de mon côté, du coup voilà le résultat…
On va vérifier ça pour la prochaine release.
Merci pour ton retour et désolé..
[^] # Re: Docker or not docker, et autres questions.
Posté par xandercagexxx . Évalué à 1.
Un dernier message :)
Je fais une requête simple sur ma base de données "select * from users" et dans le tableau de résultat, je ne vois pas les valeurs true ou false de certaine colonne.
Par exemple, avec psql j'ai pour is_active la valeur f (pour false) et is_deleted la même valeur.
Dans rootdb, l'affichage ne me montre rien pour le même utilisateur (ni false, ni f, rien du tout). C'est plutôt un bug d'affichage ou c'est plus "grave" ?
(Même requête faite depuis psql que dans l'interface de rootdb).
Les autres valeur sont correctement retourné (seul les "true" "false" ne semble pas marcher).
🤔
[^] # Re: Docker or not docker, et autres questions.
Posté par gyan000 (site web personnel) . Évalué à 2.
C.f mon commentaire juste avant, merci d'avoir pris le temps de tester.
J'ai créé un ticket sur Github pour vérifier tout ça.
[^] # Re: Docker or not docker, et autres questions.
Posté par Marc Quinton . Évalué à 3. Dernière modification le 04 mai 2024 à 15:00.
concernant Docker, la réponse est ici : https://documentation.rootdb.fr/install/install_with_docker.html
et les docker-compose.yml ici : https://github.com/RootDBApp/infra
[^] # Re: Docker or not docker, et autres questions.
Posté par xandercagexxx . Évalué à 1.
Merci 🤓
# www
Posté par qui . Évalué à 4. Dernière modification le 04 mai 2024 à 09:48.
https://www.rootdb.fr fonctionne mais pas https://rootdb.fr.
Problème de paramétrage du certificat ?
[^] # Re: www
Posté par gyan000 (site web personnel) . Évalué à 5.
Effectivement, mon certificat wildcard
*.rootdb.frne fonctionnait avec le vhost qui gère la redirection vers le sous domainewww.C’est réglé, merci de l’avoir signalé !
# Joli
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
C'est un beau projet, merci de l'avoir opensourcé !
[^] # Re: Joli
Posté par gyan000 (site web personnel) . Évalué à 4.
Et en espérant que ça puisse être utile à d'autres.
Mais je sens qu'il va y avoir du bug à résoudre… :)
[^] # Re: Joli
Posté par xandercagexxx . Évalué à 2.
C'est "l'avantage" de l'opensource. La possibilité d'avoir pleins de bug remonté facilement par les utilisateurs/testeurs 🥳 (on paye rien et les gens passe du temps a remonter les problème 🎉🎉 ).
Après, il faut juste ne pas se décourager sous l'empleur des bug remonté 😱
Personnellement, un projet qui a une belle liste de bug, ça me rassure dans le sens où cela veut dire qu'il y a du monde qui l'utilise 🤓🤓
Un projets sans bug, c'est pour moi pas un bon signe (un outil parfait existe-t-il ? )
Car la réalité c'est qu'il y a tjrs des cas chelou, des régressions et autres truc que l'on ne peut pas tester quand on développe un produit.
Bon courage pour la belle aventure qui démarre 👏
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.