Aimez-le ou détestez-le, les capacités de votre navigateur Web moderne augmentent continuellement de manière étrange et sauvage. La capacité des applications Web à fonctionner hors ligne nécessite une solution de stockage local persistante et pour beaucoup, IndexedDB est le seul choix car il fonctionne sur la plupart des navigateurs et fournit une interface de type base de données. Cependant, comme [James Long] trouvé, IndexedDB est douloureusement lent sur Chrome et limité dans la capacité de requête. Il a décidé d’apporter un outil qu’il connaissait bien, SQLite, et de l’intégrer au navigateur Web en tant qu’absurde-sql.

Pourquoi absurde ? En partie parce que la plupart des navigateurs (pas Chrome) implémentent IndexedDB au-dessus de SQLite. Ainsi, pour de nombreux navigateurs, il s’agit simplement de SQLite au-dessus d’IndexedDB au-dessus de SQLite. Heureusement pour [James] il existait déjà un projet connu sous le nom de sql.js qui utilise emscripten pour compiler le SQLite basé sur C dans WebAssembly. Cependant, sql.js utilise un support de stockage en mémoire et toutes les données sont perdues lors de l’actualisation de la page. [James] a peaufiné la méthode de lecture et d’écriture de blocs de SQLite. Au lieu d’être sauvegardé en mémoire, il a ajouté une couche pour lire et écrire des blocs à partir d’IndexedDB. Cela signifie que seules des sections de la base de données doivent être lues, ce qui entraîne d’énormes gains de performances.

un graphique montrant absurde-sql battant IndexDB sur chaque référenceCela nous amène à l’autre raison pour laquelle c’est absurde. Sur chrome (ainsi que Firefox), absurd-sql bat IndexedDB sur presque tous les benchmarks. Une requête comme SELECT SUM(*) FROM kv conduit à des résultats étonnants.

Alors, quel est l’inconvénient? À part un fichier WebAssembly assez volumineux qui doit être téléchargé (409 Ko) et mis en cache, il n’y en a vraiment pas. Bien sûr, tout n’est pas rose lorsqu’il s’agit de développement Web. Native SQLite s’exécute 2 à 3 fois plus vite qu’absurde-sql, ce qui montre à quel point IndexedDB est vraiment lent.

Il existe d’autres normes de stockage à l’horizon pour les navigateurs Web, mais le verrouillage devient un problème. SQLite attend des lectures et des écritures synchrones car il s’agit simplement de C. IndexedDB et d’autres solutions de stockage sont asynchrones car la boucle d’événements de Javascript se prête bien à ce modèle. Absurd-sql contourne cela en créant un SharedArrayBuffer qui est partagé avec un processus de travail. L’API atomique est utilisée pour communiquer avec le tampon. En particulier, atomics.wait() permet au travailleur de bloquer l’exécution du thread principal jusqu’à ce que la lecture ou l’écriture soit terminée. Du point de vue de SQLite, les opérations sont synchrones. IndexedDB fournit des transactions afin que plusieurs connexions puissent se produire (par exemple, plusieurs onglets ouverts). Plusieurs transactions en lecture seule peuvent se produire en parallèle, mais une seule transaction en lecture-écriture peut être en cours.

Pourquoi ne pas ouvrir votre navigateur et commencer à jouer avec ? Vous êtes déjà condamné à apprendre WebAssembly de toute façon.