Break CouchApp stuff into a separate module? #209
Comments
Actually, the plug-ins that power show/update/list etc. in express-pouchdb do also work in the browser on top of PouchDB. Isomorphic client/server rendering is what I had in mind when I build them first. It needs more work (mostly: experimenting with it in a real app setting) though. [1]
The major problem with splitting out the design doc endpoints is that the order of which they're defined in the index.js file matters (Because of function wrapping and the order in which middleware is executed). Everything else is pretty much already separated cleanly. So that's the thing to solve, although I'm not sure how. From a user point of view, the easiest might be to just make the minimumForPouchDB mode the default if CouchDB does make this change. [1] Originally I naively hoped I could pouchify existing couchapps with minimal changes, but not being able to intercept browser network requests makes that too hard. Links, xhr and forms are easy. CSS images is harder, but I had it working. DOM modification using JS made it an impossible task, though. 😞 |
|
Wow, that's actually really cool. :) Isomorphic CouchApps may be a great way to revive them! |
|
I just ran an existing CouchApp on top of PouchDB. Service workers are awesome. More info. It's going to take some time though before service workers mature. In the meantime, I have high hopes for a new model of building CouchApps. Basically, you write a JS app as usual (I used React), but use CouchDB to do the prerendering. This does require a few changes to the way you write the JS app (only use the data as available by the current database query), but you get sync for free because of that. And, in the case of React, live updates of the app whenever the database changes. But that approach still needs a bit more work until I can produce a write up. |
|
Careful down the road of CouchApps, at least at this point. What I envision is a node server that lives alongside CouchDB that implements all the cool things you could think of, without having to burden the Erlang developers with a feature they don’t care much about. |
|
I vote we continue this in #271 which is very similar. I might add that if we're talking about just show/list/update, so not about rewrites/views, splitting them of is probably feasible. For the others, it comes back to the integration problems I've described here and in #271. Closing, feel free to reopen if you disagree. |
* PouchDB plugin updates. (new replicator plug-in initial code - pretty much untested). Also validation update (will become 1.1.0). * A bunch of JS improvements (incl. replicator module (experimental)) & some improvements to coroutines (nesting them, most notably) * Improved docs + JS * Improvements to replicator + auth; documentation translations * Smaller JS modules. * Makes _users and _replicator databases system databases (sets extra protections for them like in CouchDB). No regressions, but JS test coverage isn't complete yet. * JS is all at 1.0.0 at least now & published. * Fixed a bug in pouchdb-wrappers * pouchdb-replicator update. * Improvements to pouchdb-replicator * Plug-in improvements * 2.1.2; moved to github * (pouchdb#232) - Modernize pouchdb-replicator * 2.1.3 * chore(package): update dependencies http://greenkeeper.io/ * chore(package): update pouchdb-plugin-helper to version 3.0.0 http://greenkeeper.io/ * chore(package): update random-uuid-v4 to version 0.0.6 https://greenkeeper.io/ * add pouchdb-replicator to the repo * convert tests to es2015 * remove packages
This reverts commit b824fbd.
There's been some discussion in the CouchDB mailing list about where CouchApps actually fit into the CouchDB story, with some indication that maybe they will be broken out into a separate module at some point.
@marten-de-vries I know you put a lot of effort into getting show/update/list/etc. working in pouchdb-server, and I think it definitely makes sense to keep it somewhere, but how easily do you think it could be extracted into an optional component? Do the
modes help with that?Personally I think CouchApps are interesting, but I've just never had any use for them. More and more, web applications are moving toward the "thick-client" model, where the web server is just a simple JSON API and doesn't have much involvement in generating HTML pages. Even where server-side rendering is becoming common (ReactJS, Ember FastBoot), it's coming from a client-oriented design, where the same templating code that's executed on the client is simply pre-executed on the server for a faster initial load.
CouchApps currently have none of this "best of both worlds" approach (isomorphic client/server rendering), and it would be tough to get there unless we managed to have show/list/etc. run within PouchDB on the client, in which case PouchDB becomes a view layer as well as a database. (Kinda weird in my mind. 😃)
Basically I agree with what @jchris said on Twitter. I'd be in favor of breaking CouchApps out into a separate plugin.
@janl @daleharvey thoughts?
The text was updated successfully, but these errors were encountered: