couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ermouth <ermo...@gmail.com>
Subject [PROPOSAL] Allow rewrites to be JS function
Date Sun, 27 Sep 2015 22:11:07 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message