couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Wenk <andyw...@apache.org>
Subject Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)
Date Tue, 05 May 2015 16:37:42 GMT
As often, here are many truths in all the replies. I see myself just
jumping in from the side because I don't actually use CouchApps. I have
full respect for people like Giovanni  who want to keep CouchApps 'alive'.
So I think the plan Jan wrote done can work quite good also for me. Here
are my comments:

On 5 May 2015 at 17:39, Jan Lehnardt <jan@apache.org> wrote:

> Thanks for bringing up naming and design docs!
>
> There are a few angles here, that make it harder for me to think about
> this. I’ll try to spell it all out.
>
> Design Docs: The learning curve of design docs is really, really steep and
> the usability is so bad, that we need third-party tools to work around this.
>
> When we met in Boston a couple of years ago, we agreed that we should be
> addressing this. Mango is the first concrete step into a future where
> CouchDB indexing is more of an API and less of a “compile JS into JSON into
> a doc with a weird name”. I believe that this is the way forward.
>
> I think everything that is in a ddoc could equally be hidden behind an API
> like mango does. Under the hood, it’s still design docs, but the interface
> would be A LOT more friendly.
>
> With 2.0 and Mango I’d hope that 90% of our users don’t have to touch
> ddocs anymore for basic CouchDB querying. I’d love to extend this to
> document update validations and filters as well.
>
> (See, now this turns into a future-of-couchdb discussion, sorry about
> that).
>
> With nice APIs for all core features, there’d be less need for a tool that
> manages design docs.
>
> What CouchApps can *do* today, would, however, still be possible.
>
> Which brings me to naming.
>
> CouchApp is:
> - a python tool
> - a nodejs tool
> - is implemented in the erlang tool erica
> - is a concept of how to put a *very specific type of app* into CouchDB
> - a domain couchapp.com/.org
> - a way to manage design documents (which have their own problems, see
> above)
> - the second thing people get to hear, when they ask about how do I query
> CouchDB?
> - a lose collection of features inside CouchDB that all have problems:
>  - rewrite: not flexible enough, web devs expect more options for routing
>  - show/list/update/filter/validate: terrible performance characteristics
>  - map/reduce views: complicated (yet powerful), mediocre performance
> characteristics
> - an url slug in our documentation:
> http://docs.couchdb.org/en/1.6.1/couchapp/
>  - this creates an unfortunate hierarchy, yes, all the things in this
> section are parts of the CouchApp idea, but e.g. doc update validations are
> a valid concept even if you need nothing else from the CouchApp idea.
>
> This is very very very very confusing and we need to clean it up.
>
> * * *
>
> I very much sympathise with ermouth’s story-of-couchapp email. I’ve been
> through similar steps and everyone I know who has taken CouchApps to an
> extreme (Caolan McMahon of Kanso, Dale Harvey of PouchDB, Gregor Martynus
> of Hoodie, just to name a select few) all have similar stories. CouchApps
> appear genius at first, until you try to build a wide range of things with
> them.
>
> At this point, I’m no longer interested what neat things can be done with
> CouchDB, but I want to make sure we polish the core features as much as we
> can so they are easy to understand and use and don’t bring surprises
> operationally.
>
> I don’t mean to kill the concept of CouchApps, but the situation today is
> very damaging to our user-adoption rate. I’m more than happy to keep the
> functionality around, because I see there is merit in having it. But *most*
> CouchDB users I see, shouldn’t not be confused with whatever “CouchApp”
> means when they just want a database that replicates, when they want to put
> their data where they need it.
>
> So yeah, sorry, I don’t think this should be a recruiting vehicle for
> CouchDB.
>
>
> Here is a scenario that I can see working:
>
> 1. establish the idea of applications-in-couchdb as a standalone project
> (can be part of ASF CouchDB) with a name that doesn’t have “couch” in it.
>

yes - but I don't understand why we can't keep the name CouchApp. We have
that name and we have a domain for it. As I said before, we have to clarify
extremely well what the project folks think about CouchApps. I could
imagine to let Giovanni work on that page with our support.


> 2. provide APIs for all design-doc-features, so we don’t need extra
> tooling with CouchDB (maybe a little bit like couchdb-cli that rkowalski is
> toying with, but we’d ship that with CouchDB)
>

