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.
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.
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?
Comments
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.
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 2: https://github.com/wvl/highbrow
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?
Operational transform algorithms for collaborative editing are a good fit for this. They are complex and have to run in both places.
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.
I sometimes write server code in the browser before porting it to the server. I find it quicker to debug with Chrome.