• # Base de données "en lecture seule"

    Posté par  (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  (site web personnel, Mastodon) . É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.

    Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

    • [^] # Re: Quelle bonne idée

      Posté par  . É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  (site web personnel) . Évalué à 2.

        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.

        • [^] # Re: Quelle bonne idée

          Posté par  (site web personnel, Mastodon) . Évalué à -1.

          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?

          Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

          • [^] # Re: Quelle bonne idée

            Posté par  (site web personnel) . Évalué à 1.

            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.

          • [^] # Re: Quelle bonne idée

            Posté par  . É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.

            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.