Hacker News Reader

Comment by judofyr | Hacker News Reader

I keep hearing about this, but has anyone actually done this?

Yes, we built [1]tilemill and [2]mapbox hosting using this technique. It's pretty awesome when it works, but can be quite tricky in other ways.

The first is a hybrid desktop/web application to design maps using a CSS like descriptor language. The desktop app downloads actually bundle a local node server in an os specific wrapper, with a web view. The application works just as well hosted and accessed by multiple user.

The latter is a cloud service that allows you to host rendered map layers and remix/share them. Foursquare recently switched to using mapbox for all their browser based maps.

I'd estimate at least 90% of the code is shared between the server and the client, with the server side generally only differing when you need to access resources not available to the client (databases, files on the server etc). The user interfaces can be rendered on either the client or the server (w/ jsdom) as needed.

[1] mapbox.com/tilemill [2] mapbox.com/hosting

BrowserQuest, which is written in Node, put their inventory tracking system client side. Brilliant!

http://www.raymondcamden.com/index.cfm/2012/3/28/How-I-cheat...

I haven't in a huge way, but I have definitely shared constants, utility functions, and some application logic that are used identically server-side and client-side.

It's probably not a HUGE boost in productivity, but it does feel really, really nice. And just knowing you can take your server-side data structures, trivially insert them into client-side scripts with JSON.stringify() or Ajax calls, and have the same helper libraries you use server-side be able to operate on them client-side, makes it so easy and flexible.

(I'm working on a project that uses IcedCoffeeScript both server-side and client-side, which lets us use the same async event-handling model on both sides as well -- another plus.)

And furthermore, what are the security ramifications of doing this?

At first glance, it seems attackers would be able to forge JSON objects resulting in "mass-assignment" style vulnerabilities (unless there is lots of protection logic) when sending JSON objects back to the server side.

However, going in the other direction (sending JSON from server to client) is a very common pattern.

This. Most tutorials of Backbone/Ember js apps I've seen have thin backends that commit any json objects the clients send them.

Data sanitization and validation on the backend should be as thourough as that of the client, if not more.

Who in their right mind does data validation on the client? However, there are (very easy) ways to store data on the client and be sure they haven't been tampered with. Just HMAC it along with a secret and check it next time.

My startup uses node to handle all database operations and essentially only serves JSON via AJAX, while the most HTML it sends is basically <script src="script.js"></script>. The entire app itself along with user-generated content depends on a few large (highly variable) objects sent as JSON where the DOM is manipulated based on this minified data.

As a bit of a backup measure (mainly to prevent XSS), the client-side javascript sanitizes (which is what I believe you partly mean by data validation) all objects sent to the client when as they receive it. So anyone using the intended client-side script should never be susceptible to XSS.

But if by "data validation" you were referring to concepts like whether or not a user has permission to access/modify some part of the database, of course that is checked server-side.

The latter is more what I meant, yes. Basically, we all know you shouldn't trust the client ever.

Well, because the same code runs in both places, you end up with a situation where you are _also_ running the validation (most of it) on the client.

The models can (and should) still be validated on the server before you actually save it, but this is child's play. There is a certain category of validation that can only happen on the server too, like 'has this username been taken already?'.

You can just sign the data, then they can't just change it.

Reply on news.ycombinator.com