There is also a variation on 3. (the custom API) where you do use PouchDB. You could have users write messages to their database and then use Spiegel with an on_change rule <https://github.com/redgeoff/spiegel/blob/master/DESIGN.md#on_change> that responds to new/edited messages and then copies those messages to the target database(s).
On Tue, Nov 28, 2017 at 7:00 AM Geoffrey Cox <[email protected]> wrote: > 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 >> >
