[datadrivenangel]

The SQLite database is located on the application server, so there is no network between the DB and the app.

[shepherdjerred]

Assuming you're serving a frontend that makes network calls to a backend, you'll need to handle loading states in the frontend regardless of how the backend retrieves its data.

[tptacek]

The idea is that you're not doing that.

[danappelxx]

Unless your database is in the browser, you are always going to be at mercy of network latencies talking to the backend.

[tptacek]

You're just saying, even if all you were doing was fetching a static JSON blob from the memory of the frontend server, you'd still want load states, right? (That makes sense, I'm just checking my understanding.)

[danappelxx]

Yup, exactly. Phones change wifi networks, routers drop packets, load balancers get overloaded. Hard to fully eliminate tail latencies.

[simonw]

The key here is to make a single API call to the backend which then runs 100+ SQL queries at once and combines the results into a single JSON response - that way you're only paying the network cost once.

See https://www.sqlite.org/np1queryprob.html

I've implemented GraphQL on top of SQLite and found it to be an amazingly good match, because the biggest weakness of GraphQL is that it makes it easy to accidentally trigger 100s of queries in one request and with SQLite that really doesn't matter.

[az09mugen]

You can with sqlite in webassembly

[shepherdjerred]

In theory, but there are still a lot of sharp edges. e.g. I wanted to use sqlite in-browser with an ORM, but few ORMs support such a setup.

[meindnoch]

And your users are sitting in front the application server?