yes


> 3. Turn all 1.x-level CouchApp features (shows, lists, updates, vhosts,
> rewrites) into a plugin (can be installed by default, and maybe later not).
> The plugin then can evolve independently from CouchDB and implement e.g.
> more efficient list functions.
>

yes


> 4. publicly celebrate the retirement of all things “CouchApp” with
> pointers on couchapp.org/.com to where the things “CouchApps” were used
> for are available now, without confusion.
>
> The story then is:
>  - In 1.x some parts of the CouchDB API were too complicated, we had to
> have a tool for it.
>  - The tool also allowed to build standalone web applications that solely
> live in CouchDB.
>  - All this is now available elsewhere under these new names: X, Y, Z.
>  - R.I.P. CouchApps.
>

I still don't understand why we have to bury CouchApp, but maybe I am
missing some key thoughts here. Imho we could also tell:

- In 1.x some parts of the CouchDB API were too complicated, we had to have
a tool for it.

- The tool also allowed to build standalone web applications that solely
live in CouchDB called a CouchApp.

- We realised that this approach was resulting in some problems and decided
to move them out of CouchDB.

- All this is now available as (e.g.) Plugins at couchapp.org and is called
CouchApp 2.0

- We had a good idea, learned and decided that it is better to give
CouchApps it's own environment

TL;DR; we learned form the first attempt and the result is a own place for
CouchApps. We have the name, we have the domain and what we need is
clarification (sorry for repeating myself).

Thoughts?

Cheers

Andy






