Live data from Hacker News

First Impressions of Sitting a Web App on CouchDB

victusspiritus.com

1–10 of 21 posts

Re: First Impressions of Sitting a Web App on CouchDB

#5
post #4

Is the idea supposed to be that a web client (html+js) reads and writes directly to a CouchDB server? Where do you put business logic?

Well, in a normal web app you put it where you normally do; it gets shoved in various .rb or .py or whatever and you just call the database as usual.

for an app written in coudb:

http://guide.couchdb.org/editions/1/en/managing.html is a breakdown of the source tree and explains things.

Re: First Impressions of Sitting a Web App on CouchDB

#6
post #4

Is the idea supposed to be that a web client (html+js) reads and writes directly to a CouchDB server? Where do you put business logic?

All business logic is in the database itself. It has ACL's and data validation built into one feature (update validation) and as for deciding which data to display and when, the map/reduce-based view API is extremely powerful.

Force yourself to use CouchDB for a project where you're handling large amounts of data and you'll discover how incredible it really is. There's tons of other great features you'l pick up along the way too.

Re: First Impressions of Sitting a Web App on CouchDB

#8
post #4

Is the idea supposed to be that a web client (html+js) reads and writes directly to a CouchDB server? Where do you put business logic?

It certainly doesn't fit every application, but it's possible to write a write-controlled app using validation functions[1].

I've written an introduction to using Evently and CouchApp if you're interested in seeing how that works[2].

[1] http://guide.couchdb.org/draft/validation.html

[2] http://mindeavor.com/blog/the-anatomy-of-a-couchapp

Re: First Impressions of Sitting a Web App on CouchDB

#9
From the article: "CouchDB + Another Layer as Web Server is Redundant". This is very true, and the biggest difference to other databases I've used, NoSQL or not. It ends up being a double-edged sword for CouchDB.

On the one hand, it saves having to context switch between thinking about the database, thinking about the web server, thinking about the web framework, etc.. For a single developer, this is not to be sniffed at. As learning is often done by lone experimentation, it makes CouchDB an excellent system for learning about NoSQL. It's also great for prototyping, where you don't necessarily want to spend a huge amount of time creating an industrial strength back-end.

On the flip-side, it means that if you do run into a situation where you want to use another layer, you've just given up the biggest advantage of CouchDB. For my current project, I found I would need to be able to integrate authentication with an existing Kerberos system - the easiest way to do this was to use Apache.

I also had slight reservations about CouchDB's approach of limiting what you can do - everything has to be a map-reduce - to ensure scalability. The plan as I understand it is to introduce further safe operations down the road. I'm sure that approach will yield dividends, but for now it seems quite limiting - similar to eschewing C in the 70s because it does not have garbage collection.

Didn't mean to beat up on CouchDB too much - it's a fine system, but I prefer the flexibility of MongoDB at this point.

Re: First Impressions of Sitting a Web App on CouchDB

#10

From the article: "CouchDB + Another Layer as Web Server is Redundant". This is very true, and the biggest difference to other databases I've used, NoSQL or not. It ends up being a double-edged sword for CouchDB. On the one hand, it saves having to context switch between thinking about the database, thinking about the web server, thinking about the web framework, etc.. For a single developer, this is not to be sniffe…

You also give up replication, not only of the data, but of the entire web application. CouchDb's replication shouldn't be overlooked not as a technology, but in its various applications of a decentralized system.
Post reply on HN