colinskow / pouch-mirror Goto Github PK

Currently, the pouch-mirror API doesn't include destroy event. Can I take a PR to add one? The idea is to destroy localDB instance. This is useful in scenarios where multiple users share one browser environment and when a user logs-off, it is prudent to delete any local DB containing private information. As pouch-mirror abstracts the localDB instance, exposing a destroy method will make it easy to delete the localDB.

Pouch-mirror uses a remote-first strategy for any edit calls. This ensures that there's only a single source of truth in a multi-client-single-server scenario and also helps with conflict resolution.
But in cases where the client interactions are heavy, the server-first approach may lead to a slower turn-around, and may not work well in cases of flaky network connectivity.

Would you plan to revisit this project to bake-in a local-first strategy? If you are too busy now, I can fork this project and add one.

For a local-first approach, I think the following interactions should be acceptable -

1. On application setup, do a one-time two-way sync with Remote. During this time, redirect all read/writes to the server.
2. Once the sync is complete, switch to local DB. Now all r/w operations happen locally.
3. On every write (to local), schedule a (delayed, say 2-4 seconds) one-time 2-way sync with remote. On conflicts, raise events.
4. If another write occurs before the delayed sync happens, cancel the sync and reschedule it. This way if a lot of writes occur in succession, we don't end-up doing several sync's with the server. Basically we wait for things to cool down on the client before firing up the remote sync.
5. Before local destroy, offer a configurable replication to remote. This way scenarios like 'logout' which invoke destroy can rest in peace knowing the localDB will replicate to remote before being wiped.

Thoughts!?

Hi Colin,

This is totally a non-issue with library. I needed your help in debugging a problem I am facing and as I didn't have your email, I am reaching out to you here.

To prevent having to expose CouchDB endpoint to my application users, I tried to add a simple reverse-proxy using request in my express app -

```
// Bind /db to couch DB backend
var DATABASE_URL = 'http://localhost:5984';

// middleware itself, preceding any parsers
app.use(function(req, res, next){
    var proxy_path = req.path.match(/^\/db(.*)$/);
    if(proxy_path){
        var db_url = DATABASE_URL + proxy_path[1];
        console.log("db_url: " + db_url);
        req.pipe(request({
        uri: db_url,
        method: req.method
        })).pipe(res);
    } else {
        next();
    }
});

Also, I added dbServer > publicURL: 'http://localhost:8080/db/' in superlogin config, so that the private DB urls come mapped to the `/db` endpoint. Things went good this far. However, when I ran the application, the replication initiated by pouch-mirror went amok and never ended. The calls trough the proxy are going through, however somehow the replication is screwed up. The private DB size ballooned very quickly from mere 8.1k to 1MB in no time.

Do you have experience with a setup like this? Would be great if you can give me any pointers.

Thanks!

Hi Colin,

Aside from Superlogin, I am also trying to integrate pouch-mirror into my application to sync with a logged in user's remote private DB (CouchDB 1.6.1) with an IndexedDB based in-browser PouchDB instance.

My setup is something like this -
Front end - React, Reflux, superlogin-client and pouch-mirror.
Server - Express, Superlogin
DB - Couch 1.6.1 (brand new, Admin Party enabled).

Right now, when I am using pouch-mirror, its able to write docs to the user's remoteDB correctly, when the sync has not finished. However, the sync never finishes. The replication process keeps on throwing 'ETIMEDOUT' exception (caught in the error event handler in startLiveReplication). Due to this issue, the replication to local DB _never _ completes and the application keeps on using remoteDB only.
Using Fiddler, I saw that the request to the Remote URL look like this -

GET http://localhost:5984/<remoteDBname>/_changes?timeout=25000&style=all_docs&feed=longpoll&heartbeat=10000&since=3&limit=100 HTTP/1.1
Host: localhost:5984
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Accept: application/json
Origin: http://localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36
Authorization: Basic Wl9zQ0dKZFNSa2FmNm9wOUcxQ0xwZzp0MWlqbUJCQlNJbUMyMVpfV1U1bjln
Referer: http://localhost:8080/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8

Its on this request where pouch-mirror receives the time-out exception. I take it that this is supposed to be a long-polling request and wonder whether this exception is expected.

I looked into the code of startLiveReplication and saw that there's a bind to uptodate event which is supposed to handle sync completion as its this place where pouch-mirror switches remoteDB with localDB. However, this enevt never gets invoked. Also, I didn't notice this event in the PouchDB replication docs. There's a complete event listed but per the documentation, for a live replication, the complete event will never be invoked unless the sync is cancelled.

Thoughts!?

PS: My entire development stack is on a single machine.