4 ms·

> I'm convinced WASM SQLite is the future of in-browser strorage for web apps/PWAs. In what use cases would it make sense to transfer the entire db file over

> I'm convinced WASM SQLite is the future of in-browser strorage for web apps/PWAs. In what use cases would it make sense to transfer the entire db file over the network, then pluck out the relevant rows into JSON, versus just doing that server side and transfer the JSON back? Is the trade off that the server does less computation, but then pay for network bandwidth fees?

edgyquant 4y ago
Not all applications need a centralized DB and even those that do likely have client only data.
sgbeal 4y ago
> In what use cases would it make sense to transfer the entire db file over the network, then pluck out the relevant rows into JSON, versus just doing that server side and transfer the JSON back? Lots of dbs are small - a few hundred kb, maybe a meg. Many sites, by comparison, serve _megabytes_ of CSS and/or JS (minified!). i just hit imdb dot com for example's sake: 7MB of Stuff to load the front page, with something like 1MB of it being JS code. In addition, this type of app permits the user to inject a copy of a client-local db with no network traffic. In developing fiddle we've seen it work with dbs of approximately 80mb (haven't tested anything larger), but those limits are going to be very browser-/environment-dependent. > Is the trade off that the server does less computation, but then pay for network bandwidth fees? That's one tradeoff. Another is less coding effort needed to implement the client/server halves of the interaction. In conventional apps, every client-side operation on data results in a call to a server-side counterpart of that client-side operation. That needn't be the case for this style of app. For some apps, all of the code can now be client-side. For some, data might be synced/pushed to the server after changes are made, but there need not be a continual back-and-forth between the client and server. Another point is data privacy: this sort of app need not send the db to anyone. The db can stay entirely on the client, so they can use private databases without any concern that the server might squirrel away a copy or leak a copy to other folks. That said: the wasm approach, with a client-embedded db, is most definitely not a one-size-fits-all solution. It will serve a certain niche of applications, but not the majority of web app data needs.
kristopolous 4y ago
Not the use-case. Here's a javascript database I made between 2011 and 2016 that is pretty web use-case specific. https://github.com/kristopolous/db.js https://github.com/kristopolous/db.js Scrolling through the documentation should make some use-cases more obvious. Restructuring, sorting, filtering and modifying data in a fast-enough way that doesn't require thinking hard about things is pretty invaluable. I was actually just using it earlier this month for the first time in a long while. I had forgotten how nice it was. Really made my job way easier but YMMV.

edgyquant 4y ago

Not all applications need a centralized DB and even those that do likely have client only data.

sgbeal 4y ago

> In what use cases would it make sense to transfer the entire db file over the network, then pluck out the relevant rows into JSON, versus just doing that server side and transfer the JSON back? Lots of dbs are small - a few hundred kb, maybe a meg. Many sites, by comparison, serve _megabytes_ of CSS and/or JS (minified!). i just hit imdb dot com for example's sake: 7MB of Stuff to load the front page, with something like 1MB of it being JS code. In addition, this type of app permits the user to inject a copy of a client-local db with no network traffic. In developing fiddle we've seen it work with dbs of approximately 80mb (haven't tested anything larger), but those limits are going to be very browser-/environment-dependent. > Is the trade off that the server does less computation, but then pay for network bandwidth fees? That's one tradeoff. Another is less coding effort needed to implement the client/server halves of the interaction. In conventional apps, every client-side operation on data results in a call to a server-side counterpart of that client-side operation. That needn't be the case for this style of app. For some apps, all of the code can now be client-side. For some, data might be synced/pushed to the server after changes are made, but there need not be a continual back-and-forth between the client and server. Another point is data privacy: this sort of app need not send the db to anyone. The db can stay entirely on the client, so they can use private databases without any concern that the server might squirrel away a copy or leak a copy to other folks. That said: the wasm approach, with a client-embedded db, is most definitely not a one-size-fits-all solution. It will serve a certain niche of applications, but not the majority of web app data needs.

kristopolous 4y ago

Not the use-case. Here's a javascript database I made between 2011 and 2016 that is pretty web use-case specific. https://github.com/kristopolous/db.js https://github.com/kristopolous/db.js Scrolling through the documentation should make some use-cases more obvious. Restructuring, sorting, filtering and modifying data in a fast-enough way that doesn't require thinking hard about things is pretty invaluable. I was actually just using it earlier this month for the first time in a long while. I had forgotten how nice it was. Really made my job way easier but YMMV.