Hi Sachin, I work on a teaching app called Quizster that handles some of the same concerns. Here is my 2 cents:
On Tue, Nov 28, 2017 at 6:37 AM Sachin Divekar <[email protected]> wrote: > Hi, > > I have been studying a possibility to use Couchdb for a realtime messaging > app. The architecture I am thinking about is as follows. The app will > access only the local offline database using Pouchdb which is in continuous > replication with a remote Couchdb cluster. On the server, it'd be one > database per user. The app, in addition to conversations also has other > active objects like tasks, notes etc. I just want to have a discussion with > some experienced Couchdb users if such architecture makes sense. > > My primary concerns are following. > > 1. I am thinking of keeping shared objects in every participant user's > database. e.g. a group chat will be present in each of the participant's > database or a task can have multiple users assigned to it. I am not sure > how to replicate the changes made by one user on a task in his database to > other participant's database. Perhaps using filtered replication but I am > not sure. > GC: I think you have a few options here: 1. You can use filtered replication to replicate the docs, where you'd probably need a replication for each pair of users who are sharing the docs to replicate to and from the respective user's DBs. 2. If you can identify a common group, e.g. in our app we have classes, and don't need this group to write to these common docs then you can use a database to replicate docs from a user DB to this "group" database. Users could then read from this group DB. Perhaps in your case you can think of a group like a Slack organization or channel. You can then use a role to restrict read access to this group DB. You'd still need a replication per user-group, but you'd probably need a lot less of them. 3. You could create a custom API, instead of writing data with PouchDB, (just use PouchDB for reading) that you call when the user sends a message that saves the message to all the needed databases. This has the distinct disadvantage that without some serious work on your side that you app wouldn't work offline. > > 2. Will the load of continuous replication of a few thousand databases be > handled smoothly? > GC: This is great question and this load is definitely an issue. The good news is that we just open sourced our solution for this: Spiegel <https://github.com/redgeoff/spiegel> > > 3. How to deploy filters, views etc on all the databases because > essentially they will be same for all the databases. > GC: We create migration scripts that use Slouch StreamIterators <https://github.com/redgeoff/slouch/wiki/Don%27t-just-relax.-Slouch%21#streamiterators> to iterate through all the target databases and create the filters and views. > > Looking for some advice. > > Thank you. > > Regards > Sachin >
