Re: Couchapp experience in 2016
Jan, The playful exploration of the single-tier functionality has followed CouchDB from the very start. It is one of the unique features, and even if you regard it as a side effect it has always held a great potential for creating interest and try-out activity for the project. Hence, it definately belong in the weekly news. It goes without saying that this is IMO and all of that. I just dont to include the H because I dissaprove strongly of your respons to the massive work that ermouth has done to explore the limits of the so-called "coachapps": To send signals of dissaprovment without giving a single reason is lazy and disrespectful, especially in this case given the quality and thoroughness of ermouth's work. To discourage couchapp contributions from the weekly news is extreme. It is unworthy of an OS project. johs On 2. sep. 2016, at 08.27, Jan Lehnardt wrote: Project wise, we probably shouldn’t get people too excited about CouchApps at this point. > On 2. sep. 2016, at 09.10, Jan Lehnardt wrote: > > >> On 02 Sep 2016, at 09:08, Alexander Shorin wrote: >> >> On Fri, Sep 2, 2016 at 9:53 AM, Jan Lehnardt wrote: On 02 Sep 2016, at 08:45, Alexander Shorin wrote: Still, it's about CouchDB use case with pro/cons described (; >>> >>> sure, I just wouldn’t put it in the weekly news ;) >> >> Why not? It's good, real experience that shows that better pick >> node.js to get better performance rather than stay and dance around >> couchapps which is fun. We don't have quite a lot of posts like that >> kind. >> > > I’m not inclined to explain my position on CouchApps yet again. > > I’m not the editor in chief for the weekly news, but if asked, I would not > include this item for reasons that are reasonably well documented in the > mailing list archives (so not very). > > Best > Jan > -- >
Re: Couchapp experience in 2016
Thank you, Giovanni! > For me, choosing a 1-tier architecture Actually, we still need kinda reverse proxy in front, mostly to have gzipped answers (and, optionally, prepend Cache-control headers). Without js rewrites I had to use Apache or node to avoid web server recompilation on rules change. Now I can use nginx since rule list is stable and I need to compile nginx only once don‘t bothering about internal routing rules. > by choosing extreme ease of > development(in-browser development, same javascript language for frontend > and backend) I still don‘t think couchapps are easy in common sense, mostly because technologies are limiting and concepts are off mainstream. However, I admit now that couchapp concept is less limiting than I thought a year ago ) ermouth 2016-09-05 11:28 GMT+03:00 Giovanni Lenzi : > Great job ermouth, you are always on the front line on pushing couchapp > borders! > > JS rewrites seems to really enable them to any kind of use. Performance may > be a limit if you are really interested to squeeze each available cpu > cycle, ok but, from a business perspective, how does it cost to reach > and mantain this speed? May be an interesting question for your article > too. > > For me, choosing a 1-tier architecture(couchdb with js rewrites and default > vhost) over the usual 3-tier(web-app-db) is mostly a matter of costs. > Choosing couchdb means keeping costs low by choosing extreme ease of > development(in-browser development, same javascript language for frontend > and backend) ease of maintenance and reduced set of skills(one server only > to learn, configure and mantain with no licenses). > > Would I mind spending some more bucks on hardware (which keeps constantly > improving and getting cheaper) to reach the same performance level of a > more complicated and thus expensive architecture? Of course not. > > Thanks for your work, > --Giovanni > > 2016-09-02 0:00 GMT+02:00 ermouth : > > > Tried out more or less pure couchapp approach in 2016 realities, I mean > JS > > rewrites and PouchDB. > > > > Written down a story about the project, from the couchapp side: > > http://lesorub.pro/how-it-works > > > > It was interesting experience, couchapps still might be useful, in very > > rare cases ) > > > > ermouth > > >
Re: Couchapp experience in 2016
Great job ermouth, you are always on the front line on pushing couchapp borders! JS rewrites seems to really enable them to any kind of use. Performance may be a limit if you are really interested to squeeze each available cpu cycle, ok but, from a business perspective, how does it cost to reach and mantain this speed? May be an interesting question for your article too. For me, choosing a 1-tier architecture(couchdb with js rewrites and default vhost) over the usual 3-tier(web-app-db) is mostly a matter of costs. Choosing couchdb means keeping costs low by choosing extreme ease of development(in-browser development, same javascript language for frontend and backend) ease of maintenance and reduced set of skills(one server only to learn, configure and mantain with no licenses). Would I mind spending some more bucks on hardware (which keeps constantly improving and getting cheaper) to reach the same performance level of a more complicated and thus expensive architecture? Of course not. Thanks for your work, --Giovanni 2016-09-02 0:00 GMT+02:00 ermouth : > Tried out more or less pure couchapp approach in 2016 realities, I mean JS > rewrites and PouchDB. > > Written down a story about the project, from the couchapp side: > http://lesorub.pro/how-it-works > > It was interesting experience, couchapps still might be useful, in very > rare cases ) > > ermouth >
Re: Couchapp experience in 2016
> using more CouchDB design documents simultanously is not fast enogh? It‘s not. There are 2 basic considerations: a) node is faster as a compiler and generates code, that runs faster, b) we can avoid excessive serialize/parse calls between OTP and SM, which are both CPU and IO hungry for large branchy docs. Although we add several more layers here, and they add latency, which diminish our performance boost. So I‘m not sure if 5x rps and bandwidth per core achievable, gonna play with it a little. ermouth
Re: Couchapp experience in 2016
> So if we could have a performance booster, say 5x, I‘d use > couchapps not only for small things or interims. Do you mean your workaround on JavaScript single-threading like it is usally the case in any other environment, even in angular2 or react, by using more CouchDB design documents simultanously is not fast enogh? On Sat, Sep 3, 2016 at 12:24 AM, ermouth wrote: > > from someone reaching the end of couchapp > > possibilities by developing a software stack which does'nt need local > > installation > > Thanks. Reaching the end means going back with new experience. > > Ddoc Lab is able to generate attaches with npm package tarballs, and npm > allows direct install from CouchDB. I mean deploying from Couch to FS, not > vice versa as we usually do. That is my "going back" from Couch to FS-based > solutions: FS apps still follow data. > > Now I‘m thinking about composing kinda node.js module, able to augment > query server in part of show, list, update and, possibly, reduce. > > There exist nice set of modules like pouchdb/pouchdb-list. I gonna try to > combine couple of them, and, intercepting appropriate requests by node.js, > exec lists and similar queries inside node.js. Just for an experiment, to > see what it gives. > > Actually (couchapp + JSrewrite + PouchDB) architecture is pretty nice and > even attractive in terms of stability and, well, purity – but lacks > performance. So if we could have a performance booster, say 5x, I‘d use > couchapps not only for small things or interims. > > ermouth > -- -- Dipl.-Inf. Harald R. Kisch Falkenstraße 19C 81541 München Germany Mobil DE: +49 (0) 176 56 58 58 38 Skype: harald.kisch Mail: haraldki...@gmail.com
Re: Couchapp experience in 2016
> from someone reaching the end of couchapp > possibilities by developing a software stack which does'nt need local > installation Thanks. Reaching the end means going back with new experience. Ddoc Lab is able to generate attaches with npm package tarballs, and npm allows direct install from CouchDB. I mean deploying from Couch to FS, not vice versa as we usually do. That is my "going back" from Couch to FS-based solutions: FS apps still follow data. Now I‘m thinking about composing kinda node.js module, able to augment query server in part of show, list, update and, possibly, reduce. There exist nice set of modules like pouchdb/pouchdb-list. I gonna try to combine couple of them, and, intercepting appropriate requests by node.js, exec lists and similar queries inside node.js. Just for an experiment, to see what it gives. Actually (couchapp + JSrewrite + PouchDB) architecture is pretty nice and even attractive in terms of stability and, well, purity – but lacks performance. So if we could have a performance booster, say 5x, I‘d use couchapps not only for small things or interims. ermouth
Re: Couchapp experience in 2016
> couchapp is a web app hosted > inside CouchDB and using CouchDB features to run I like that definition coming from someone reaching the end of couchapp possibilities by developing a software stack which does'nt need local installation of any development tools ;) On Fri, Sep 2, 2016 at 9:35 PM, ermouth wrote: > Hi, Robin! > > > I'm very interested in couchapps > > although the definition isn't too > > clear for me > > Nobody knows exact definition. > > The variety of solutions entitling itself ‘couchapp’ it quite wide. They > use different client-side frameworks and architectures, since CouchDB does > not dictate. However they all are served from CouchDB and often use CouchDB > queries to fetch/store data. > > So if we take the term in fuzzy meaning, couchapp is a web app hosted > inside CouchDB and using CouchDB features to run. > > ermouth > -- -- Dipl.-Inf. Harald R. Kisch Falkenstraße 19C 81541 München Germany Mobil DE: +49 (0) 176 56 58 58 38 Skype: harald.kisch Mail: haraldki...@gmail.com
Re: Couchapp experience in 2016
Hi, Robin! > I'm very interested in couchapps > although the definition isn't too > clear for me Nobody knows exact definition. The variety of solutions entitling itself ‘couchapp’ it quite wide. They use different client-side frameworks and architectures, since CouchDB does not dictate. However they all are served from CouchDB and often use CouchDB queries to fetch/store data. So if we take the term in fuzzy meaning, couchapp is a web app hosted inside CouchDB and using CouchDB features to run. ermouth
Re: Couchapp experience in 2016
On Fri, Sep 2, 2016 at 1:35 PM, Harald Kisch wrote: > I appreciate your interest in couchapps. Oh, I've even written a few, even have my own short-lived tool to handle design docs https://github.com/millette/divanator My question about terminology had more to do with this: > 2. A library for single page application (SPA) > Angular or React or whatever you want Here's another "couchapp" I did 3 years ago, but it's straight html (show/list functions) served from couchdb with almost no client-side js. http://www.francais101.com/ > 3. A REST API library for communication with Couchdb > I would recommend using the jquery lib ( > http://bradley-holt.com/2011/07/couchdb-jquery-plugin-reference/) That's what I meant by AJAX. Is it necessary to call something a couchapp? > If you want to be supersexy with offline mobile responsitivity, you can > also use pouchdb (https://pouchdb.com/) My own website is served by couchdb too (sort of a wiki) and I can edit anything offline (and attach images, whatever) thanks to PouchDB. So here, I have one DB with 2 design docs (and serving 2 subdomains) one for visitors, one for admin. The admin side use the app cache, page.js, pouchdb and other niceties. > In my opinion there is no more easy way to build fast, high available > JavaScript applications for massive loads. Eventually, I'm going to have to get to the bottom of this, but I heard couchapp (but like I said, I'm not sure what that entails _exactly_) might not have a future after CouchDB 2. Something to do with show function performance. Thanks for sharing your tips :-) -- Robin http://robin.millette.info/
Re: Couchapp experience in 2016
Hi Robin, I appreciate your interest in couchapps. You can use any HTML file to serve your app directly from couchdb. Usually you need: 1. A design document create it yourself (id:"_design/name") or use couchapp ( http://couchapp.readthedocs.io/en/latest/) 2. A library for single page application (SPA) Angular or React or whatever you want 3. A REST API library for communication with Couchdb I would recommend using the jquery lib ( http://bradley-holt.com/2011/07/couchdb-jquery-plugin-reference/) It's some years old but still valid ( https://onabai.wordpress.com/tag/jquery-couch-js/) If you want to be supersexy with offline mobile responsitivity, you can also use pouchdb (https://pouchdb.com/) With all this in place you are extremely flexible. You can choose your editor, your operating system, your dev environment and also your backend provider (http://www.couchappy.com or http://www.appback.com) You can simply concentrate on the frontend-development side. Having all data in sync (build in continious replication) on many CouchDB instances you can simply balance your load by putting a proxy in front of your instance farm or if you need data sharding across CouchDB instances automatically simply use CouchDB 2.0. In my opinion there is no more easy way to build fast, high available JavaScript applications for massive loads. Have fun. Harry On Fri, Sep 2, 2016 at 4:46 PM, Robin Millette wrote: > Hello, > > I'm very interested in couchapps although the definition isn't too > clear for me. I usually try to output html pages, with some > client-side JS enhancements. Not sure if couchapp implies AJAX. > Anyhow. > > On Fri, Sep 2, 2016 at 10:20 AM, Peter Figliozzi > wrote: > > > In summary, the Couchapp architecture makes > > it easier to get started programming web applications, without having to > > learn some middleman API. > > I often present CouchDB as a web server that happens to take care of > the database as well :-) > > -- > Robin > -- -- Dipl.-Inf. Harald R. Kisch Falkenstraße 19C 81541 München Germany Mobil DE: +49 (0) 176 56 58 58 38 Skype: harald.kisch Mail: haraldki...@gmail.com
Re: Couchapp experience in 2016
Hello, I'm very interested in couchapps although the definition isn't too clear for me. I usually try to output html pages, with some client-side JS enhancements. Not sure if couchapp implies AJAX. Anyhow. On Fri, Sep 2, 2016 at 10:20 AM, Peter Figliozzi wrote: > In summary, the Couchapp architecture makes > it easier to get started programming web applications, without having to > learn some middleman API. I often present CouchDB as a web server that happens to take care of the database as well :-) -- Robin
Re: Couchapp experience in 2016
I am a data scientist. When I needed to learn how to build a web application, Couchapp was the first thing I learned. I chose it because it was the only thing I could really understand. Viewed as a system, it's a lot simpler to have one thing storing your application code and data, instead of two or more things which must communicate with each other. After my first few apps, I learned to use Backbone, d3, etc. in my Couchapps. I find the results better than what I can get creating an R-Shiny or Flask application. In summary, the Couchapp architecture makes it easier to get started programming web applications, without having to learn some middleman API. On Fri, Sep 2, 2016 at 12:14 AM, Martin Broerse wrote: > > > > deep CouchDB understanding and experience > > > You need tooling but without deep understanding you can deploy an Ember > application as couchapp. See: > https://www.npmjs.com/package/ember-cli-deploy-couchdb > Working example: https://github.com/broerse/ember-cli-blog > > - Martin > > > On Fri, Sep 2, 2016 at 12:00 AM, ermouth wrote: > > > Tried out more or less pure couchapp approach in 2016 realities, I mean > JS > > rewrites and PouchDB. > > > > Written down a story about the project, from the couchapp side: > > http://lesorub.pro/how-it-works > > > > It was interesting experience, couchapps still might be useful, in very > > rare cases ) > > > > ermouth > > >
Re: Couchapp experience in 2016
> > deep CouchDB understanding and experience You need tooling but without deep understanding you can deploy an Ember application as couchapp. See: https://www.npmjs.com/package/ember-cli-deploy-couchdb Working example: https://github.com/broerse/ember-cli-blog - Martin On Fri, Sep 2, 2016 at 12:00 AM, ermouth wrote: > Tried out more or less pure couchapp approach in 2016 realities, I mean JS > rewrites and PouchDB. > > Written down a story about the project, from the couchapp side: > http://lesorub.pro/how-it-works > > It was interesting experience, couchapps still might be useful, in very > rare cases ) > > ermouth >
Re: Couchapp experience in 2016
Awsome! if couchapps was ever worth pursuing, you made the largest contribution to proving so. johs > On 2. sep. 2016, at 00.00, ermouth wrote: > > Tried out more or less pure couchapp approach in 2016 realities, I mean JS > rewrites and PouchDB. > > Written down a story about the project, from the couchapp side: > http://lesorub.pro/how-it-works > > It was interesting experience, couchapps still might be useful, in very > rare cases ) > > ermouth
Couchapp experience in 2016
Tried out more or less pure couchapp approach in 2016 realities, I mean JS rewrites and PouchDB. Written down a story about the project, from the couchapp side: http://lesorub.pro/how-it-works It was interesting experience, couchapps still might be useful, in very rare cases ) ermouth
