Architecture : Vue d’ensemble de l’architecture de QoreDB

Vue d’ensemble de l’architecture de QoreDB

Le paysage des clients de bases de données est aujourd’hui dominé par des outils souvent perçus comme lourds, complexes ou vieillissants.
Beaucoup ont été conçus à une époque où les usages, les contraintes de sécurité et les attentes en matière d’expérience développeur étaient très différentes.

QoreDB est né d’une vision claire : concevoir un client de base de données desktop, local-first, rapide et agréable à utiliser au quotidien, capable de réconcilier les mondes SQL et NoSQL au sein d’une interface unique et cohérente.

Cette vision se reflète directement dans son architecture.

Un socle technologique moderne et performant

Pour garantir les performances et la sécurité d’une application native tout en conservant la flexibilité d’une interface moderne, QoreDB repose sur un stack hybride volontairement exigeant.

Le cœur applicatif est construit autour de Tauri 2.0 avec un backend en Rust.
Ce choix permet de bénéficier :

• de performances élevées
• d’une gestion de la mémoire sûre
• d’un contrôle fin sur les ressources locales

L’interface utilisateur est développée en React 19.1 avec TypeScript 5.8, afin d’offrir une expérience fluide, réactive et fortement typée.
Cette combinaison permet de maintenir une interface moderne sans compromettre la stabilité de l’application.

La communication entre les différentes couches repose sur des mécanismes asynchrones, avec l’utilisation de Tokio côté Rust. Cela garantit une excellente réactivité, même lors de l’exécution de requêtes complexes ou de connexions distantes.

Les piliers de l’architecture

L’architecture de QoreDB n’est pas le résultat d’un empilement de technologies.
Elle repose sur des principes stricts, définis dès le départ pour assurer la cohérence et la pérennité du projet.

Local-first et offline-capable

QoreDB est une application installée localement, qui fonctionne sans dépendance obligatoire à un service SaaS ou à une infrastructure cloud.
Les données, connexions et configurations restent sous le contrôle du développeur.

Modularité et extensibilité

Le cœur de l’application est volontairement maintenu léger.
L’architecture est pensée pour accueillir, à terme, de nouveaux drivers, fonctionnalités ou extensions sous forme de modules ou de plugins, sans surcharger l’ensemble du système.

Déterminisme et testabilité

Chaque choix architectural vise à favoriser des comportements prévisibles.
Cela facilite la compréhension du système, la gestion des erreurs et la mise en place de tests automatisés, indispensables pour un outil destiné à un usage quotidien.

Une expérience unifiée pour SQL et NoSQL

L’un des défis majeurs de QoreDB est de proposer une expérience cohérente entre des technologies fondamentalement différentes, comme PostgreSQL, MySQL ou MongoDB.

Plutôt que de masquer ces différences derrière des abstractions excessives, l’architecture de QoreDB cherche à :

• unifier les interactions
• conserver les spécificités essentielles de chaque moteur
• offrir des fonctionnalités transversales communes

Parmi les éléments clés de cette approche :

• Un gestionnaire de connexions sécurisé
  Les identifiants sont stockés via les trousseaux de clés natifs du système d’exploitation, afin de respecter les standards de sécurité de chaque plateforme.
• Le support du tunneling SSH
  Pour sécuriser l’accès aux bases de données distantes, sans complexifier inutilement la configuration.
• Une interface multi-onglets
  Permettant de travailler simultanément sur plusieurs requêtes, tables ou bases de données, tout en conservant une vision claire de l’état courant.

Cette approche permet de travailler efficacement avec plusieurs paradigmes de données sans changer constamment d’outil ou de logique mentale.

Conclusion

L’architecture de QoreDB privilégie la clarté et la maîtrise plutôt que le sur-engineering ou les dépendances SaaS superflues.

L’objectif est simple : construire un outil qui travaille avec le développeur, et non contre lui.
QoreDB est une plateforme de données pensée par un développeur, pour les développeurs, avec une architecture conçue pour évoluer sans perdre sa cohérence.

Les prochains articles aborderont plus en détail :

• la sécurité et la gestion des données locales
• les choix techniques derrière l’unification SQL / NoSQL
• les compromis assumés dans certaines parties du système