Posté par abriotde .
Évalué à 3.
Dernière modification le 14 octobre 2022 à 13:23.
En fait si j'ai bien compris le principe. Il a compilé SQLlite en WASM, et il tourne côté client. Et en gros le serveur (100% static, sans aucun traitement) sert de disque dur pour éviter de télécharger l'entièreté de la DB. Ce sont les appels de SQLlite au système de fichier qui sont fait via le réseau au serveur.
D'un point de vue économique et écologique, c'est top.
J'avoue que ça fait un moment que j'essaie de voir les cas d'usage que va permettre WASM et WASI. J'entends partout que c'est le futur mais je restais pour le moment assez peu convaincu, l'application QT qu'on va compiler pour tourner tel quelle en WASM dans un navigateur j'y crois pas trop coté expérience UX/UI.
Mais là pour le coup, la DB Sqlite en WASM via un site statique je l'avais pas vu venir. J'ai du mal à percevoir si en dehors de l'exploit technique ça donnera vraiment quelques choses mais ça force à réfléchir autrement. Qui sais, ça sera peut être réellement le futur WASM !
J'avoue que ça fait un moment que j'essaie de voir les cas d'usage que va permettre WASM et WASI.
Mon cas perso : ça me permet de ne pas avoir à demander à uploader le fichier entier (qui peut être de plusieurs Go) pour faire son analyse, je fais tout en local sans avoir besoin de faire installer un logiciel (les gens sont fainéants quand c'est pour tester).
Mais là pour le coup, la DB Sqlite en WASM via un site statique je l'avais pas vu venir.
Certes, maintenant je serai curieux de connaître le "coût" en latence et quantité de donnée transmise par rapport à une requête plus classique avec backend dynamique.
Qui sais, ça sera peut être réellement le futur WASM !
Ou pas :).
Perso je vois ça surtout comme un amusement technique de faire un peu joujou, de la à être très utile en prod… Peut-être pour squatter gratos du GitHub pages sans les limites de l'hébergement statique, certes.
Perso je vois ça surtout comme un amusement technique de faire un peu joujou
Perso je vois ça surtout comme une super idée économique.
D'un point de vue coût, c'est génial. Un site statique, ne coute rien à héberger contrairement à un site PHP/MySQL. Ainsi tu as moins besoin de pub ou dis autrement, ton site te rapporte plus d'argent.
D'un point de vue écologique c'est mieux car le surplus de CPU consommé par le client est négligeable compte tenu que de toutes manière son CPU tourne et consomme.
D'un point de vue client, le chargement est bien plus rapide. Du static répondra toujours plus rapidement qu'un traitement côté serveur. Donc évidemment qu'en latence tu y gagne. Sans compter que pour les prochaines requêtes, il ne fait même plus les appels en Ajax s'il reste sur la page de 1Ko ou qu'il navigue sur une précédemment chargé même si c'est sur des données différentes.
Le seul bémol est pour un client "terminal" avec un PC à la config trop légère. Mais du SQLLite, ça ne va pas chercher bien loin, peut-être la RAM?
D'un point de vue client, le chargement est bien plus rapide. Du static répondra toujours plus rapidement qu'un traitement côté serveur. Donc évidemment qu'en latence tu y gagne.
Je te défie de le prouver.
Car sur de la théorie c'est très loin d'être évident :
- gain temps de traitement distant, OK
- perte temps de transmission (plus de données)
- perte de temps de traitement local (plus petite machine client que serveur donc temps plus long, sans parler de faire tourner en JS plutôt que compilé natif)
- gain potentiel (aléatoire) sur 2ème requête si requête sur même bloc, certes, car plus de temps de transmission, mais même ça faut voir par rapport au temps JS
ne coute rien à héberger contrairement à un site PHP/MySQL […] Mais du SQLLite, ça ne va pas chercher bien loin
Tiens, les technos changent… tu peux avoir du SQLLite sur le serveur aussi.
D'un point de vue coût, c'est génial.
Pareil, faut démontrer le gain par rapport au développement, un serveur ça coûte rien par rapport à du développement.
D'un point de vue écologique c'est mieux car le surplus de CPU consommé par le client est négligeable compte tenu que de toutes manière son CPU tourne et consomme.
Sérieux, la faut arrêter l'écologie d'affichage, si négligeable en local JS c'est tout autant négligeable voir encore plus en centralisé optimisé. 1000x négligeable peut être supérieur à 1000x sur le même serveur donc optimisé pour coûter peu. Démontre que faire tourner 1000x sur JS avec les octets en plus transmis serait plus écolo que centralisé, la comme ça en première vue théorique c'est le contraire.
Avant de sortir des "idées super économiques et écologiques" contre-intuitives, faudrait avoir plus de concret.
En attendant c'est juste un jeu, au mieux squatter sur le dos de l’hébergeur statique gratos, de la bande passante gratos, et du CPU utilisateur gratos, et du développeur gratos aussi sans doute pour que ce soit rentable.
Posté par barmic 🦦 .
Évalué à 3.
Dernière modification le 19 octobre 2022 à 16:00.
D'un point de vue client, le chargement est bien plus rapide. Du static répondra toujours plus rapidement qu'un traitement côté serveur. Donc évidemment qu'en latence tu y gagne. Sans compter que pour les prochaines requêtes, il ne fait même plus les appels en Ajax s'il reste sur la page de 1Ko ou qu'il navigue sur une précédemment chargé même si c'est sur des données différentes.
Si j'ai bien compris c'est l'inverse il utilise intensivement xhr. Il utilise sqlite comme un client et les données sont récupérées via des requêtes range.
I implemented a virtual file system that fetches chunks of the database with HTTP Range requests when SQLite tries to read from the filesystem.
# Base de données "en lecture seule"
Posté par dovik (site web personnel) . Évalué à 3.
Vraiment cool.
Un détail important : la base de données est "en lecture seule".
# Quelle bonne idée
Posté par abriotde . Évalué à 3. Dernière modification le 14 octobre 2022 à 13:23.
En fait si j'ai bien compris le principe. Il a compilé SQLlite en WASM, et il tourne côté client. Et en gros le serveur (100% static, sans aucun traitement) sert de disque dur pour éviter de télécharger l'entièreté de la DB. Ce sont les appels de SQLlite au système de fichier qui sont fait via le réseau au serveur.
D'un point de vue économique et écologique, c'est top.
[^] # Re: Quelle bonne idée
Posté par Tangi Colin . Évalué à 3.
J'avoue que ça fait un moment que j'essaie de voir les cas d'usage que va permettre WASM et WASI. J'entends partout que c'est le futur mais je restais pour le moment assez peu convaincu, l'application QT qu'on va compiler pour tourner tel quelle en WASM dans un navigateur j'y crois pas trop coté expérience UX/UI.
Mais là pour le coup, la DB Sqlite en WASM via un site statique je l'avais pas vu venir. J'ai du mal à percevoir si en dehors de l'exploit technique ça donnera vraiment quelques choses mais ça force à réfléchir autrement. Qui sais, ça sera peut être réellement le futur WASM !
[^] # Re: Quelle bonne idée
Posté par Zenitram (site web personnel) . Évalué à 2.
Mon cas perso : ça me permet de ne pas avoir à demander à uploader le fichier entier (qui peut être de plusieurs Go) pour faire son analyse, je fais tout en local sans avoir besoin de faire installer un logiciel (les gens sont fainéants quand c'est pour tester).
Certes, maintenant je serai curieux de connaître le "coût" en latence et quantité de donnée transmise par rapport à une requête plus classique avec backend dynamique.
Ou pas :).
Perso je vois ça surtout comme un amusement technique de faire un peu joujou, de la à être très utile en prod… Peut-être pour squatter gratos du GitHub pages sans les limites de l'hébergement statique, certes.
[^] # Re: Quelle bonne idée
Posté par abriotde . Évalué à -1.
Perso je vois ça surtout comme une super idée économique.
Le seul bémol est pour un client "terminal" avec un PC à la config trop légère. Mais du SQLLite, ça ne va pas chercher bien loin, peut-être la RAM?
[^] # Re: Quelle bonne idée
Posté par Zenitram (site web personnel) . Évalué à 1.
Je te défie de le prouver.
Car sur de la théorie c'est très loin d'être évident :
- gain temps de traitement distant, OK
- perte temps de transmission (plus de données)
- perte de temps de traitement local (plus petite machine client que serveur donc temps plus long, sans parler de faire tourner en JS plutôt que compilé natif)
- gain potentiel (aléatoire) sur 2ème requête si requête sur même bloc, certes, car plus de temps de transmission, mais même ça faut voir par rapport au temps JS
Tiens, les technos changent… tu peux avoir du SQLLite sur le serveur aussi.
Pareil, faut démontrer le gain par rapport au développement, un serveur ça coûte rien par rapport à du développement.
Sérieux, la faut arrêter l'écologie d'affichage, si négligeable en local JS c'est tout autant négligeable voir encore plus en centralisé optimisé. 1000x négligeable peut être supérieur à 1000x sur le même serveur donc optimisé pour coûter peu. Démontre que faire tourner 1000x sur JS avec les octets en plus transmis serait plus écolo que centralisé, la comme ça en première vue théorique c'est le contraire.
Avant de sortir des "idées super économiques et écologiques" contre-intuitives, faudrait avoir plus de concret.
En attendant c'est juste un jeu, au mieux squatter sur le dos de l’hébergeur statique gratos, de la bande passante gratos, et du CPU utilisateur gratos, et du développeur gratos aussi sans doute pour que ce soit rentable.
[^] # Re: Quelle bonne idée
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 19 octobre 2022 à 16:00.
Si j'ai bien compris c'est l'inverse il utilise intensivement xhr. Il utilise sqlite comme un client et les données sont récupérées via des requêtes range.
Et le code est sur github : sql.js-httpvfs
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.