11–20 of 165 posts
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 c…
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 c…
I can see that the organization running the application needs a global view of all data. But regional users perhaps don't. Often they just need to know their own data.
Write first to edge then copy to central database rather than write first to central database then trickle down to the site from where the write originated in. Just wondering what portion of applications could use this alternative design.
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 c…
I think you always need loading states to account for slow network, or am I missing something?
Earlier quoted context omitted.
I think you always need loading states to account for slow network, or am I missing something?
The SQLite database is located on the application server, so there is no network between the DB and the app.
Earlier quoted context omitted.
The SQLite database is located on the application server, so there is no network between the DB and the app.
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.
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 c…
How is it for writes? Would a CRM type system benefit from liteFS setup?
> 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-us...
Earlier quoted context omitted.
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.
The idea is that you're not doing that.
Earlier quoted context omitted.
The idea is that you're not doing that.
Unless your database is in the browser, you are always going to be at mercy of network latencies talking to the backend.
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 c…
How is it for writes? Would a CRM type system benefit from liteFS setup?