>
>
> * * *
>
> We have talked about focussing the CouchDB message and we agreed that
> replication and its ecosystem are the prime story to tell. I believe
> CouchApps are a huge distraction from that story and we should own to
> retire it.
>
> * * *
>
> So far my thoughts. I realise people have invested a lot in CouchApps (I
> know I have for 5+ years), but we have to be looking out for CouchDB and
> see where we run into diminishing returns. It took me more than half a
> decade to learn that CouchApps harm CouchDB more than they help. We as the
> project shouldn’t focus on what is technically neat/cool, but how we can
> get more people to use our project because it fits their needs and is
> easily accessible. We have many other fronts to fight to get this right,
> but with CouchApps, we have a foot firmly on a break when it comes to
> making CouchDB more accessible.
>
> * * *
>
> I know this is a lot to take in. Take your time. You might want to refrain
> from knee-jerk-replies of the “but but but CouchApps are cool…” type. I
> understand. I think they are cool too.
>
> Best
> Jan
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
> > On 05 May 2015, at 16:52, Johs Ensby <johs@b2w.com> wrote:
> >
> > Cudos to Giovanni for CouchApp enthusiasm
> > and to Ermouth for harsh critisim
> > to Jan and Andy for addressing the “story” level
> >
> > In spite of its many shortcomings, I still believe couchApps could be
> the big recruiter for CouchDB.
> > The fact that you can make a design document, direct a vhost to its
> _rewrite and there create your api for accessing multiple databases with
> various access levels and multiple design documents is awesome.
> >
> > The main storytelling problem is the overselling as Ermouth points out.
> > The overselling starts with the name itself, it should not have “app” in
> it.
> >
> > The concept of a CouchDB app is wrong.
> > The “app” that a million young developers are waiting to create lives in
> the client.
> > They need to learn some CSS and a Javascript framework, and CouchDB is
> the only backend they will need until they find out that they need more in
> addition to CouchDB.
> >
> > We should quit telling the story about CouchApps and start telling the
> story of design docs.
> > CouchDB design documents are great.
> > At least as long as we keep it simple.
> >
> > Our quest should be for powerful simplicity.
> > Simplicity always win.
> >
> > Johs
> >
> >
> >
> >> On 05 May 2015, at 11:49, Jan Lehnardt <jan@apache.org> wrote:
> >>
> >>>
> >>> On 05 May 2015, at 11:08, Andy Wenk <andywenk@apache.org> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Jan thanks for raising this important topic!
> >>>
> >>> As I had been around and participated when JChris, Jan and others
> started
> >>> CouchApps and Benoit took over the work, I am a bit sad, that CouchApps
> >>> started to confuse people. And yes it is true, they are limited but
> have
> >>> their place in the history of CouchDB. Far more, it can easily be seen
> as
> >>> the evolutionary basis for Hoodie and that is a good thing imho.
> >>>
> >>> We should give CouchApps a place to live in the CouchDB ecosystem (not
> >>> meant technically). So my proposal is to reactivate couchapp.org and
> write
> >>> one page with info about
> >>>
> >>> * what CouchApps are
> >>> * how one can create one (links to doku)
> >>> * what alternatives there are (kanso, hoodie ...)
> >>>
> >>> Furthermore we should include a link on couchdb.org to couchapp.org.
> >>>
> >>> I think it would be wrong to leave people still in the dark even though
> >>> nowadays we think, CouchApps is not the way one should create a WebApp
> >>> based on CouchDB (and I don't think the approaches to create CouchApps
> was
> >>> foolish Jan ;-)). It is our responsibility to clarify what CouchApps
> are
> >>> and why one should move forward to sth. better. With clarification
> comes
> >>> clarity
> >>
> >> Thanks Andy! — I’m all for the things you mention, once we figure out
> how
> >> the CouchApps story fits into the larger CouchDB story without confusing
> >> anyone.
> >>
> >> What’s your take on that? :)
> >>
> >> * * *
> >>
> >> Also, I think we shouldn’t be afraid to make CouchApp’s place in
> CouchDB’s
> >> history clear in terms of “This was an idea of its time. Today, we think
> >> differently. RIP CouchApps”.
> >>
> >>
> >> Best
> >> Jan
> >> --
> >>
> >>>
> >>> All the best
> >>>
> >>> Andy
> >>>
> >>>
> >>> On 5 May 2015 at 10:54, Jan Lehnardt <jan@apache.org> wrote:
> >>>
> >>>> It seems we have a separate discussion going on here, so I forked the
> >>>> thread.
> >>>>
> >>>> I’ve seen these two sides ever since we invented CouchApps:
> >>>>
> >>>> Pro:
> >>>> - CouchApps are amazingly simple
> >>>> - CouchDB as an app server is a great idea, I don’t need to run any
> other
> >>>> infrastructure
> >>>> - this is the future of web development
> >>>> - couchapp* is a great tool to manage design docs
> >>>>
> >>>> (*or erica… etc.)
> >>>>
> >>>> Con:
> >>>> - the concept of compiling design docs is confusing
> >>>> - even when they get it, they are confused that they need a third
> party
> >>>> tool called `couchapp` to do so, because the documentation talks about
> >>>> building full apps in CouchDB, they have an external app and just
> want to
> >>>> use CouchDB as a database, but couchapp is still the tool they need.
> >>>> - the tooling is poor
> >>>> - the tooling is all third-party
> >>>> - they can only cover a very limited use-case
> >>>> - CouchApps are the only way to use CouchDB
> >>>>
> >>>>
> >>>> I see a number of people being passionate about CouchApps and I
> believe
> >>>> their enthusiasm is warranted, CouchApps are a neat idea.
> >>>>
> >>>> But I also see a greater number of people being confused by CouchApps
> and
> >>>> in turn by CouchDB.
> >>>>
> >>>> That is not a good situation.
> >>>>
> >>>> Let’s think about how (and if) we can fit the CouchApp story into
a
> >>>> coherent CouchDB story.
> >>>>
> >>>> A prerequisite for that is having a coherent CouchDB story, which we
> don’t
> >>>> have fully finalised yet, but we have talked about extensively, and
> the
> >>>> consensus is around the “Data where you need it” narrative that
> emphasises
> >>>> replication between CouchDB instances and other projects that speak
> the
> >>>> replication protocol (especially PouchDB and TouchDB).
> >>>>
> >>>> How do CouchApps fit into that narrative?
> >>>>
> >>>>
> >>>> * * *
> >>>>
> >>>> (Personal view alert: this is just to give some more background on my
> own
> >>>> position, this isn’t meant as a basis for discussion)
> >>>>
> >>>> I’m personally conflicted. When we set out to develop CouchApps, we
> >>>> thought we are inventing a new paradigm for how to build the web, and
> >>>> everybody would follow us, because that would enable a true p2p web.
> That
> >>>> didn’t happen and probably was a little foolish of us :D
> >>>>
> >>>> Technically, that would have meant CouchApps had to grow a lot more
> and I
> >>>> realised quickly that CouchDB is not the right place to grow such a
> thing.
> >>>> In addition, there are various fully fledged web frameworks already
> and
> >>>> CouchApps could never really compete in terms of person-power and
> attention.
> >>>>
> >>>> That all led me to re-evaluate the whole value proposition, when
> things
> >>>> like PouchDB came up and the browser became a decent application
> >>>> development platform. That whole thinking led to the creation of
> Hoodie (
> >>>> http://hood.ie), which started out with the code name CANG (Couch
> Apps
> >>>> Next Generation), where we liked some of the core ideas of CouchApps,
> but
> >>>> wanted to address the limitations that would stifle their adoption.
> Hoodie
> >>>> embraces browser-to-server sync to allow fully offline apps, it allows
> >>>> all-javascript-all-json development on the front- and back-end. It
> uses the
> >>>> database-per-user and the _changes-feed-as-async-worker paradigms and
> it is
> >>>> all wrapped into a package that is *really* easy to understand and get
> >>>> started with. Hoodie, unlike CouchApps, does have a fighting chance
of
> >>>> making CouchDB’s unique features (replication, _changes) available
> for a
> >>>> larger population and I’m infinitely excited about that.
> >>>>
> >>>> * * *
> >>>>
> >>>> All that doesn’t mean, however, that CouchApps don’t have their
> place, but
> >>>> again, I’m not sure where that place is and the place it currently
has
> >>>> seems to negatively affect CouchDB, so I’d like for this list to
> think and
> >>>> talk about all that for a bit.
> >>>>
> >>>> How can we make it that CouchApps strengthen CouchDB and not weaken
> it by
> >>>> adding confusion?
> >>>>
> >>>> How do CouchApps fit into the CouchDB story?
> >>>>
> >>>>
> >>>> Best
> >>>> Jan
> >>>> --
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> On 05 May 2015, at 08:45, ermouth <ermouth@gmail.com> wrote:
> >>>>>
> >>>>>> CouchDB-killing answers
> >>>>>
> >>>>> Well... When someone says couchapps is silver bullet – I say ‘No’
> and I
> >>>> can
> >>>>> prove it. Couchapps have a lot, A LOT of problems, and some of them
> can
> >>>> not
> >>>>> be solved inside CouchDB. For example, try to implement ACL for
> >>>> attachments
> >>>>> or try to scale couchapp. You just can‘t do it in reasonable way.
> >>>>>
> >>>>> I know several engineers who tried out couchapps – and left CouchDB
> >>>>> forever. Not because CouchDB itself, but because couchapps. O‘Reilly
> said
> >>>>> it‘s a silver bullet, others said – and what we have? Sloppy
and
> >>>>> hard-to-debug architecture, that does not scale, has no tooling
and
> a lot
> >>>>> of security issues.
> >>>>>
> >>>>> You gonna solve architecture problems with positive posts?
> >>>>>
> >>>>> What I want to say – there is no need to lie and say couchapps
are
> great.
> >>>>> Because they are not.
> >>>>>
> >>>>>> would you like to write down some of your positive:-)) experiences?
> >>>>>
> >>>>> http://ermouth.livejournal.com/tag/couchdb – sorry, Russian
> language.
> >>>>>
> >>>>> ermouth
> >>>>
> >>>> --
> >>>> Professional Support for Apache CouchDB:
> >>>> http://www.neighbourhood.ie/couchdb-support/
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Andy Wenk
> >>> Hamburg - Germany
> >>> RockIt!
> >>>
> >>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
> >>>
> >>> https://people.apache.org/keys/committer/andywenk.asc
> >>
> >> --
> >> Professional Support for Apache CouchDB:
> >> http://www.neighbourhood.ie/couchdb-support/<
> http://www.neighbourhood.ie/couchdb-support/>
>
> --
> Professional Support for Apache CouchDB:
> http://www.neighbourhood.ie/couchdb-support/
>
>


-- 
Andy Wenk
Hamburg - Germany
RockIt!

GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588

 https://people.apache.org/keys/committer/andywenk.asc

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