ojanik

Error: 500 Message: { "status": 500, "message": "Internal Server Error" }

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.

Type inference FTW.

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?

  13 -> thirteen -> three ten
  14 -> fourteen -> four ten
  15 -> fifteen -> five ten

  11 -> eleven -> why not oneteen?
  12 -> twelve -> why not twoteen?

Looking at your code, you're also blocking Win+S on Windows and Ctrl+S on Mac for no good reason.

Extrapolating from your experience: What about shift key?

When you decide to block default behaviour, do your research, not everyone is on a Mac with American layout.