couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johs Ensby <j...@b2w.com>
Subject Re: [PROPOSAL] Allow rewrites to be JS function
Date Thu, 01 Oct 2015 09:07:17 GMT
Hi Jan & PMC,
will you welcome ermouths rewrite contribution?

Arguments against couchapps has to do with performance and the folly in competing with node.js.
Of course it is too late to compete with the node.js ecosystem.
That battle was lost in 2010, when couchapps did not evolve beyond the experimental stage
where we still are https://www.google.com/trends/explore#q=couchdb%2C%20node.js&date=1%2F2008%2049m&cmpt=q&tz=Etc%2FGMT-2
<https://www.google.com/trends/explore#q=couchdb, node.js&date=1/2008 49m&cmpt=q&tz=Etc/GMT-2>

Node.js got another companion already
https://www.google.com/trends/explore#q=couchdb%2C%20mongodb%2C%20node.js&date=1%2F2011%2049m&cmpt=q&tz=Etc%2FGMT-2
<https://www.google.com/trends/explore#q=couchdb,%20mongodb,%20node.js&date=1/2011%2049m&cmpt=q&tz=Etc/GMT-2>

Now it's more about this development
https://www.google.com/trends/explore#q=couchdb%2C%20couchbase&date=1%2F2011%2060m&cmpt=q&tz=Etc%2FGMT-2
<https://www.google.com/trends/explore#q=couchdb, couchbase&date=1/2011 60m&cmpt=q&tz=Etc/GMT-2>

It is not too late to compete for the entry-level position to new developers in the cloud
era.
It is a battle for simplicity.
_rewrite for creating API servers
_list for presentation
- a design document will all you can store as JSON, available there in the memory of the server
as a single javascript object called "this"
- the rest is HTML5 mastered by millions of young developers

Johs



> On 29. sep. 2015, at 20.23, Robert Newson <rnewson@apache.org> wrote:
> 
> Performance is likely to be very poor but I'm not blocking it.
> 
> I do suggest we look at Lua though. There's a native Erlang lua interpreter written by
Robert Virding. Lua seems a popular choice in this space, haproxy 1.6 has lua hooks. 
> 
>> On 29 Sep 2015, at 06:06, ermouth <ermouth@gmail.com> wrote:
>> 
>> Jason,
>> 
>> thought about your message more systematically.
>> 
>> We have a distinct tradeoff (JS-provided flexibility vs performance), it
>> exists from the beginning of CouchDB. Now, with cluster, we have chance to
>> reduce JS-related impact.
>> 
>> For prev versions I can hardly imagine more than, say, 1K simultaneous
>> highly active users per single instance, when JS is actively used. JS just
>> stalls on validates, updates an so on. And if we dared to have lists
>> (especially in awful ACL workarounds), 1K turned to 100-300, even for thick
>> i7.
>> 
>> To increase number of users, to scale, I had to have smth in front of (N *
>> CouchDB). And that ‘smth’ is always quite complex. Moreover, it is always
>> task-specific, non-general.
>> 
>> With cluster, the problem goes solved in general, and no additional ‘smth’
>> in front of CouchDB needed. Got 1001-th user? Add one more node, that‘s
>> all. We already have this problem nearly solved, by cluster nature.
>> 
>> So why not to extend – dramatically – CouchDB playground? Shared DBs out of
>> the box is badly desired option, as I see.
>> 
>> And it‘s a very cheap way to make ALL couchappers happy for a long time )
>> 
>> BR
>> 
>> ermouth


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