couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Mitchell <>
Subject Re: show/list
Date Thu, 14 Nov 2013 21:20:04 GMT
On Thu, Nov 14, 2013 at 4:03 PM, Lance Carlson <> wrote:
>> Outside of the browser case, the need to present data with specific
> structure, filtering, and context is a real feature. Usually I manage
> to produce views if I need specific processing to be done. From my
> point of view the current show/list implementation fits this case
> poorly. I'd prefer to talk about the problem being solved rather than
> starting with a solution and finding a problem to keep it around.
> There might be a great way to get show and list to fit these needs or
> there might be an entirely new API.
> What did you have in mind?

I've been thinking on this but I don't have a proposal to share yet.
It's certainly something that will be easier to solve by discussing
what our problems actually are in the open here. I think the plugin
system might be a great way to allow some of these prototypes to be
put to use in an experimental sense. Things that work really well
could be merged into the core while others could be moved out.

>> One example where we don't have good solutions and force the client to
> do lifting is conflict handling. A show implementation that could do
> merges on read could be very useful IMO.
> +10
>> [0]: Benoit's work on event source support is a great example of
> making it easier for browser based clients to interact more seamlessly
> with CouchDB. CORS is another area where CouchDB is pushing away the
> need for middle tiers. I don't see show and list as a good way to
> remove rendering as a tier. Browser-side rendering seems superior in
> every way except SEO.
> Do you have any ideas on how we deal with SEO? Revert back to the middle
> tier?

In the past I've used a publishing tool that would generate static
snapshots that were updated as needed. From there, a user would hit a
static page and download JS which would subsequently render everything
via JS, the same templates (something like Mustache usually), and JSON
coming from CouchDB. This made it easy to have fast load times and
leverage CDNs while making the dynamic parts of the app seamless.

This beats the CouchDB side by having quicker search bot indexing
(they'll be able crawl S3 much much faster than CouchDB usually),
providing a nice failover if the database goes down (links work just
like they used to in the old web if you can't talk to CouchDB and
dynamic page elements are either replaced with default content or

That does mean you have a third moving part but it's not really a
middle tier. It doesn't sit between the browser and CouchDB. The cons
are that this doesn't work very well for apps where the content is
always dynamic (though search engines rarely index those very
effectively anyway), the lack of a good place to put the code that
pushes the static site out (it could be a couchdb subprocess of sorts
I guess), and you'll need something like CORS, a smart CDN, or some
hidden-iframe-proxy to enable the browser to load content from CouchDB
as a different origin.

View raw message