I put nginx in front and a location /static/ block with a try_files directive that first tries to serve static files from Django (those collected with python manage.py collectstatic) and falls back to serve files that a gulp task generated.

To serve different assets in dev and prod I let gulp generate a manifest and have a custom template tag in Django that expands to different paths depending on settings.DEBUG:

  {% my_static 'css/all.css' %}

expands to either /static/css/all.css or something like /static/css/all.min.abcd1234.css.

If nginx is serving a minified, hashed path it adds a Cache-Control: max-age=31556926 header to the response.

I'm in the planning phase of porting a large C# application's frontend to React on Node (for isomorphism).

Basically we'll have our main application server (in this case, .net mvc api, but think django-rest-framework) talk to a node server as well as the client, with the same REST api. The plus is very real separation of concerns (django does all data handling, business logic; javascript does all UI). The downside is having two server stacks.

FWIW, I'm planning to use nuclear-js[1] for flux. And we're considering porting our .net code to django.

[1] https://github.com/optimizely/nuclear-js

I've not done it myself (I've looked but it was a small project so I just ignored server side rendering and used django-compressor for convienience's sake) but you should definitely check https://github.com/markfinger/python-react if you haven't already

Simplest solution I've found is to run the devserver in a gulp task instead of using any of the pipeline/compressor projects.

My current app stack is a React+fluxxor frontend consuming a django-rest-framework driven API. The frontend/backend live in the same repo for simplicity, but are otherwise separate projects in their own subpaths that share nothing.

For deployment, I have the root path serve up the client, while the API is on its own subdomain.