couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: [PROPOSAL] Allow rewrites to be JS function
Date Mon, 28 Sep 2015 15:30:31 GMT
Hi, ermouth!

I think that's good idea at least from point of consistency: if we
have other function in Javascript or else language, why we can't have
the same for rewrites? This will remove any need to learn new special
DSL that rewrites uses now and be limited by it.

As about performance, it's expected to be poorer for JS, but seems
it's not much to worry about. I think it could be even better than 3X
by using some tricks.

Please, continue your work on this!


On Mon, Sep 28, 2015 at 1:11 AM, ermouth <> wrote:
> 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,
> 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

View raw message