couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)
Date Wed, 06 May 2015 13:28:54 GMT

great discussion here, let’s keep it going!

I love the idea of getting a few more people into a joint session to discuss the future of
CouchApps, as Johs suggested.

The current thread is focussing on “how to fix CouchApps”, which we should continue to
figure out.

I’d also like push towards thinking about how the CouchApp (or whatever the final name might
be) story fits into the larger CouchDB story of “Data where you need it.” — Not necessarily
how the slogan made be “true” in the context of CouchApps (e.g. “Data (and logic) where
you need it.”, but more:

- CouchDB’s core feature is geographically distributed replication.

- Replication becomes really powerful with projects like PouchDB and TouchDB that take individual
user data offline on their browsers and phones.

- The industry’s current battle is vendor-lock-in with proprietary backend as a service
solutions that may or may not have offline capabilities.

- CouchDB is the only serious Open Source contender in this.

- We also have somewhat quirky, while technically neat, applications that can live inside

I don’t think that last bit helps paint the big picture CouchDB story at all. Granted, I’m
making a deliberately weak attempt of tying things together (because I don’t know any better),
but this is to get you thinking about how this could fit in our larger narrative, if at all.

My current thinking is that we can’t make it clear and thus should figure out a plan to
retire “CouchApp”, while still allowing all the cool tech, and find a new name for the
concept that can live on without making CouchDB’s core message unclear.

But I am very open to finding a way to make it fit. This is where you come in :)


> On 06 May 2015, at 14:23, Alexander Shorin <> wrote:
> 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);
>  pass
> class Document(JSON):
>  pass
> class DesignDocument(Document):
>  pass
> class CouchApp(DesignDocument):
>  pass
> 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
> application.
> 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.
> --
> ,,,^..^,,,

Professional Support for Apache CouchDB:

View raw message