couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Cox <>
Subject Re: Architecture of a messaging app using Couchdb
Date Tue, 28 Nov 2017 15:23:57 GMT
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
<> 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 <> 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 <> 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
> <>
>> 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
> <>
> to iterate through all the target databases and create the filters and
> views.
>> Looking for some advice.
>> Thank you.
>> Regards
>> Sachin

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message