Sammy.js, CouchDB, and the new web architecture • Hacker News Board

Re: Sammy.js, CouchDB, and the new web architecture

#11

Post by n8agrin » Tue, Sep 15, 2009, 5:02 PM UTC

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.

Re: Sammy.js, CouchDB, and the new web architecture

#12

Post by akeefer » Tue, Sep 15, 2009, 5:08 PM UTC

thisduck wrote: post #5

chime wrote: post #4

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?

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.

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.

Re: Sammy.js, CouchDB, and the new web architecture

#13

Post by richcollins » Tue, Sep 15, 2009, 5:45 PM UTC

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.

Re: Sammy.js, CouchDB, and the new web architecture

#14

Post by tewks » Tue, Sep 15, 2009, 6:14 PM UTC

moe wrote: post #6

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?

There is an important aspect that not many "fat clients" have solved except the iPhone (except for the fact many iPhone apps are pirated and end up torrented): a reliable way to charge users... 50% of Photoshop installs are pirated; I wonder how many users of Salesforce are using pirated copies?

Re: Sammy.js, CouchDB, and the new web architecture

#15

Post by Periodic » Tue, Sep 15, 2009, 6:14 PM UTC

akeefer wrote: post #12

thisduck wrote: post #5

Earlier quoted context omitted.

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.

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 suckin…

I kept hoping the next paragraph would address this, but it didn't.

It's cool and all, but it sounds like you're still going to basically need a server stack there to enforce permissions and some logic and consistency things. For example, say users have some private data. What stops me from modifying the javascript to insert a record that points to someone else's email address in my record? Unless the database can see this and prevent it I might then be looking at or even able to change someone else's email on their account. It can get very hairy if you don't have full control over the database interaction because you have to start guarding against arbitrary database operations.

Re: Sammy.js, CouchDB, and the new web architecture

#16

Post by Periodic » Tue, Sep 15, 2009, 6:15 PM UTC

mcav wrote: post #3

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.

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.

Re: Sammy.js, CouchDB, and the new web architecture

#17

Post by dolinsky » Tue, Sep 15, 2009, 6:16 PM UTC

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.

Re: Sammy.js, CouchDB, and the new web architecture

#18

Post by omouse » Tue, Sep 15, 2009, 6:25 PM UTC

rcoder wrote: post #7

moe wrote: post #6

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?

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 c…

Tools for developing Qt and Java applications are also free and are much much better than anything that has been created for DHTML/JS so far.

Java too has a very large install base. It is a shame that SUN didn't do much to promote it but you can still take advantage of the fact that many many people have the JVM installed.

Re: Sammy.js, CouchDB, and the new web architecture

#19

Post by sunkencity » Tue, Sep 15, 2009, 6:46 PM UTC

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

Re: Sammy.js, CouchDB, and the new web architecture

#20

Post by iamwil » Tue, Sep 15, 2009, 6:47 PM UTC

moe wrote: post #6

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?

I hear all the negatives of why it wouldn't work, and everything that's wrong with it. And it's certainly healthy to be skeptical. But I don't hear anyone talking about what its possibilities are.

While it might be the new old thing, it's happening in the context of a different tech env, different market. The limitations of the old old thing might be different for the new old thing.