Node and React Isomorphic Rendering Architecture

Question

So I understand the fundamentals of isomorphic rendering with React / Node, but I'm confused on how I would fit Apache or NGINX into my landscape.

Typically, with a client-side page I would just serve the static content from Apache or NGINX and the client-side page would make AJAX calls (which are reverse proxied through Apache or NGINX) to Node. Node would serve up the data and the page would change accordingly.

Looking at an isomorphic page with React, the page is initially rendered on the Node server and changes are served up to the client from the server. Can I still use Apache or NGINX to load balance and reverse proxy my requests?

As an example, I would have one Node instance serving my API and one Node instance for rendering React and serving it to the client. In this example, could I load balance, reverse proxy my calls, and serve my .js and .css bundles from Apache/NGINX? In this example the user would access www.example.com/ - that would first go to the Apache/NGINX which would reverse proxy the call to the Node server which would render the page and serve it up to the client. Then, on the page the client would click some button and access www.example.com/api/test and that would also go to Apache/NGINX and reverse proxy over to the second Node instance, which would server the data back to the client. Or should that button click go back to the first Node instance (where rendering takes place) and that Node instance calls the second Node instance to get the data, renders the new piece, and serves it back to the client?

Basically I want an isomorphic app with all the benefits of having Apache or NGINX in front of my Node servers. Is that possible and/or best practice? If not, what is the ideal landscape for an isomorphic app so that I can still maintain all the benefits of Apache or NGINX as my entry point to my webapp?

Answer 1

Yes, that should all work fine. The React/Node server just renders html, and is reverse-proxy-able like any other html backend.

And yes, using a reverse-proxy/loadbalancer in front of your servers is a great idea, if you're planning on running something at scale.