couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)
Date Wed, 06 May 2015 12:23:26 GMT
On Wed, May 6, 2015 at 3:15 PM, Johs Ensby <> wrote:
>> On 06 May 2015, at 13:55, Giovanni Lenzi <> wrote:
>> They could also be:
>> - design doc app
>> - design app
>> - couchdb apps
>> - couchdb based apps
>> But they all seem very complicated to me. What do you think?
> I would prefer to think of the “app” as a combination of things that use ddoc to
link functionality to the data, or provide an API of the data for the "app".

I think we need to set the terminology right.

What is design document?
A special document which _id starts with _design/ prefix which
contains design functions.

What are design functions?
A programming code that stored in design document and executed on CouchDB side.

Which design functions are could be?
Show, list, update, validate_doc_update, map, reduce.

Can we name design document with only map/reduce functions as CouchApp?
No, because it's just a secondary index.

Can we name design document with all of design functions as CouchApp?
No, because it's still just a design document, not an application.

What is CouchApp?
At first, answer is it's name: it's application. Applications has an
UI. UI in context of CouchDB is provided by HTML. Deisgn documents may
provide HTML UI via design functions and via attachments.

So design document where show/list functions produces HTML output is a CouchApp?
No, it's just a design document where show/list functions formats
result as HTML.

Then, may be design document with HTML attachments is a CouchApp?
No, it's still just a design document with HTML attachments.

So what is CouchApp is?
Again, the answer is in the name. CouchApp. Couch, App. CouchDB
Application. With first word everything is clear I hope (:
Application is not only an UI, but also uniform and consistent logic
about solving some single and specific problem.

What's the difference between design document with views, shows, lists
functions, HTML attachments and CouchApp Blog?
The latter is used to implement blog application. The former is just
an abstract design document with no specific purpose.

So, if we draw Object Oriented model of CouchApps we'll see pretty
clear structure:

class JSON(object);

class Document(JSON):

class DesignDocument(Document):

class CouchApp(DesignDocument):

So, CouchApp is just a next step in line which is a JSON Document, but
which the main difference: it solves specific business problem and
provides an interface for users to interact with!

Can regular documents be CouchApps?
No, because they cannot carry any logic on board.

Can arbitrary design document be CouchApp?
Technically yes, but no since design documents has no specific purpose
from the start. CouchApps has that.

So here is everything is clear for me. You can name CouchApp whatever
you like: CouchDB hosted application, Design Document application,
Smiley Upplication, but you cannot change next things: it's a design
document, it serves for specific purpose which makes it an

Has it CommonJS modules or, not, contains it static Javascript files
or not, interacts it with the other design documents / couchapps or
not - all these are just an implementation details.


View raw message