couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johs Ensby <>
Subject Re: [PROPOSAL] Allow rewrites to be JS function
Date Mon, 19 Oct 2015 19:24:03 GMT
Hi Garren,
thanks for the "not standing in the way", I hope for more volunteers to iron out some of CouchDB's
old akward wrinkles.
I am all with you for simplification:) ermouth's rewrite function is a huge simplifier.

Where I disagree with you is where you say "probably a sign that this idea is not something
worth pursuing".
Whenever you discover that you have a differentiator, it's always a good idea to look closely
before discaring it and blend in with the rest.
It's all about attracting the next million web developers.


> On 19. okt. 2015, at 20.08, Garren Smith <> wrote:
> I’m really struggling with these proposals. I love the enthusiasm of everyone but I
keep thinking we should rather simplify CouchDB. 
> CouchDB is ultimately a database. One with excellent sync capabilities. And combining
that with libraries like PouchDB and Hoodie make it an amazing database to build applications
> Adding routers and reverse proxies just makes it feel like we trying to push CouchDB
into being more than it needs to be.
> For example building Couchapp like functionality in Node.js is so simple and way better.
Languages like Go also do that really well. Far superior than what we can do with a database.
> I would rather let the Node.js and Go web libraries serve content and let us focus on
building a clustered replicating database. We will draw more people to this community if we
can do that properly over creaky, slow and limited web serving mashed on top of a database.
> If I look at other popular databases, I don’t see any of them serving web content which
is probably a sign that this idea is not something worth pursuing. 
> However if there is a burning desire for this and developers raising their hands to code
this functionality, I would not stand in your way. It is great to see the varied use of CouchDB
out in the wild.
> Cheers
> Garren
>> On 19 Oct 2015, at 4:47 PM, Johs. E <> wrote:
>> Thanks Andy,
>> I will try and  get some use cases up on confluence.
>> As for whoever would pick up the work after ermouth,  I have of course one big thing
on the wish list that goes well with a new router solution..
>> reverse proxy
>> I remember asking about it when I first started to work w CouchDB and there were
some concerns regarding security.
>> Since then I think node.js has paved the way with content scraping and all sorts
of outgoing traffic.
>> Has anyone work on a reverse proxy solution for Couch?
>> johs
>>> On 18 Oct 2015, at 21:36, Andy Wenk <> wrote:
>>> Hey Johs,
>>> thanks a lot for this. I need some time to dig into it. We need a place to
>>> write the user stories / use case down. So I suggest we find good place at
>>> the cwiki. So I suggest to use
>>> .
>>> Do you have write access there? If not, please ping me.
>>> Great work!
>>> All the best
>>> Andy
>>> P.S.: Jan already mentioned the feature freeze. Please take it not as a
>>> demotivation but as the possibility to have a bit more time to work on it.
>>> On 17 October 2015 at 17:32, Johs Ensby <> wrote:
>>>> Andy,
>>>> I will make my first use case for function in _rewrite a high level one:
>>>> to create a standalone server that is an all-in-one DB server, application
>>>> server, api server and web server.
>>>> I have played with the build of CouchDB 2 with rewrite function
>>>> implemented that  ermouth put up on the irish AWS community AMI list and
>>>> the new use cases are endless.
>>>> First, I find that there are a few things that people fail to notice about
>>>> ddocs.
>>>> you need a tool to build a ddoc, editing JSON is not a viable option. The
>>>> Ddoc Lab of ermouth is in a class of its own. If you havent tried it yet,
>>>> do so from <>. Installing on your own
>>>> couch it is as easy as storing the application, all included as one
>>>> document in any database. Ddoc Lab is a component oriented IDE with syntax
>>>> checking, less preprosessor and other build tools that let you keep a well
>>>> organized ddoc as a source project (in one couchdb document) and you
>>>> publich a ddoc to any target db.
>>>> with this tool you can organize your js modules and templates etc and
>>>> basically...
>>>> set up the API of your application in a ddoc. You can switch between
>>>> databases and their ddoc functionality based on username, role or
>>>> geolocation and limit access to parts of the Couch API as needed
>>>> This is the method I would recommend to explore powerful simplicity with
>>>> function in rewrites
>>>> redirect port 80 directly to couch
>>>> set up 2 vhosts, one for public access pointing to youdb/_design/api and
>>>> one for sysadm pointing to /
>>>> for admin use Fauxton and Ddoc Lab on the sysadm vhost
>>>> you are set to develop great systems, no big tool stack to learn, just
>>>> bring in whatever js modules you like, the template engine you like, the
>>>> router you like, the HTML5 stuff you like..
>>>> .. or just write some very compact js code in one place where you ealier
>>>> had to mess around with a whole stack of tools and systems
>>>> below is the req object that the function takes
>>>> Johs
>>>> The rewrite function has this syntax
>>>> function(req) {
>>>>      .. your code that will
>>>>      return
>>>>              path
>>>>              // optional
>>>>              headers
>>>>              method // you can change this on the fly
>>>>              code
>>>>              body
>>>> }
>>>> the function receives this req object
>>>> method
>>>> path
>>>> raw_path
>>>> query
>>>> headers
>>>>      Accept
>>>>      Accept-Encoding
>>>>      Connection
>>>>      Host
>>>>      Upgrade-Insecure-Requests
>>>>      User-Agent
>>>>      x-couchdb-vhost-path
>>>> body
>>>> peer
>>>> cookie
>>>> userCtx
>>>> db
>>>> name
>>>> roles
>>>> secObj
>>>>> On 1. okt. 2015, at 13.40, Andy Wenk <> wrote:
>>>>> Johs,
>>>>> Yes for sure! That's always great. Maybe you can also write some user
>>>> stories (given when then) or scribble some graphics. Everything is useful
>>>> and will fasten the process ;-)
>>>>> Cheers
>>>>> Andy
>>>>> On 1 Oct 2015 12:38, "Johs Ensby" < <>>
>>>> wrote:
>>>>> Thanks for this Andy,
>>>>> I can contribute to the discussion of the feature seen from a user
>>>> perspective.
>>>>> Would it be appropriate to present some use cases?
>>>>> best
>>>>> Johs
>>>>>> On 1. okt. 2015, at 12.33, Andy Wenk < <mailto:
>>>>>> wrote:
>>>>>> Johs,
>>>>>> Let me please show the steps needed.
>>>>>> * discuss the feature very clearly on the dev@. Please make sure
>>>> core
>>>>>> developers as committers with commit bits are involved
>>>>>> * code the feature. Make sure to implement tests
>>>>>> * send a pull request and show it to dev@
>>>>>> * finally the community will accept or decline the feature (this
>>>>>> involve refactoring and changes)
>>>>>> As Alex said. The PMC or Jan do not decide about the feature.
>>>>>> All the best
>>>>>> Andy
>>>>>> On 1 Oct 2015 11:21, "Alexander Shorin" < <mailto:
>>>>>> wrote:
>>>>>>> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <
>>>>>> wrote:
>>>>>>>> will you welcome ermouths rewrite contribution?
>>>>>>> The decision is depends on the implementation. If it will be
good, why
>>>>>>> not? Finally, CouchDB is open source project: we cannot forbid
>>>>>>> right for contributions, we only welcome them.
>>>>>>>> Arguments against couchapps has to do with performance and
the folly
>>>> in
>>>>>>> competing with node.js.
>>>>>>> Performance question for the new _rewrite implementation is very
>>>>>>> depends on query server. Once it can process this kind of functions,
>>>>>>> you may use something better than JS to gain better performance.
>>>>>>> could be Erlang native query server, or luerl-based one, or else
>>>>>>> like.
>>>>>>> --
>>>>>>> ,,,^..^,,,
>>> -- 
>>> Andy Wenk
>>> Hamburg - Germany
>>> RockIt!
>>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588

View raw message