6 ms·
I think this skips one mega benefit for apps. I’ve been using liteFS in production for a couple months. Your web app is able to resolve db queries instantly.
by zackify 3y ago
I think this skips one mega benefit for apps.
I’ve been using liteFS in production for a couple months.
Your web app is able to resolve db queries instantly.
You don’t need loading states if you’re using complex charts and other frontend JS that waits for data.
All the data is resolved so fast and you can just return all your data like more traditional apps, and the load times are insane.
If you’re multi region you can deploy one app instance there. Instead of 2-3. Postgres read replica, maybe something like redis.
It really replaces both of those, assuming you have a read heavy app it works great.
- bgdkbtv 3y agoHow is it for writes? Would a CRM type system benefit from liteFS setup?
- thomasfromcdnjs 3y agoIn Fly's implementation; > LiteFS’ use of FUSE limits the write throughput to about 100 transactions per second so write-heavy applications may not be a good fit. https://fly.io/docs/litefs/faq/#what-are-the-tradeoffs-of-using-litefs https://fly.io/docs/litefs/faq/#what-are-the-tradeoffs-of-us...
- bgdkbtv 2y agoSeems that 100 writes per second is more than enough for a typical CRM (for a local business).
- linsomniac 3y agoThe article says "LiteFS supports roughly 100 writes per second".
- danappelxx 3y agoI think you always need loading states to account for slow network, or am I missing something?
- datadrivenangel 3y agoThe SQLite database is located on the application server, so there is no network between the DB and the app.
- shepherdjerred 3y agoAssuming 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 3y agoThe idea is that you're not doing that.
- danappelxx 3y agoUnless your database is in the browser, you are always going to be at mercy of network latencies talking to the backend.
- tptacek 3y agoYou'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 3y agoYup, exactly. Phones change wifi networks, routers drop packets, load balancers get overloaded. Hard to fully eliminate tail latencies.
- simonw 3y agoThe 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 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.
- boxed 3y agoYou can run postgres on the same host as the web server too. Isn't that going to get you most of that same benefit in speed?
- yurishimo 3y agoIt is. I do this on plenty of hobby Laravel apps.
- boxed 3y agoMe too, but I guess there could be even higher gains with SQLite when it's in-process...
- cztomsik 3y agothe cool thing with sqlite is that you can compile your whole app into a single binary, so you don't need docker for example (or it's trivial to dockerize it afterwards if you really insist)
- giovannibonetti 3y agoPostgres is great, but managing a fleet of them (one in each web server) and ensuring they are all working fine would bring a lot of operational complexity. SQLite, on the other hand, skips all of that with its simple in-process model.
- boxed 2y agoI just start postgres and it's solid. I don't understand this statement. With Dokku it's trivial.
- kevinak 2y agoIt’s better than running it on a separate server but if you’re using Postgres you’re always hitting the network stack on the machine, with SQLite that isn’t the case.