Sammy.js, CouchDB, and the new web architecture

Yes, history keeps repeating. It's hilarious to watch these kids reinvent, well, everything, over and over.<p>So, here we have the return of the fat client, episode 20.<p>And as with all the other episodes the standard question remains: If you're going fat-client then why on earth stick to a platform as horrible as HTML/JS?

When all you have is a hammer ...<p>jQuery is not a good architecture for a full client application. jQuery is meant for flipping some dom attributes here and there. It does a poor job of modeling the UI state. Sinatra is also a poor architecture choice for the client since the client has persistent state.<p>We already have a well designed client architecture. It's called Cocoa and its implemented in the browser as Cappuccino.

<i>With the power of CouchApp and _attachments, the javascript and HTML files needed to serve the application are served directly out of the database.</i><p>That statement kind of troubles me. It shows that you're really just offloading all of the work from a normal app server to the data storage layer. From a "Mom look what I can do!" perspective this is cool, but, again, you're not eliminating your app server. Couchdb allows this because it uses HTTP as it's communication protocol, but one could do the same with MySQL, via an HTTP communication frontend, which sounds a lot like what Rails, Django, etc effectively are with some optimizations to make other non-data-storage operations faster.

Good, <i>except</i> that you still have to deal with authentication, authorization, and other security aspects of a server-side component. Server-side code won't go away no matter how fat the client gets.

Honest question: How would one go about implementing authentication/security into such a setup? Maybe it could work for 1-writer, many reader apps (blogs) but how do you handle user signups, accounts, and security with this?

This might work for the simplest of sites like some have pointed out (e.g. a blog) but what I can't accept is having application logic on the frontend. Beyond authentication (let's say OAuth et all solve that issue down the road), one of the benefits of having serverside code is that when it comes down to it, you as a developer don't care if the user messes with the frontend (exposed) business logic (usually form validation of some type) because you're always checking it again / cleansing it on the serverside. That's the tip of the iceberg...ranking algorithms, limits on certain activities (rules in general).<p>Now, that serverside code can be javascript serverd on something akin to 10gen if javascript is their tool of choice, but exposing any of those to the user so that they may edit them without any secondary sanity check is unacceptable.

I like this idea quite a bit. No application server means less maintenance and less administrative overhead.<p>Of course, it also means that the newly-empowered database has to scale out just as easily as an application server. For starters, request authentication becomes the responsibility of the database, and that could mean heavy volume.

learning JavaScript &#38; prototype i wrote a Twitter clone around this idea. I put up a number of textfiles in different user directories, and turned apaches directory listings on, and voilà a very basic restful interface. I also added post somehow, maybe a php script.<p>The client-side script could read who to follow from the server and by itself performed the task of assembling the timeline which was the CPU and IO extensive task that twitter had problems scaling with. Not sure the extra bandwidth cost of performing this client side would be worth it, but there's almost no logic at all server side so there's not much scaling of processor power at least. Programming with prototype was fun, but then I found jQuery...

How on earth are these guys going to prevent a user from reading all the credit cards from that couch-db via its json interface?

Is anyone actually using this architecture?

Stop the madness. Just stop it.