What the HTTP is CouchApp?(couchapp.org)
couchapp.org
What the HTTP is CouchApp?
http://couchapp.org/page/what-is-couchapp
11 comments
Calling the standard stack "fragile custom code" doesn't do much for their credibility here. I mean, really. Fragile?
Have you ever tried keeping a web application running? It's hard. About as close as we've gotten to doing it well is the plain-old PHP and Apache httpd stack. I've written PHP apps that stay up for years as long as I pay the bill. I was never able to get anywhere close to that reliability from other web stacks. CouchApps aim to be simpler and more reliable, so that eventually end-users can deploy and perhaps even create them.
Not playing devil's advocate here, but a deep concern:
Today's world is full of programmers posing as production administrators, while the solution is to employ administrators and move on. I've seen so many production failures because of admin-posed programmers wishful thinking or not having a sufficiently broad perspective to prepare themselves for the disaster. It was regardless if it was a simple Apache+PHP, hairy Weblogic+Oracle stack or some new sexy Erlangish stuff.
I have nothing against programmers and I am both admin & programmer myself, but many (most?) coders just lack some operational perspective & experience. Is is possible that selling new solutions as "don't plan, deploy & pray" will make this trend worse?
Today's world is full of programmers posing as production administrators, while the solution is to employ administrators and move on. I've seen so many production failures because of admin-posed programmers wishful thinking or not having a sufficiently broad perspective to prepare themselves for the disaster. It was regardless if it was a simple Apache+PHP, hairy Weblogic+Oracle stack or some new sexy Erlangish stuff.
I have nothing against programmers and I am both admin & programmer myself, but many (most?) coders just lack some operational perspective & experience. Is is possible that selling new solutions as "don't plan, deploy & pray" will make this trend worse?
The important thing to keep in mind is that by "deploy" I mean "install" -- the goal is to make CouchApps as easy to share / replicate / install on end-user devices like cellphones and laptops.
Once you have a fully replicating application, you want to run it as close to the user as possible to avoid network latency. I don't think the deployment challenges of large centralized apps will go away, but there are a lot of apps that better fit the decentralized model.
Now that CouchDB makes decentralized web apps possible, we'll get to see what can be done.
Once you have a fully replicating application, you want to run it as close to the user as possible to avoid network latency. I don't think the deployment challenges of large centralized apps will go away, but there are a lot of apps that better fit the decentralized model.
Now that CouchDB makes decentralized web apps possible, we'll get to see what can be done.
I've built and deployed more ASP / SQL Server (or occasionally Access!) than I care to remember; I'm doing more ASP.Net now, after some time on desktop apps in between. Either way, I've never had reliability issues.
map reduce for a blog - brilliant!
now in the real world:
now in the real world:
select data
from this_table and this_table and this_table and that_table
where there was no previously defined relationship
but users need this data with the new relationship
and have it done in a few minutesWait a minute. Unless you already built RDBMS tables with that relationship in mind, you are just as screwed there as you are in Couch. And if you are talking about the time it takes Couch to build a new index for some custom view, I'm sure it's nominal compared to the number of times you feel the need to change or create one.
How about defining views?
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 code working together with everything else. At which point you wonder what was the point?
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 code working together with everything else. At which point you wonder what was the point?
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.
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.
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.
Ah, soon we will be writing stored procedures in the database tier to enforce business logic again, like the good (read: miserable) old days.
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.
This project really challenges a lot of my assumptions. I'm not sure how I feel about it yet.
I'm going to sleep on it.
I'm going to sleep on it.
"Your site can be faster than theirs, if you serve it from localhost."
Is there some arcane wisdom in here, or is this just stupidity? Sure, if I run Google on my own computer, and replicate it to my laptop, they will both be very fast... and need quantum HDs for storage.
Is there some arcane wisdom in here, or is this just stupidity? Sure, if I run Google on my own computer, and replicate it to my laptop, they will both be very fast... and need quantum HDs for storage.
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
http://guide.couchdb.org/draft/validation.html
No, there are 2 special types of views that take the result of a query and format it in some way. Can't remember but I asked them once.
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.
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.
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.
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?