incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Building substantial "pure" 2 tier CouchApps - feasible?
Date Tue, 12 Jul 2011 08:31:23 GMT
I still think the couchapp framework miss some features.  And I will
try to summarize some points. Side notes for usual people fast to jump
on conclusions, this isn't the couchapp trial at all. I quite love the
couchapp framework like it is. But today afetr 3 years of existence or
so itt's a little time to think more about it. So couchapp framework
miss some features:


1. Even if restish, it's not restfull . Most of the couchapp these
days are using a url fragments for the routing witch breaks the
meaning of URIS. Also it's isn't yet possible to fallback to the
google solution to make these uri searchable [1]. The rewriter helps
but isn't complete and once again isn't restful:

I can do :

GET /db/_design/dname/_show/fun
GET /db/_design/dname/_list/fun
(POST|PUT) /db/_design/dname/_update/fun


but I can't simply do (GET|PUT|POST|DELET|...) of )
/db/_design/dname/_app/somehandler

Of course I can play with the rewriter:

[
{
"from": "somehandler/*",
"to": "_show/showfun"
"method": "GET"
},
{
"from": "somehandler/*",
"to": "_update/updatefun"
"method": "PUT"
},
{
"from": "somehandler/*",
"to": "_update/updatefun"
"method": "POST"
}
]

but this isn't obviously the simplest solution.

2. The rewriter limits

While really powerful, the rewriter need some enhancements to fit all
needs. That something I investigate and I actually works on different
ways to achieve that.

3. Multiple calls on a page

Actually done by ajax, web workers, iframes (put your method) .
Something should be done to allows that.  The obvious way to achieve
it  would be to all funs to access to the couchdb api. Could be cool,
I'm also working on it (hence couchc [2]) and definitly useful to
extend couchdb api without having to rely on couchdb core. This
something appearing in redis with LUA that I find really useful. It
could aslo possible eventually to add a REST api to allows merging or
other fancy things you would like. Something fluidinfo [3] provides in
its service.

3) sessions

There is no secure way to maintain user infos across functions today.

4) Sandboxing

There are discussions today to allows write only db and such things.
Something that could be done on app level. What about sandboxing
couchapps like android apps are ?


5) About externals (os daemons)

That something really cool, but not really portable. Say I replicate a
couchapp that use these externals. Now my problem will have to install
this external. I've no clear idea to sove that point, maybe exposing
some systems calls like nodejs do ?


- benoit


[1] http://code.google.com/web/ajaxcrawling/docs/specification.html
[2] https://github.com/benoitc/couchc
[3] http://fluidinfo.com/

On Tue, Jul 12, 2011 at 10:00 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:
> On Tue, Jul 12, 2011 at 4:06 AM, Jason Smith <jhs@iriscouch.com> wrote:
>> tl;dr summary: It is practical using external processes to check in
>> and keep things sane. This is very future-proof, but with a slightly
>> longer time-to-market.
>>
>> On Tue, Jul 12, 2011 at 6:18 AM, Andrew Stuart (SuperCoders)
>> <andrew.stuart@supercoders.com.au> wrote:
>>> I'd like to build a rather substantial application, it would be nice to
>>> build it as a pure 2 tier CouchApp.
>>
>> Many have tried.
>>
>> It is completely impractical to build a pure 2-tier Couch app.
>> However, two tiers, plus external helpers ("2.1 tier") is very
>> practical.
>>
>> We've got some difficult days ahead. But it doesn't really matter with
>> me now. Because I've been to the mountaintop. I don't mind. Like
>> anybody, I would like to build a full-featured Couch app; scalability
>> has its place. But I'm not concerned about that now. I just want to do
>> God's will. And He's allowed me to go up to the mountain. And I've
>> looked over. And I've seen the Promised Land. I may not get there with
>> you. But I want you to know tonight, that we, as a people, will get to
>> the Promised Land. So I'm happy, tonight. I'm not worried about
>> anything. I'm not fearing any <span>.
>>
>> What I prefer is this: Your programmers develop on and deploy to the
>> Couch. Your users also interact directly with the Couch. However,
>> *external agents* also access the couch and perform administrative
>> tasks as needed.
>>
>> The benefits of two-tier apps are obvious; I will list a few:
>>
>> * Simpler
>> * Reduced sysadmin workload
>> * Excellent future-proofing: multi-datacenter, offline operation, run
>> from an iPhone, etc.
>>
>> Unfortunately, real-world apps are more than a pretty web page. To name a few:
>>
>> * Send emails or other messages (e.g. push notifications)
>> * Help users recover their password
>> * Interface with related services: boot EC2 instances, update a DNS
>> entry, generate an certificate
>> * Notice that somebody is spamming and do the needful
>> * Ops stuff: run backups, rotate logs, monitor services. Maybe that's
>> an external responsibility; but IMO nowadays that is an application's
>> self-hygeine
>> * Catch unexpected errors, reassure the user, alert the staff
>>
>> There is no alternative. You need a third component--admin stuff--to
>> build a comprehensive service.
>
> ANother path would be providing a way to code these features inside
> couch by providing needed API and the way to script it. Exactly like
> it was possible in good old hypercard time.
>
> - benoƮt
>

Mime
View raw message