couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giovanni Lenzi <g.le...@smileupps.com>
Subject Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)
Date Tue, 05 May 2015 11:17:09 GMT
> 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
- 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/
>
>

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