Arrêtez de construire des bases de données

La complexité de la gestion des données

• Les ingénieurs frontend finissent par se rendre compte de la nécessité de mettre en cache les données d’API.
• Au départ, tout commence par un simple stockage de données, mais à mesure que les demandes de fonctionnalités augmentent, on en vient à implémenter un cache de données, des index manuels, des mutations optimistes (optimistic mutations), une invalidation récursive du cache, etc.
• Ces fonctionnalités ressemblent au fonctionnement interne d’une base de données et, dans les applications frontend complexes, on finit par construire une base de données spécialisée pour le domaine.

Les bases du cache

• Tout commence par le stockage du résultat des requêtes API dans des variables locales.
• Dans les applications web utilisant des frameworks déclaratifs, les données sont stockées dans des variables afin d’éviter des requêtes API inutiles.
• L’étape suivante consiste à déplacer le cache vers une couche plus haute ou à l’externaliser en dehors de l’arbre de l’UI.

Accélérer grâce aux index

• En organisant les données d’une certaine manière, on peut réduire le travail de l’application et améliorer l’expérience utilisateur.
• On constate que l’optimisation des données côté frontend ressemble au fonctionnement interne d’un moteur de base de données.
• La structure des données est améliorée en stockant les données par ID et en créant des index permettant de retrouver rapidement des éléments par date.

Mutations optimistes

• Il s’agit de simuler localement l’effet d’une action donnée sans attendre la réponse du serveur.
• Cela donne l’impression que l’interface utilisateur réagit immédiatement, mais si le serveur renvoie un résultat différent, l’UI doit annuler les modifications.
• Les défis incluent la duplication de la logique entre client et serveur, la gestion d’erreurs asynchrones et l’ajustement des changements après redémarrage de l’application.

Invalidation récursive du cache

• Les données apparaissent à plusieurs endroits du cache, et il faut l’invalider correctement après une mise à jour afin qu’il reste cohérent avec le serveur.
• L’UI doit savoir quelles parties du cache sont concernées par chaque mutation, ce qui peut devenir fragile à grande échelle.
• Combinée aux mutations optimistes, cette situation rend encore plus difficile la duplication de la logique serveur côté client afin d’anticiper les changements du serveur.

En train de construire une base de données ?

• Dans les applications frontend suffisamment complexes, on finit par construire de nombreuses fonctionnalités de gestion des données, ce qui détourne du temps consacré à satisfaire les utilisateurs et à résoudre les problèmes métier.
• Une alternative est proposée : une stack de base de données optimisée pour le frontend.

Présentation de SQLSync

• SQLSync a été développé comme une stack de base de données optimisée pour le frontend, basée sur SQLite.
• SQLSync est conçu pour résoudre les problèmes de gestion des données et permettre aux développeurs de se concentrer sur les fonctionnalités propres à leur application.
• SQLSync fournit un cache durable, toutes les capacités de SQLite, des mutations optimistes, une invalidation intelligente du cache et des requêtes réactives.

L’avis de GN⁺

Le point le plus important de cet article est le phénomène par lequel, à mesure que la complexité des applications frontend augmente, les développeurs finissent par implémenter eux-mêmes des fonctionnalités similaires à celles d’une base de données. Ce travail consomme leur temps et les éloigne du développement de fonctionnalités qui apportent une vraie valeur aux utilisateurs. Des stacks de base de données optimisées pour le frontend, comme SQLSync, proposent une approche innovante pour résoudre ce problème. Cet article est intéressant parce qu’il met en lumière un problème fondamental des approches traditionnelles de gestion des données et explore une nouvelle solution permettant aux développeurs de travailler plus efficacement.

[GN⁺]

Avis Hacker News

• Compréhension d’un ami créateur de projet

  • SQLsync est un outil qui permet aux développeurs frontend d’interroger et de mettre à jour une base de données distante depuis le navigateur.
  • Il fonctionne en envoyant une base de données SQLite dans le navigateur en s’appuyant sur la puissance de WASM.
  • Il utilise un algorithme réactif pour la synchronisation entre plusieurs clients.
  • C’est une approche innovante pour résoudre le travail de synchronisation des données des développeurs.

• Expérience avec un logiciel de gestion de projet dans une ancienne entreprise

  • Les données étaient synchronisées avec un mécanisme de check-in/check-out, mais cela a fini par être considéré comme dépassé avec l’arrivée des applications à mises à jour en temps réel.
  • Après dix ans passés à construire des applications web SPA, ce type de mécanisme de synchronisation donne l’impression d’avoir eu de l’avance sur son temps.

• Les problèmes qui disparaissent quand on abandonne les SPA

  • Avec des solutions comme Hotwire ou htmx, les requêtes serveur sont simplifiées, et le problème de les rendre rapides est mieux compris.

• Avis du créateur de SQLSync

  • Il répond à de nombreuses questions et prévoit de vérifier régulièrement celles qu’il aurait manquées.
  • Il se dit heureux de voir la discussion autour du premier billet, centré sur les raisons qui l’ont poussé à créer SQLSync.
  • Il prévoit d’expliquer le fonctionnement de SQLSync dans le prochain billet.

• Ne pas donner aux utilisateurs un modèle mental différent de la réalité

  • La synchronisation de base de données peut être plus complexe que le modèle client-serveur.
  • Lorsqu’une UI rapide est nécessaire, il semble plus sûr d’utiliser des primitives CRDT.

• Le principe selon lequel ce qui est mesurable est géré, et le sophisme des coûts irrécupérables

  • La complexité de la base de données est le problème.
  • Le problème vient de la syntaxe de SQL, et si l’usage d’une base de données relationnelle de base était une expérience agréable, la tentation d’utiliser une DB au lieu de construire sa propre base de données serait plus forte.
  • Une bonne base de données utilise SQL, et pour être efficace, il faut utiliser le langage de la base de données.

• Le problème de la synchronisation d’état entre client et serveur

  • Revenir à un modèle PHP/SSR permet de contourner le problème au prix d’un sacrifice sur l’UX.
  • Les SPA sont bien, mais l’envoi de formulaires multipart fonctionne toujours.
  • Garder tout l’état sur le serveur et traiter le client comme un simple terminal améliore l’expérience développeur.

• Comparaison avec les bibliothèques ORM

  • Question sur la comparaison entre SQLsync et l’utilisation directe de TypeORM et SQL.js, pris en charge dans le navigateur.

• Différence entre les bases de données frontend et backend

  • Les bases de données frontend peuvent être différentes de celles du backend, et il faut peut-être mieux gérer l’état en temps réel côté client.
  • L’utilisation de react query et des WebSocket est envisagée pour traiter l’invalidation du cache.
  • L’idée de SQLsync mérite aussi d’être prise en considération.

• Tentative similaire avec SignalDB

  • SignalDB utilise la réactivité basée sur les signaux et une syntaxe de requête semblable à celle de mongodb, indépendante du framework.