Endless replication when using reverse-proxy. about pouch-mirror

[colinskow]

CouchDB is designed to be exposed to end users. If you setup the security features correctly you have nothing to worry about. To access CouchDB with a browser, you will need to enable CORS.

I'm not sure if you have deeper reasons for using a reverse proxy, but it seems to me like a waste of server resources.

Definitely something about your implementation is screwing up the replication algorithm. The simplest solution is to not use a proxy.

[colinskow]

Join slack.pouchdb.com to communicate with myself and a lot of helpful people with CouchDB experience.

[SukantGujar]

Thanks Colin. One primary reason for using proxy is to prevent the CORS exchanges, which are slow and repetitive. And to allow gzip compression. Then there's the need to have as less ports exposed as possible and also less important needs like to be able to have the backend replacable in future. But frankly, I am hesitant to expose CouchDB unless I truly understand the security undertakings.

[SukantGujar]

After closer inspection, I found that the proxy code was not sending over the query string parameters to PouchDB. The following change fixed the issue -
req.pipe(request({ qs:req.query, uri: db_url })).pipe(res);

[colinskow]

The reverse proxy won't actually provide any additional security. Any attack that could be leveled against Couch will pass straight through the proxy unless you heavily filter the requests. It is much easier to study up on CouchDB security and do it right than to filter proxy requests.

The proxy will likely add lag to your requests, so you need to measure this against the benefits of GZIP. Not to mention as your app scales you will save a lot of money by not needing to scale the proxy servers.

[SukantGujar]

Your points are very valid Colin. I think the right thing for me to do is to take metrics with both approaches. Thanks to Superlogin's publicURL concept, its a one line change for me to switch from public facing CouchDB to a proxied one.
Another aspect here is that my application is not as chatty with the server. In fact around 80% of the time the interactions would be client side only. So the local PouchDB instance would be busy and occasionally the app would sync with the server.