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.
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.
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