[koolba]

When your data is public and immutable, this approach is very pleasant. The client becomes just another caching layer and worst case it's presenting a historical version of the truth. You can even extend this across tabs with things like local storage.

This breaks down quickly once you have data that could become private or mutate rather than append.

[tehbeard]

This what stopped me exploring couchdb further.

The "one db per user" model for private data made using other features like views etc more difficult when you have to upgrade,edit,remove them.

Mutability wasn't really a problem, either present the conflicts to user and pick one or write code to merge if possible.

[fermuch]

Couchbase (with its sync gateway) uses "channels" to sync data. It even lets you change the channel of a doc, and to the sync client it shows as if the doc was deleted (if the user is not part of the new channel)

[bayesian_horse]

Yeah, couchdb more or less requires you to replicate data for individual users if you need complex permissions and want the user to access the couchdb directly.

Permissions in general need to be handled by custom reconciliation functions (dropping unauthorized changes) or some kind of nanny system that can react to changes.

For example, imagine blog posts as documents, and a list of comments inside that document. Instead of the user adding/changing the comment list, the user would add a record to a comment request list, and either the reconciliation process or a nanny service checks the requests and updates the comment list.

The much simpler solution of course is to not let the users have any write access to the couchdb and just use a REST API. But then you loose much of the benefits of couchdb...

[rockwotj]

I think the Firebase Realtime Database and Firestore have a good model for offline and being able to have private and mutable data. It does get complex but the Firebase SDKs do the heavy lifting for you here.

[xrd]

Can you share more about the private and mutable data functionality for Firebase? I used them a few years back, and never really understood how to do private data without building my own ACL inside Firebase.

[rockwotj]

Here is a couple of specific examples: https://medium.com/firebase-developers/patterns-for-security... https://firebase.google.com/docs/firestore/solutions/role-ba...

You do need to have you ACL data also stored in the database, which can be a hassle if you have existing ACL system already built outside of Firebase.

xrd, do you have a specific question about private data in Firestore?

[xrd]

Thanks for the response. I suppose my biggest question is not how I can store private data (I can just make it inaccessible via the right rules). But, it seems like I am then layering my own ACL system onto those rules. And, I never got a sense there was an easy way to write a test that simulated my rules against my data and made sure I was not accidentally creating a leaky rule.

In so many ways it is SO much easier to use Firebase because all the pieces are right there as compared to a DB + Server + Front End + Tooling. But, I still always worried that I would somehow leave a gaping hole in my data and not know about it.

And, I was never really sure how I can easily do joins across data without writing my own bespoke metalanguage inside Firebase. A link posted today on HN talked about XML does turn out to be good for nested data (hence the reason it is used for UIs), and it feels like Firebase being more or less JSON loses in this respect.

That's just my experiences, and I say that loving Firebase.

Those two examples made me think: Firebase removes a lot of complexity for me, but it forces me to write my own layer of complex access and DB logic which I never felt fully qualified to do, and as such, just went back to using databases with an ORM and a backend server.

[megous]

In reality data can't become private again, after being available. You may try to contact all users to delete their copy, but they may not respect that.

[azernik]

That's in theory. In actual reality, if you're making an app that has private data and is not crawled by bots, most of the time users don't save everything that they see.

[kijin]

I think the parent means clients (user agents), not actual human users. As soon as any state that needs to be hidden is exposed to clients, that's a security breach regardless of whether any human eyeballs have seen it.

[megous]

This is true, too, but I meant users, too. It's all too common for users to screenshot things, etc. I see it a lot of the time on Twitter for example. You can delete tweets, but oftentimes it's pointless. But I also regularly see my gf taking photos with her phone of various apps she uses on her notebook, just to have the info around on her phone. I suspect it's pretty common, because it's much more low-tech then saving pages or API scraping.