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 - 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 <[email protected]>: > > > On 05 May 2015, at 11:08, Andy Wenk <[email protected]> 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 <[email protected]> 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 <[email protected]> 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/ > >
