couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)
Date Tue, 05 May 2015 11:01:32 GMT

> On 05 May 2015, at 12:54, Giovanni Lenzi <g.lenzi@smileupps.com> wrote:
> 
> I think it's a timing problem.. probably Couchapps were simply not mature
> enough some years ago.. but nowadays their potential has increased a lot,
> under every aspect.
> 
> IMHO they are even one of the best way to implement granular server-side
> security.
> 
> - security: server-side read and write ACLS are a reality(
> https://www.smileupps.com/couchapp-tutorial-chatty)
>   - filtered changes from RCouch will improve security even further
>   - probably, some minor tweaks to the rewriting engine module can easily
> add ACL at view level, so improving performance on #3
>   - ACL for _attachments is already possible. We have a tutorial scheduled
> on that

How do you do per-doc or per-attachment ACL? Those are not core CouchDB features.


> 
> - background events are a reality too and they enable Couchapps to perform
> any kind of background REST events:
>   - send email, SMS, payments, scheduled backups.. and so on.. just by
> interacting with the database
>   - all these jobs can eventually be packed into single-feature-ready
> couchapps: e.g. "do you need stripe payments on your website?".. just
> download the stripe couchapp!
>   - the daemon is opensource and implemented in node.js,
> https://www.smileupps.com/couch-daemon-triggerjob ... but it would be great
> ported to erlang
> 
> I agree with ermouth a lot can still be done around tooling, performance
> and scalability (do you think bigcouch can eventually help us on this
> too?), but I think leaving Couchapps could be really a great error.
> 
> 
> 2015-05-05 11:49 GMT+02:00 Jan Lehnardt <jan@apache.org>:
> 
>> 
>>> 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/
>> 
>> 

-- 
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/


Mime
View raw message