It's got: offline first, latency compensation, pubsub, partial sync, authorization rules and serverside timestamps, and global transactions, and 5 9s availability backed by spanner for umpteen languages. https://tomlarkworthy.endpointservices.net/blogs/firestores-...
Web Applications from the Future: A Database in the Browser
41–50 of 75 posts
Re: Web Applications from the Future: A Database in the Browser
#42No sure on the scalability of SQLite but here’s a simple way to get database undo/redo.
Re: Web Applications from the Future: A Database in the Browser
#43Having been a dev on EtherPad, Google Wave, Coda, and other real-time collaborative apps with OT, undo, and so on... I think it's correct that, ideally, there would be a framework that handles real-time collaboration, undo/redo, and offline support for you, and then you build your app with these problems already solved. I will probably create such a framework eventually. I don't see it as a database engineering probl…
There are a few of those frameworks. The first one that comes to mind is YJS here is a getting started[1]. 1. https://www.tag1consulting.com/blog/deep-dive-real-time-coll...
Re: Web Applications from the Future: A Database in the Browser
#44There is a moment when you step back and realize that all the data-wrangling code we write in apps is essentially what an SQL query planner does. And our frontend is just one big materialized view that we need to update.
I often think that if we had a database that runs in the browser, and we could subscribe to queries, and missing local data would be fetched on-demand, frontend development would be a lot easier. Its of course much more complicated than that.
I think the reality though is that backend scaling requirements always end up dwarfing frontend productivity concerns. And there is also a huge amount of glue between backend data sources, preventing the creation of a clean database on the backend to sync with, meaning we are creating API gateways and GraphQL federation layers, and all we can hope for is a good client-side caching layer.
If you look deeper though you will find many projects doing all these kinds of things already. Mobile developers are very familiar with offline techniques and SQLite on the client, and it doesn't feel like anything special to them. For the web/desktop, maybe no one has packaged it in the right way yet, or maybe we are still digesting GraphQL, SSR, and serverless, and then there will be another shift with offline-first, reactive SQL in the frontend.
It's funny though that if you think long enough about these concerns, you always seem to end up wanting some Datalog thing.
Re: Web Applications from the Future: A Database in the Browser
#45Re: Web Applications from the Future: A Database in the Browser
#46Having been a dev on EtherPad, Google Wave, Coda, and other real-time collaborative apps with OT, undo, and so on... I think it's correct that, ideally, there would be a framework that handles real-time collaboration, undo/redo, and offline support for you, and then you build your app with these problems already solved. I will probably create such a framework eventually. I don't see it as a database engineering probl…
I'm also looking at WebAssembly as the way of doing work ( http://www.adama-lang.org/blog/micro-monoliths ) versus generic operations.
Something interesting to consider is how important is offline use these days? If we get to an online-99.9% world, then the solution feels ... simple.
Re: Web Applications from the Future: A Database in the Browser
#47We had Meteor with “mini mongo” and you locally subscribed to streams and it was all a quite bloated PÓS IIRC. At some point someone will make a virtual browser that runs in the browser, or maybe a kubernetes that runs in the browser and the circle of ironic self referencing will be complete. Just replace the browser and use ports 80 and 443 and be done with it, instead of pretending that cpu cycles and RAM are free.…
> instead of pretending that cpu cycles and RAM are free. Don’t pretend security is free either.
I'm saying that we cannot presume the insecurity of a general purpose browser in a custom application that just happens to take advantage of open ports and an existing distribution network (upgrading/crossgrading connection or not...)
How uncommon is it to open a Zoom link from a browser source into the Zoom app, and countless other examples... not presuming any particular tech stack, which would imply it's own particular vulnerabilities or advantages...
Just curious...I think the "cram it all into a megabrowser from a megacorp and make it run" approach is rather 2021, is all, not necessarily the way of the still as yet undetermined future.
Re: Web Applications from the Future: A Database in the Browser
#48Re: Web Applications from the Future: A Database in the Browser
#49We had Meteor with “mini mongo” and you locally subscribed to streams and it was all a quite bloated PÓS IIRC. At some point someone will make a virtual browser that runs in the browser, or maybe a kubernetes that runs in the browser and the circle of ironic self referencing will be complete. Just replace the browser and use ports 80 and 443 and be done with it, instead of pretending that cpu cycles and RAM are free.…
> or maybe a kubernetes that runs in the browser and the circle of ironic self referencing will be complete https://blog.stackblitz.com/posts/introducing-webcontainers/
I'm going to go with a unikernal wrapping a process before this stuff makes it's way through my intestines, color me skeptical of the notion that slippy couplings in between multiple impedance mismatches will be excusable much longer in a world that increasingly cares about power consumption (and battery life) as well as carbon footprints...
Re: Web Applications from the Future: A Database in the Browser
#50Earlier quoted context omitted.
There are a few of those frameworks. The first one that comes to mind is YJS here is a getting started[1]. 1. https://www.tag1consulting.com/blog/deep-dive-real-time-coll...
Do you know if any of these frameworks support different users being permissioned to see different documents or different views of collections.