
Sammy.js, CouchDB, and the new web architecture - thisduck
http://www.quirkey.com/blog/2009/09/15/sammy-js-couchdb-and-the-new-web-architecture/
======
moe
Yes, history keeps repeating. It's hilarious to watch these kids reinvent,
well, everything, over and over.

So, here we have the return of the fat client, episode 20.

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?

~~~
rcoder
The reasons to stick with DHTML/JS as a "thick client" development platform
are simple: decent, free development tools, the ability to interpose proxies
and application middleware between the client and server transparently, and a
very, very large install base for the client runtime.

That being said, I share much of your amusement at/disdain for the attitude of
"OMG, look at this brand new thing I have made that is completely different
from all those old things!"

~~~
moe
I'm not sure about these reasons.

 _decent, free development tools_

Well, you can have these for any mature platform. Be it QT, Flex or even Java.
I'm not sure what's more decent about the HTML toolchain. The often cited
FireBug is, to me, merely an emergency bandaid that makes development at least
_possible_ but still far from enjoyable.

 _the ability to interpose proxies and application middleware between the
client and server transparently_

There's nothing stopping any fat-client to speak HTTP. You don't need to a
browser for that.

 _and a very, very large install base for the client runtime._

I'd say installation base is a red herring when talking about cross-platform
apps but I'll give you that "instant-on" is an argument. For that I'd point to
Air, which can run hybrid in and outside the browser.

I'm not arguing that HTML doesn't have it's place, mind you. But the extent to
which it is abused nowadays is absurd.

~~~
shabda
> and a very, very large install base for the client runtime.

You are underetimating this. For evrything else, (air, java, Qt, C#) I have to
start a new app. My firefox is always on.

~~~
johnpaulett
In most cases, we are just swapping some startup time (for java, qt, etc.) for
download time in the heavy web 2.0 apps.

------
richcollins
When all you have is a hammer ...

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.

We already have a well designed client architecture. It's called Cocoa and its
implemented in the browser as Cappuccino.

~~~
jherdman
Interesting point. I tend to agree with you. I find myself hesitant about
putting my business logic essentially on the front-end. With the current model
we can hide some of the "secret sauce" that makes our applications unique on
the server end. With something like Cappuccino (or Sammy.js, etc), how do we
keep our secret sauce secret?

~~~
shykes

       > I find myself hesitant about putting
       > my business logic essentially on the front-end
    

Leave the business logic on the server where it belongs - but hide it behind a
REST API, and leave the rendering to the browser.

I think that's the core argument, if you omit the "CouchDB as an app server"
part (which is orthogonal).

~~~
ams6110
This was exactly the approach I took with an app about 4 - 5 years ago. Back
then XML not JSON was the data transport format, but I kept it lightweight.
The UI was built in the browser using XSLT to generate HTML. Additional
transforms tied to UI events allowed filtering, sorting, etc. all on the
client. IE, for all its other flaws, actually supported this much better than
any other browser at that time and we were developing in an IE-only
environment.

Business logic was on the server in stored procedures, which were exposed in a
simple web service api so they could be called directly by the browser script
logic. This also made it very testable because the stored procedures could be
invoked by testing scripts that did not depend on the presence of any middle
tier or UI at all. It also would have been a simple matter to build other
client front-ends, as long a platform could work with XML and HTTP it could in
theory be a client.

The XSLT to render the UI from XML could get a bit verbose but despite that it
turned out to be a very productive way to work.

The downsides at the time were that IE was slow to render when you injected
the HTML output of the transforms into the body.innerHTML property; this
became noticeable if the generated page was large, but on the plus side this
was a constraint against developing overly-complex pages.

------
n8agrin
_With the power of CouchApp and _attachments, the javascript and HTML files
needed to serve the application are served directly out of the database._

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.

------
mcav
Good, _except_ 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.

~~~
Periodic
In this case it will just move into the database. You'll have to start writing
procedures and rules in the database instead of in your web framework and only
expose those instead having only trusted code interact with the DB.

~~~
mechanical_fish
_You'll have to start writing procedures and rules in the database instead of
in your web framework_

This will not fool anyone. You can't fold the business logic into the database
and then pretend that you've eliminated the business-logic layer on the
server. It's still there. You've just driven it into hiding.

~~~
Periodic
Exactly. I don't think there is an equivalence between server code and client
code. There are some things you just can't trust the client to do, so there
will always have to be server code to do it. Whether that code is in a web
server, a framework, a database, it doesn't matter. Someone has to write it.

However, I could see some of the code, such as the code that actually builds
the page the users sees, being pushed into the browser. But then, don't we
already have that with XML and XSLT (or whatever?)

------
chime
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?

~~~
thisduck
I think CouchDB might have built-in authentication coming soon, but I'm not
sure about that.

There's always the option of using HTTP authentication.

~~~
akeefer
Is that really good enough, though? For example, suppose that I write a
blogging platform, and I want to ensure that a user can only query their own
blog entries. How would I do that if the query is coming from the client
(which always has to be untrusted) directly to the database? What prevents
someone from rewriting the js client side so that it queries blog posts from
other users? Or to prevent it from just sucking back all the blog posts in the
DB and essentially DOSing the whole server?

Doing per-user security directly in the DB with simple CRUD permissions per
table would be enough of a headache, but most applications eventually require
finer-grained security than that, and for performance reasons you also don't
want a client to be able to execute just any arbitrary query.

It seems like this is pretty close to same trap a lot of people fall into of
only enforcing data validation client-side, or only enforcing things like view
permissions client-side (by not rendering links), which leaves all sorts of
holes open.

~~~
iamwil
Well, all queries are accessed through URLs. There are two types of queries:
temp views and permanent views. You can use apache/nginx to redirect all query
through URLs for temporary views. Permanent views are stored on the db. That
way, your client can't execute arbitrary queries. Then, the client can only be
limited to views/queries that the web dev set.

<http://wiki.apache.org/couchdb/Nginx_As_a_Reverse_Proxy>

Then as long as the client can keep its identification token secret from
others, you can implement "user can only query their own blog entry"

I suggest you look into couchDB a bit further. CouchDB is a different beast
altogether from relational databases. Therefore, the assumptions you make
about what a database can and cannot do coming from a relational world doesn't
always apply.

------
dolinsky
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).

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.

------
gcv
I like this idea quite a bit. No application server means less maintenance and
less administrative overhead.

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.

------
sunkencity
learning JavaScript & 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.

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...

------
tzury
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?

------
cmelbye
Is anyone actually using this architecture?

------
californiaguy2
Stop the madness. Just stop it.

