couchdb-marketing mailing list archives

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

> On 05 May 2015, at 14:18, Giovanni Lenzi <g.lenzi@smileupps.com> wrote:
> 
>> 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?
> 
> Request is denied if the changes filter does not receive as query
> parameter(or in path) the same userid which is authenticated (can be done
> comparing req.userCtx.name or anything inside req.userCtx.roles)

That happens in a proxy outside of CouchDB then?

> 
> So:
> - changes for non authenticated users is denied
> - changes with incorrect user id are denied
> - to optimize performance, changes request with a since query parameter too
> old, are rejected... and list-view has to be used.
> 
> 
> 2015-05-05 13:42 GMT+02:00 Jan Lehnardt <jan@apache.org>:
> 
>> 
>>> 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/
>> 
>> 

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


Mime
View raw message