We've been running PouchDB in production for ~15 months now. We chose it because it was a greenfield project and it gave us 2 things: Easy offline support and real-time syncing that makes it easy to create collaboration a-la Google Docs. Because the entire thing is a web app with app cache manifest deploying new versions is very little hassle.
In terms of architecture we have about 250 tenants with separate Couch databases per each. We're still running Couch 1.6. We have yet to evaluate Couch 2.0.
It's been mostly smooth ride for the most part but this being a very unusual architecture we had to tackle few interesting problems that came along.
1. Load times. Once you get over certain db size the initial load time from clean slate takes ages due to PouchDB being super chatty. I'm talking about 15-30 mins to do initial sync of 20-30mb database. We had to resort to pouch-dump to produce dump files periodically. That helped a lot. I think this issue has been rectified with Couch 2.0 and sync protocol update.
2. Browser limits. Once we hit the inherent capacity of some browsers (namely Safari on iOS, 50mb) we had to get creative. Now we're running 2 CouchDB databases for each tenant where 1 has full data and the other only contains last 7-8 days. Pouch syncs to the latter one. We run filtered replications between the full db and the reduced db and do periodic purging. On the client side if a customer tries to go back more than 7 days we just use the Pouch in online only mode where it acts as a client library to remote couch and doesn't sync locally.
3. Dealing with conflicts. This might matter or it might not depending on the domain but you have to be aware of data conflicts. Because CouchDB/PouchDb is eventually consistent multi-master setup and you will get data conflicts where people update the same entity based on the same source revision. PouchDB has nice hooks to let you deal with this but you have to architect for it.
4. Custom back-end logic. Because Pouch talks directly to Couch you can't exactly execute custom back-end logic when needed. We had to introduce a REST back-channel to make sure our back-end runs extra logic when needed.
5. We had some nasty one-off surprises. Last one was with an object that had 1700 or so revisions in couch and once it synced to PouchDB it would crash the Chrome tab in a matter of seconds. Due to the way PouchDB stores revision tree (lot's of nested arrays) Chrome would choke during JSON.parse() call and eat up memory until crash. We resolved this one by reducing the revision history limit that is kept.
Coincidentally, I just installed GitLab to try it out for our small team to replace BitBucket + Jira. And while its more than capable filling Bitbucket shoes the issues subsystem is probably worse than github's and nowhere near flexible as jira.
Most notably: Missing more sophisticated workflows. Search for issues using multiple labels. Search for issues across multiple projects.
We would also love to be able to do simple time tracking against issues.
Is there no reasonably priced product out there that would fit our (rather simple) needs?
Ode to the javascript would be a better title. Yes, javascript is getting more popular but what would be interesting is to see how javascript growth compares with growth of it's derivatives or languages that compile to it. The sheer amount work done to avoid Javascript at its current state is mind-boggling.
Error: 500 Message: { "status": 500, "message": "Internal Server Error" }