5 ms·

The ability to share models/code between the client side and server side is magic at first. Javascript on every level with the data encoded in JSON? Yes, please

by switz 15y ago

The ability to share models/code between the client side and server side is magic at first. Javascript on every level with the data encoded in JSON? Yes, please.

judofyr 15y ago
I keep hearing about this, but has anyone actually done this?
- gphil 15y ago
  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.
  - sespindola 15y ago
    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.
    - StavrosK 15y ago
      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.
      - tfb 15y ago
        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.
        StavrosK 15y ago
        The latter is more what I meant, yes. Basically, we all know you shouldn't trust the client ever.
      - AdrianRossouw 15y ago
        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?'.
  - StavrosK 15y ago
    You can just sign the data, then they can't just change it.
- bascule 15y ago
  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-cheated-Mozillas-new-HTML5-Game http://www.raymondcamden.com/index.cfm/2012/3/28/How-I-cheat...
- crazygringo 15y ago
  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.)
- AdrianRossouw 15y ago
  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

by switz 15y ago

The ability to share models/code between the client side and server side is magic at first. Javascript on every level with the data encoded in JSON? Yes, please.

judofyr 15y ago

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

gphil 15y ago
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.
- sespindola 15y ago
  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.
  - StavrosK 15y ago
    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.
    - tfb 15y ago
      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.
      - StavrosK 15y ago
        The latter is more what I meant, yes. Basically, we all know you shouldn't trust the client ever.
    - AdrianRossouw 15y ago
      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?'.
- StavrosK 15y ago
  You can just sign the data, then they can't just change it.
bascule 15y ago
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-cheated-Mozillas-new-HTML5-Game http://www.raymondcamden.com/index.cfm/2012/3/28/How-I-cheat...
crazygringo 15y ago
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.)
AdrianRossouw 15y ago
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