incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Iriele <siriele...@gmail.com>
Subject Re: show/list
Date Thu, 14 Nov 2013 21:49:41 GMT
@Fillipo That argument ca be made about just about any software design..but
CouchDB has this very nice separation of "what you get back" vs "what is
stored". If i have a gian document and I want an array of of say player
installs from my document..why should i load up the entire thing when i
only need a small tid bit of it?....If i had a class document and i wanted
the first 3 students..why then should I pull out other needless information
from the database?...

...when people come from the LAMP stack world they get very nervous about
rethinking the delegation of responsibilities...One thing that i keep
seeing is..."I dont need a server in the middle because list/shows takes
care of it"....then the following is "they do not replace app
serves"...this is a strange argument but so sum it up...app servers are not
replaced by list show functions and should not be...there are times when
all your need is a few random calls and MAYBE..for some cases you don't
need one....but to be honest they can exist in both spaces just fine...

basically it boils down to this...show/lists, as well as update handlers,
functions allow you to keep your app server code simpler be re-delegating
responsibilities...they also have to do less if you do this right which
means...less smaller memory footprint, only serialize/deserialize what you
need to, etc.

It took me quite some time to get to the point of realizing this but...I'm
here now and I've heard this argument too many times (partly because i was
on the other side at some point :-D)...also...these 2 killer
features..couchbase said they are not supporting...i.e...I'll never use it


On Thu, Nov 14, 2013 at 1:20 PM, Brian Mitchell <brian@strmpnk.co> wrote:

> On Thu, Nov 14, 2013 at 4:03 PM, Lance Carlson <lancecarlson@gmail.com>
> 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
> omitted).
>
> 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.
>

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