React Renderer Process

[tmkontra]

Hi @silviogutierrez, I really love the design of reactivated and am trying to fully understand how it works. I think I have a surface-level understanding of the renderer: a ReactDOMServer fronted by a nodejs http server process, which is spawned by the django process.

The "API Protocol" for that ReactDOMServer appears to be a json {context, props} object.

So far, I had a few questions I was hoping you might be able to answer:

1. The renderer_process process does not appear to be "supervised". If it crashes, will the django process attempt to communicate with the now-non-existent server, and encounter unexpected errors (i.e. a full restart of the django server will be required)?
2. Is it imperative to run the renderer process as a subprocess? Would there be any gain from requiring it to be externally supervised?
3. Similarly, would there be any gain to support a "worker farm" of multiple renderer processes? I suppose it would depend on the relative performance of the django server and the react server -- in a load balanced django deployment, each django process could have its own react process anyway.
4. Finally, are there any improvements or tasks you have in mind with regards to the Javascript side of things -- if so I would love to help. I have more experience with Python, so I would be excited to broaden my Javascript horizons.

Thank you!

[silviogutierrez]

Hi Tyler,

These are great questions. Point by point below.

1. So, reactivated originally started with a separate render process. It listened on a port and could be hosted in another machine even. This made it more scalable but needless complicated setup. The core mission of the library is to make it trivial to deploy Django+React. Not just locally, but on a server. And this is best done with a single Docker image. Docker really doesn't like multiprocess entry points. But my business, https://www.joyapp.com, ran for years on a separate renderer. This involved Kubernetes running two different pods. I've now switched over to same-process / non supervised and in a year or so, none of my projects have had a single crash.
2. It isn't imperative. This is purely for developer experience and ease of deployment. In fact, you can see remnants of the separate-process code in renderer.py. It even checks if an environment variable is already set, and if so, will just forward the request to it.
3. So I actually looked into worker farms etc. Turns out, rendering React on the server is slow. Real slow. And synchronous. So tying each Django request handler to a single React handler made sense. There may be speed differences, but generally, you can just scale up the Django processes (each with their own React process) and you should be fine.
4. I'll keep this in mind, see below for a python part — even though you asked for JS. Also, look through the other discussions and voice your opinion. There are a lot of design decisions needed.

More on decoupling the Django process and the React process

This is actually really close. In fact, it also affects Windows support: #188.
Already, an environment variable is respected, so if you set that when starting the Django process, reactivated will just pass on the request to whatever is in there. And you can even start the render manually with node node_modules/reactivated/build.renderer.js (for local development) with a SOCKET_PATH env variable set to 127.0.0.1 and a port. See renderer.tsx in the reactivated package.

All that really needs to happen is to change the renderer.py code to not force a unix socket and instead detect the renderer target:

In renderer.py, currently:

    response = session.post(f"http+unix://{socket}", headers=headers, data=data)

You can hack it together manually and basically start the renderer separately in another window / tmux tab. Then maybe we can look into promoting this concept for those that want it. I don't see a ton of value for most deployments, but at least we'd get Windows support.