Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What the HTTP is CouchApp?

couchapp.org

Post reply on HN
Print view View original

21–28 of 28 posts

Re: What the HTTP is CouchApp?

#21

Post by jchrisa »

JamesNK wrote: post #13

So have any real world applications successfully used this as a framework? It looks interesting but I see any moderately complex web app, i.e. more than CRUD, hitting a wall of complexity when using CouchApp as a base. You eliminate so called "fragile custom code" up until the point where the framework doesn't support something and you need the custom code anyway, except now there is the overhead of getting custom co…

The most complex thing I've done with it is this Twitter client: http://jchris.couchone.com/twebz/_design/twebz/index.html

It uses OAuth and all that good stuff. The "fragile" parts are handled by an asynchronous _changes based process (Node.js is a good fit but really anything works).

The key is to get anything that could go wrong, out of the request / response loop between the browser and the server. The asynchronous handler pattern is a best practice anyway (resize an image on POST, or in a queue?). Keeping the request / response critical path simple makes for more reliable apps.

Re: What the HTTP is CouchApp?

#22

Post by jchrisa »

gaiusparx wrote: post #12

Where normally does a couchapp put its application/business logic? At client side javascript?

There is a server-side JavaScript validation function which can reject updates for being malformed or if the user isn't allowed to proceed:

http://guide.couchdb.org/draft/validation.html

Re: What the HTTP is CouchApp?

#23

Post by jchrisa »

benblack wrote: post #6

CouchApp really is excellent marketing, folks, and I congratulate you. As I'm sure you know, any database with an HTTP interface will do exactly the same thing. Riak, for example. I leave you to your normal round of thoughtful, reasoned NoSQL vs RDBMS debate.

Riak and other HTTP based databases do not have the peer-based replication which sets CouchDB apart. Being able to share an application and its data with a simple HTTP call, and synchronize it across all your phones and laptops -- that is not something other databases can do.

Re: What the HTTP is CouchApp?

#24

Post by equark »

I wish the couch guys would just focus on integrating the _changes feed into different languages. What I find appealing is their attempt to solve the distributed sync problem. That's useful, but adopting couchdb on all the clients doesn't make much sense. Microsoft's sync framework is moving to allowing full cross language / platform sync. It already allows two-way syncing odata feeds to the iPhone, android, windows phone, and pure javascipt. I don't see why I need build all my clients on couchdb directly to get this functionality. It seems like a nonstarter for 95 percent of use cases.

Re: What the HTTP is CouchApp?

#25

Post by aneth »

jchrisa wrote: post #20
aneth wrote: post #9

Not sure how I feel about exposing my database directly to a client. This means all security regarding reading and writing any data must be handled in CouchDB. Not knowing about CouchDB, the existence of CouchApp leads me to believe there must be some way to do this, but I can't see how this would be possible with MySQL or Postgres. Cell level security in a database? Hmm.

CouchDB's security is per-database (since you assume you will be replicating a complete database to the end-user, the concept of cell-level security doesn't make sense).

Cell-level security would never make sense, which is why you need an application layer to perform queries and return and modify only data that a client has permission for.

Am I right that the database would be shared by all clients and that the application layer is essentially moved into the client? If so, this seems like a pretty silly architecture.

Re: What the HTTP is CouchApp?

#26

Post by jchrisa »

aneth wrote: post #25
jchrisa wrote: post #20

Earlier quoted context omitted.

CouchDB's security is per-database (since you assume you will be replicating a complete database to the end-user, the concept of cell-level security doesn't make sense).

Cell-level security would never make sense, which is why you need an application layer to perform queries and return and modify only data that a client has permission for. Am I right that the database would be shared by all clients and that the application layer is essentially moved into the client? If so, this seems like a pretty silly architecture.

yes the application runs entirely on the client, but validation functions are run on replication, so I can change my copy of your blog post, but you won't let me change it via replication. That would be silly.

Re: What the HTTP is CouchApp?

#27

Post by prodigal_erik »

jchrisa wrote: post #26
aneth wrote: post #25

Earlier quoted context omitted.

Cell-level security would never make sense, which is why you need an application layer to perform queries and return and modify only data that a client has permission for. Am I right that the database would be shared by all clients and that the application layer is essentially moved into the client? If so, this seems like a pretty silly architecture.

yes the application runs entirely on the client, but validation functions are run on replication, so I can change my copy of your blog post, but you won't let me change it via replication. That would be silly.

Is that desired behavior in CouchDB? If replication will refuse to change anyone else's copy of that document, changing my own copy merely desynchronizes my replica and deceives myself about the true state of the world. I would prefer the system know which changes would be rejected elsewhere, and stop me from making them in the first place.

Re: What the HTTP is CouchApp?

#28

Post by aneth »

jchrisa wrote: post #26
aneth wrote: post #25

Earlier quoted context omitted.

Cell-level security would never make sense, which is why you need an application layer to perform queries and return and modify only data that a client has permission for. Am I right that the database would be shared by all clients and that the application layer is essentially moved into the client? If so, this seems like a pretty silly architecture.

yes the application runs entirely on the client, but validation functions are run on replication, so I can change my copy of your blog post, but you won't let me change it via replication. That would be silly.

In addition to erik's comment, I'm also concerned about what people can read. What about email addresses in the user table? Deleted posts and edit history? Privately shared content? Does validation allow the restriction of who can view certain content?
Post reply on HN