[xrd]

This is interesting to me.

One of the things that really turned me off from firebase is the rules system where you have to build an ACL there. It's been a few years since I've played heavily with it, but I really disliked trying to essentially build my authorization system into a backend which I couldn't run locally and was primarily edited in their web console.

For me, writing a proxy that sits in front of couchdb is very simple. I use JWT tokens that get passed between components in the system. I keep my authorization logic out of couch. I can write normal unit tests on my proxy. And my pouchdb client code mirrors the structure of my backend structure, which is a mental model I really prefer.

I guess I'm saying I think having a separate database for each user makes more sense to me, not less.

The only thing I'm struggling with is running code when a document is updated. I have a polling client that watches for the _global_changes updates, but it seems really hacky. I wish there was a better way to get access to all database changes that looked like firestore functions.

[kiwicopple]

This is almost exactly the architecture I’m thinking about for Supabase, except using our Real-time server instead of polling. If you’re open to it, I’d love to chat to you about how you’ve implemented this? My email is in my profile

[tehbeard]

_changes should be available in an event stream format for continuous consumption, and you can apply filter functions to the feed?

[xrd]

It is, but I am using the global changes feed (so I don't need to create a process for each database which doesn't scale for me). And you have to manually create that database to have it work. And I have to filter based on my own code, I just wish there was a way to subscribe to high level events. In general it works fine but I keep thinking there could be a better way.