3 ms·

So node.js can replace Java/Tomcat? I guess I'll have to pinch my nose and somehow start liking JavaScript. Typescript looks good, that might make it palatable.

by jebblue 11y ago

eklavya 11y ago
I read the article and don't think they meant this. They wanted server side (selective) rendering and didn't want the hassle of two languages so they went with node.js. quote"Without shared rendering logic we couldn't have realized the potential of rendering only what was necessary on startup and everything else as data became available."
Wintamute 11y ago
I imagine a common architecture for universal apps will be to just use some sort of thin Node.js app to perform the actual app rendering, and have it communicate with a separate API app written in whatever language is most appropriate. Static files could either be served by the Node.js app, or even a different source. And these days ES6/ES7 makes Javascript very palatable indeed. Check it out :-)
- madeofpalk 11y ago
  That's exactly how you do it :) You have one 'Universal Application', and then you have two small entry points: - server.js is a small (express) server to send a HTTP response to the client (server bootstrapping) - client.js renders a page and the mounts it onto a DOM node. To get around the issues of database access, it makes it a lot easier to put all of that into an API that can be accessed by the server and the client. Here's a very small project I build (and am continuing to build) to learn about this architecture https://github.com/joshhunt/reactapus https://github.com/joshhunt/reactapus
  - Wintamute 11y ago
    Aha yes, I like the look of your project ... nice work! I've got something fairly similar going on. https://github.com/madebycomrades/autokitty-react https://github.com/madebycomrades/autokitty-react
    - madeofpalk 11y ago
      Oh that's awesome. I'm still trying to learn and understand the Flux/Redux pattern, my project is essentially rewritten from this https://github.com/erikras/react-redux-universal-hot-example https://github.com/erikras/react-redux-universal-hot-example Your project looks like it will be a very helpful resource for learning. Thanks for the link.
  - jebblue 11y ago
    For a non-signed in session I can see some advantage in improving the swiftness of implementing supporting changes on the server for the client developers. For signed in sessions, you can't get around the database and an API update for it when the client needs some new feature or access so in the signed in case; I think the benefits of this nodejs part would be diminished.
    - madeofpalk 11y ago
      I'm not sure if I quite understand your comment. You can still use authentication with an API... You don't need direct access to the database to do that.

So node.js can replace Java/Tomcat? I guess I'll have to pinch my nose and somehow start liking JavaScript. Typescript looks good, that might make it palatable.

by jebblue 11y ago

So node.js can replace Java/Tomcat? I guess I'll have to pinch my nose and somehow start liking JavaScript. Typescript looks good, that might make it palatable.

eklavya 11y ago

I read the article and don't think they meant this. They wanted server side (selective) rendering and didn't want the hassle of two languages so they went with node.js. quote"Without shared rendering logic we couldn't have realized the potential of rendering only what was necessary on startup and everything else as data became available."

Wintamute 11y ago

I imagine a common architecture for universal apps will be to just use some sort of thin Node.js app to perform the actual app rendering, and have it communicate with a separate API app written in whatever language is most appropriate. Static files could either be served by the Node.js app, or even a different source. And these days ES6/ES7 makes Javascript very palatable indeed. Check it out :-)

madeofpalk 11y ago
That's exactly how you do it :) You have one 'Universal Application', and then you have two small entry points: - server.js is a small (express) server to send a HTTP response to the client (server bootstrapping) - client.js renders a page and the mounts it onto a DOM node. To get around the issues of database access, it makes it a lot easier to put all of that into an API that can be accessed by the server and the client. Here's a very small project I build (and am continuing to build) to learn about this architecture https://github.com/joshhunt/reactapus https://github.com/joshhunt/reactapus
- Wintamute 11y ago
  Aha yes, I like the look of your project ... nice work! I've got something fairly similar going on. https://github.com/madebycomrades/autokitty-react https://github.com/madebycomrades/autokitty-react
  - madeofpalk 11y ago
    Oh that's awesome. I'm still trying to learn and understand the Flux/Redux pattern, my project is essentially rewritten from this https://github.com/erikras/react-redux-universal-hot-example https://github.com/erikras/react-redux-universal-hot-example Your project looks like it will be a very helpful resource for learning. Thanks for the link.
- jebblue 11y ago
  For a non-signed in session I can see some advantage in improving the swiftness of implementing supporting changes on the server for the client developers. For signed in sessions, you can't get around the database and an API update for it when the client needs some new feature or access so in the signed in case; I think the benefits of this nodejs part would be diminished.
  - madeofpalk 11y ago
    I'm not sure if I quite understand your comment. You can still use authentication with an API... You don't need direct access to the database to do that.