6 ms·

What features will this unlock for you?

• harryvederci 4y ago
  Serving my htmx app as a WASM app, so interaction by users will be done on their computer. Then only the DB changes will be have to be synced with the backend, saving a lot of traffic / server capacity. This was already possible, but then the user's changes would be lost if they don't sync in time. If I understand things correctly this is the missing piece: persistence. So if the user goes offline and makes changes, those will persist so they can be synced when the user goes online again. (All of this is as far as I understand things, I could be completely wrong.)
  • k__ 4y ago
    Isn't that model (without the wasm part) alread possible with pouchdb/couchdb?
    • harryvederci 4y ago
      I haven't looked into those, but I'm happily using SQLite already, and this would mean I won't have to swap it for something else to achieve the same thing.
  • ris58h 4y ago
    > If I understand things correctly this is the missing piece: persistence. So if the user goes offline and makes changes, those will persist so they can be synced when the user goes online again. 1. You can persist data with localStorage/IndexDB, can't you? 2. There is nothing in the article about syncing. There is no out-of-the-box solution, as I can see.
    • harryvederci 4y ago
      > You can persist data with localStorage/IndexDB, can't you? I guess so, but given the situation that I'd already be using WASM SQLite in the client's browser, then I'd have to implement that part myself, or use something like Absurd SQL. I'd rather use the implementation made by the creator of SQLite. > There is nothing in the article about syncing. Correct, that's something I'll have to do myself. I don't see any issues there though, I'd just need to verify the user is authorised to make those changes, which in my specific use case seems pretty trivial.
• wruza 4y ago
  Querying already cached data without reimplementing the query logic in javascript. How… I mean this is so obvious to have a RDBMS local to any non-basic app, why are you even asking? No offense, I just don’t understand how to create webapps and be not bothered by a lack of fundamental things. Some e-stores and sites literally reach server on each tick on a sidebar, when it could be a fragmentarily replicated local database with a background periodic or live sync. Imagine adjusting a filter and not waiting for reload and rescroll in a “web 2.0” app, when an entire dataset is comparable to a bundle.min.js and a roundtrip to it is 1000x+ slower than a query itself. E.g. a page where I buy t-shirts is barely a megabyte of json (sans images) for all items, but it spends probably half an hour in awaiting responses when I’m shopping around. An app like that shouldn’t even make requests, apart from downloading new jpegs and one narrow replication stream. Even for open-in-new-tab, because resources are cached and a dataset is in sync.
  • ris58h 4y ago
    Why do you need RDBMS for it? localStorage/IndexDB isn't enough?
    • mch82 4y ago
      Check out “SQLite as an application file format”, https://www.sqlite.org/appfileformat.html https://www.sqlite.org/appfileformat.html
      • ris58h 4y ago
        And how does it help in case of frontend development? A half of those points don't apply to web dev. Do you really need joins? Do you really need atomic transactions? Do you really need SQL? Most of API's that used by web apps operate with objects or arrays of objects. Why should we add complexity of SQL if we already can store those objects in a plain array?
        • wruza 4y ago
          This logic is flawed. X is not in Y, so we shouldn’t add it, because currently in Y no one is using neither X nor some crippled parody of it.