Live data from Hacker News

Web Applications from the Future: A Database in the Browser

stopa.io

41–50 of 75 posts

Re: Web Applications from the Future: A Database in the Browser

#41
Just use Firebase (firestore) ...

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-...

Re: Web Applications from the Future: A Database in the Browser

#43

Having 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...

Do you know if any of these frameworks support different users being permissioned to see different documents or different views of collections.

Re: Web Applications from the Future: A Database in the Browser

#44
Great post. Captured the problem nicely. I went on a similar journey recently.

There 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

#45
You should also look to OpenDSU (opendsu.com) that covers in a unique ways these aspects. Basicaly it goes to build on the vision in wich applications are running inside digital wallets and you control your data (client side encryption) while beeing able to collaborate with others and get security in a decentraliassd way using various types of anchoring in ledgers (not necesarly distributed or your typical blockchains but of course this could be the case too)

Re: Web Applications from the Future: A Database in the Browser

#46

Having 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…

The common abstraction is a shared log. I'm boiling down my current side project ( http://www.adama-lang.org/ ) into reusable components.

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

#47

We 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.

is our non-browser (that happens to piggyback on 80 & 443) a single-purpose application? What are the presumed security vulnerabilities of a bespoke non-browser that happens to listen on 2 ports, and either negotiate a transfer from http(s) to our kustom-protocol or utilize existing protocols starting from http(s) (any version of your choice...)

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

#49
post #12

We 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/

Wow! it just goes to show... something or other... How many recursive levels of that do you reckon are required to grind your average dev portable workstation to a halt? (let's say 32gb ram, presuming no actual program load, just overhead plus 'hello world') I suppose the real question is: how many engineers will a major corp throw at aforementioned wall/problem in order to make us not care and follow unwise engineering paths?)

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

#50

Earlier 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.

Fluid Framework (a project I contribute to/work on through Microsoft) supports this via token in our default service implementation, but we don't have integration with an ACL DB.
Post reply on HN