couchdb-marketing mailing list archives

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

> On 05 May 2015, at 13:17, Giovanni Lenzi <g.lenzi@smileupps.com> wrote:
> 
>> How do you do per-doc or per-attachment ACL? Those are not core CouchDB
> features.
> 
> per-doc:
> - read : https://www.smileupps.com/couchapp-tutorial-chatty-read-api

That looks like you are using a changes filter. A client has to opt into that. what if a client
calls changes without the filter?

> - write: https://www.smileupps.com/couchapp-tutorial-chatty-write-api
> 
> per-attachments: a tutorial will come.. however
> - write: same method used in
> https://www.smileupps.com/couchapp-tutorial-chatty-write-api
> - reads: through unguessable ids, which is industry common practice
> 
> all of the above can be seriously enhanced with filtered changes and some
> minor improvements to rewriting engine module.
> 
> 
> 
> 2015-05-05 13:01 GMT+02:00 Jan Lehnardt <jan@apache.org>:
> 
>> 
>>> 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/
>> 
>> 

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


Mime
View raw message