TLDR: Extend design doc `rewrites` section functionality, enabling it to be both list (array of rules, current format) and JS function (string). Function receives request, userCtx and security obj, returns rewritten path, and, optionally, method, headers and body.
Solves a lot of inherent couchapp problems: enables access control on early stage, query-based rewrites, userCtx-based rewites, timeframe-based policies and so on. Details --------- Was proposed several times. There exist 3 years old PR http://bit.ly/1KNPNLW, that was rejected because of ‘terrible performance’. I‘ve taken that PR, cleaned it up, modified for chttpd and fixed several most hitting performance issues. Right now performance isn‘t so terrible. If we denote list-based rewrite timing as X, JS-based rewrite takes approx 3*X + JS function run time (relatively modest, if fn is written carefully, generally much less then X). For comparison: validate_doc_update call takes approx 2*X, list call 3.5*X. So 3*X isn‘t so high, especially taking in consideration these facts: * We gain high flexibility and remove one of most serious bottlenecks of couchapps; * Right now requst validity check is often performed in couchapp‘s list function – approach of awful performance; we eliminate this approach totally (so here we have performance gain actually); * Since rewrites can be chained, we can make first rewrite hop using list syntax and use JS only on second hop, for subset of requests. And most important, in my universe. JS-based rewrite allows enforcement of filtering changes feed and, so, userCtx-based filtered replication. So we can have fair shared DBs – as opposite (or extension) to currently popular per-user DB approach. This is extremely important for CouchDB + (N * PouchDB) app architecture, that becomes more and more popular. -------- I‘m half way to PR, so question is: should it be merged if I do it? What do you think? ermouth
