6 ms·

Is there really any practical examples of sharing code between back-end and front-end? I only see really specific use-cases, such as sharing the logic of a game

Is there really any practical examples of sharing code between back-end and front-end? I only see really specific use-cases, such as sharing the logic of a game between the client and the server, since most of the time the back-end serves the content and the front-end displays it.

dang 12y ago
> Is there really any practical example of sharing code between back-end and front-end? Operational transform algorithms for collaborative editing are a good fit for this. They are complex and have to run in both places.
aikah 12y ago
This is the weakest argument for the use of nodejs in my opinion. But I can imagine people sharing models and validation code in an AJAX heavy app.
bryanlarsen 12y ago
Shared code can be a huge win in certain scenarios. 1. the server can run the client code to render and serve HTML, so you get all the benefits of server side rendering as well as client side rendering. [1][2] 2. imagine you have an architecture that allows multiple clients to simultaneously modify a single document, like google docs, or like all your standard cookie-cutter enterprise form & report interface to records in a database database. Now imagine that you need to do some sort of batch operation to these documents. If your code is written in Node, you just run your client code on the server. Instead of directly manipulating the database from your batch workers, you use the standard REST & WebSocket API that your clients do. This is called a service-oriented code structure, and there are huge advantages to this; so big that everybody is switching to it. Node makes it almost free. 1: https://github.com/rendrjs/rendr https://github.com/rendrjs/rendr 2: https://github.com/wvl/highbrow https://github.com/wvl/highbrow
- rimantas 12y ago
  Regarding the first point… what's the point really? Either you render it on the client, or you render it on the server, then client couldn't care less what did you use to render it as long as it gets HTML it wanted. If you feel the need to render something in both places I feel that you have some seriously overcomplicated architecture. Regarding the second point: if the client modifies the document through the API calls, who cares what technology is used to implement those API methods?
jaxytee 12y ago
I sometimes write server code in the browser before porting it to the server. I find it quicker to debug with Chrome.

dang 12y ago

> Is there really any practical example of sharing code between back-end and front-end? Operational transform algorithms for collaborative editing are a good fit for this. They are complex and have to run in both places.

aikah 12y ago

This is the weakest argument for the use of nodejs in my opinion. But I can imagine people sharing models and validation code in an AJAX heavy app.

bryanlarsen 12y ago

Shared code can be a huge win in certain scenarios. 1. the server can run the client code to render and serve HTML, so you get all the benefits of server side rendering as well as client side rendering. [1][2] 2. imagine you have an architecture that allows multiple clients to simultaneously modify a single document, like google docs, or like all your standard cookie-cutter enterprise form & report interface to records in a database database. Now imagine that you need to do some sort of batch operation to these documents. If your code is written in Node, you just run your client code on the server. Instead of directly manipulating the database from your batch workers, you use the standard REST & WebSocket API that your clients do. This is called a service-oriented code structure, and there are huge advantages to this; so big that everybody is switching to it. Node makes it almost free. 1: https://github.com/rendrjs/rendr https://github.com/rendrjs/rendr 2: https://github.com/wvl/highbrow https://github.com/wvl/highbrow

rimantas 12y ago
Regarding the first point… what's the point really? Either you render it on the client, or you render it on the server, then client couldn't care less what did you use to render it as long as it gets HTML it wanted. If you feel the need to render something in both places I feel that you have some seriously overcomplicated architecture. Regarding the second point: if the client modifies the document through the API calls, who cares what technology is used to implement those API methods?

jaxytee 12y ago

I sometimes write server code in the browser before porting it to the server. I find it quicker to debug with Chrome.