L’avenir du SQL pour le web
(jlongster.com)- absurd-sql : une approche où les données sont lues et écrites progressivement dans IndexedDB avec SQL.js (SQLite)
→ « absurd » car c’est une manière absurde de stocker les données d’une base dans une autre base
→ IndexedDB est lent et assez limité, mais avec cette approche c’est plus de 10 fois plus rapide
- Hook de sql.js pour stocker les données dans IndexedDB
→ cela reste encore 50 à 100 fois plus lent que SQLite natif
→ ici, IndexedDB a été utilisé, mais la Storage Foundation API pourrait aussi convenir (tests prévus)
- Avantages / inconvénients
→ le seul véritable inconvénient est qu’il faut télécharger et utiliser le fichier WASM gzipé (SQL.js)
→ permet d’exploiter toutes les fonctionnalités de SQLite : transactions, système complet de requêtes, vues, CTE, triggers, Full-text Search, mise en cache, etc.
2 commentaires
J’ai repris tel quel le titre original de l’auteur, « A future for SQL on the web ».
sql.js-httpvfs - Héberger une base de données SQLite sur GitHub Pages https://fr.news.hada.io/topic?id=4226
Cet article semble susciter beaucoup d’inspiration.
C’est une solution de contournement, mais on assiste au retour de WebSQL, que le W3C avait abandonné en estimant que SQL n’était pas adapté au web. En réalité, ce sera sans doute bien plus pratique pour les développeurs.
Je pense que c’est d’autant plus vrai à cause de l’existence d’Electron.
J’ai aussi vu le retour de Notion expliquant qu’après avoir utilisé IndexedDB comme sur la version web, ils sont passés à SQLite sur la version Electron, et que cela a rendu les choses bien plus vivables.
https://www.notion.so/blog/faster-page-load-navigation
On a aussi l’impression que ce type d’expérience est ensuite réexporté vers le web.