Hi, version 2.0.0 was published a few days ago, allowing to have multiple renderers. The number of renderers is configurable.

Take a look at the changelog for more details:

I have been using a slight variant of this for full page rendering of react apps and its working great. Almost entirely replacing eex templates and relying solely on server side rendered + hydrated react on the client. This pattern is a bit against the grain, and rather than attempting to avoid javascript within Phoenix front-ends, it embraces it!

I have not really built much using eex templates, and generally find myself reaching for react when building decently complex UIs in Phoenix apps. I do have a javascript background, more specifically Meteor, so I suppose it is just what I am more familiar with.

I think for people coming from node, or react backgrounds, this pattern would help ease them into using phoenix on the back-end, and maybe help grow the community!

Wow this is very cool, thanks for open sourcing it. I’ve been experimenting with different frontend/backend architectures for a couple of months now leveraging React and lately have been using Next.js to do SSR talking to Phoenix backend using Apollo/Absinthe. It all works (generally) but adds a heavy fast-moving dependency and some degree of complexity.

It might be cleaner/simpler to use this library instead. Two questions:

• I realize it’s very new and I was only able to find one example app on GH using it (https://github.com/Harleymckee/reactin). Are you using it in dev/prod on some closed-source apps already or is it experimental?
• I think it uses a GenServer to control a single spawned long-running node instance that does all the rendering. Have you done load testing on it? I think (not sure) each render request blocks all other render requests and not sure what happens if node crashes for a given request. Maybe using poolboy (or something) could make it more performant/resilient… have you considered?

Thanks again!

Really impressed with this plugin Bryan, thanks for open sourcing it. I forked it and got it working with Svelte.js.. A suggestion I have is to abstract away the elixir logic from the React stuff (and maybe call it 'elixir_ssr_renderer) to make it easier to adapt it to different JS frameworks.

Thanks! My personal aim was to make it so it didn’t need a node webserver running and that it could be supervised, started, and stopped in an elixir app. I do like Next.js a lot actually. I just wanted to reduce the complexity here. The beauty with this is you can use it for full page renders or just sprinkling in react components.

It’s still new and I think you found my coworker’s test app, haha. We aren’t using it in prod yet, but since we do a lot of react here, it is going to be soon enough.

I haven’t done any load testing on it. You are right that if it’s only one process it will block other requests. We do want to make it have more. I haven’t figured out the mechanism but maybe poolboy is an option. Whatever happens, I want it to be configurable.