Just added release functionality to the repo above, and published it to a 5$ Linode instance to test it out.
Check it out here: https://nomrah.dev
I left the dashboard open in production to let people see that too…
The app is behind HAproxy, so IPs of users are not public. Is that enough? Or should i be worried about something else when leaving the dashboard public?
@harmon25 Looks great! is this the same model that NextJS et al use? From looking through the code here, the phoenix side will render an empty html page and then render the <ServerContainer /> component which contains the app, hyrdated with data passed from the server. This is then ‘hydrated’ on the client side using the props passed from the server - is this all correct?
My question is then, when is the <ClientContainer /> rendered?
Also once that initial page is rendered, is it pretty much from then on the same as an SPA? E.g. routing will all take place client side and no more SSR will occur?
I’m guessing the main benefit here (I usually do SPA + GQL API Phoenix) is that it eliminates the need for the intial page fetch from CDN (e.g. netlify) → render → fetch data from api (show loading states) → then show data
and rather:
page loads directly from server → initial data passed to react component → component rendered already with data ?
Just want to make sure I understand this right - so whilst the actual content is no longer served as a single static JS Bundle (typically to a CDN close to the user), it should be faster because it eliminates the need for CDN call + API call (and most likely CORS) and can instead can all be delivered in a single round trip?
Hi @Harrisonl,
Thanks for checking it out!
Yea it is pretty similar to NextJS, but NextJS is IMO better suited for something fully static, and served entirely from CDN, or maybe the new serverless idea they are pushing. But deploying NextJS as part of an Express application or the like is not recommended, because of the synchronous rendering of React components to a string in Node.
Thing is, I need/want to reach down to the underlying HTTP constructs for security purposes, like cookies, CSRF, redirects, server side auth etc..
This pattern lets me leverage Phoenix/Plug and its great patterns and structure for managing HTTP/API concerns, and delegating the UI/UX to server rendered + client hydrated React. Which despite its pitfalls, has enormous engineering effort/community behind it…
I currently work on a team that has too much React experience to toss it away. As much as I love the idea of LiveView; I also appreciate the inherent separation between front and back-end code the SPA pattern benefits from, and how it allows for teams that can specialize in say React or Elixir.
To directly answer the questions:
<ClientContainer /> is used to hydrate React on the client. This is necessary because certain React provider components, namely react-routers StaticRouter vs BrowserRouter.
The StaticRouter is used for server rendering and pretty much just takes a location(path) as a prop, and figures out what page of the React app to render. The linked example is using a wildcard phoenix route,to pass the conn.request_path into the ServerContainer so it knows what page to render.
The ClientContainer uses BrowserRouter, which is actually hooked up to the browsers push state history stuff and grabs its location from the URL bar.
So yes, the component is rendered on the server with the data you provide it.
During rendering the component on the server, it could also do some data fetching from within the servers node environment.
It is still possible to deliver the app.js, and app.css webpack bundles over CDN, just not the rendered HTML page. And yes, the app can be bootstrapped entirely on the server, removing the need for a initial API call to understand who is on the page or for critical data for example.
The rendered HTML could be cached in Elixir - but depending on the state it is hydrated with - e.g private user information. It might not be a good idea to be naively caching it, it does however have a pretty substantial performance improvement if it was necessary.
Happy to answer any more questions!
Oh, and to clarify phoenix actually returns the rendered react component - so not an empty html page. You can verify this when looking at the data over the network, or the initial page load.
Thanks for super detailed reply! That definitely cleared it up.
I’m in a very similar boat RE team with a lot of react experience and am actually a big fan of react itself and don’t want to introduce a completely new technology (LiveView) until it’s more battle-tested with a bigger eco-system behind it. Although I do want to find some ways to increase performance and remove some of the pain’s associated with SPA + API’s for a bit faster dev cycle, hence the digging into SSR react.
Just the last question I had is once the server has loaded the app and rendered the front end, is it for all intents and purposes an SPA? E.g. client side routing and not every route goes through the whole server side rendered flow again. Sorry for the basic questions - never actually done SSR react, always been SPA so some of this stuff is quite new to me!
Yes exactly!
Once the client is hydrated, and you are using BrowserRouter or the like, React just picks up from there.
This works pretty well with the phoenix wildcard, because you can still refresh the page and trigger the server render. But a regular user navigating via react router links etc will be back in full spa land pretty much. You can see this by navigating between the / and /profile routes on the demo: https://nomrah.dev/
@harmon25 Thanks for all the answers! Trying this out on a sideproject and ran into a few issues (mainly with console.log but saw your comment thread on the original repo and that worked a charm) - just wondering if you have any ideas on using WebSockets in the app? Since WebSocket is only included in the client side I am getting an Cannot read property 'WebSocket' of undefined which makes sense. I’m not so familiar with the hyrdation flow, but would it be trivial to say delay the execution of the webhook logic until the client side hydration begins?
I actually just responded in the original repo with some thoughts on that: Some Questions + running in a release/production · Issue #44 · revelrylabs/elixir_react_render · GitHub
Here is an example of how i was able to get the node ssr process to connect back to the phoenix socket.
It only required an isomorphic WebSocket in the right place for phoenix to know how to instantiate the phoenix channel socket.
In looking closer at the phoenix source it looks like WebSocket could be passed into the phoenix socket constructor as the transport option - rather than hacking global like i did 
To more directly answer your question:
I think a conscious decision should be made on what data you want to have available for the SSR, and thus rendered on the server vs the data that will be fetched async once the client bootstraps.
I would also separate out the phoenix socket/channel logic from the content being server rendered via some indirection through redux or something similar. This would allow you to not include that client code when you SSR, and maybe just hydrate redux state or something on the server, and not have to worry about how it got there.
In your app.js file is where you have the socket code, and maybe add extra redux middleware to manage channel data when running in the browser vs on the the static server render.
Can’t seem to edit my post, but I did find a solution. The above bug occurs because it the phoenix.js library attempts to call location which I am assuming is not defined in the node runtime and is browser specific.
You can replicate this @harmon25 by adding a test channel in your app, and then importing the socket.js file in your index page.
The solution, is quite simple, but basically you need to change:
const socket = new Socket("/socket", {});
let socket = new Socket("ws://localhost:4000/socket", {});
Which then bypasses the location calls and the app will compile correctly.
My only concern is that this will be an ongoing theme where the react app expects there to be a browser runtime present (e.g. through libraries etc.) and cause these issues.
Started writing this in the AM, and then got busy with work…
If you are not using redux or some global state thing, the right approach would be a context in the ClientContainer.
Here is a gist of what that might look like.
Not tested, but should work.
You could combine the above with a ChannelContext that was responsible for managing and communicating the channel data/status to child components.
This should be imported on the client container, or maybe app.js, but not in components down the tree that end up on the server render. Which is the problem I think you are having… this websocket stuff will not work in the context of node without some help - like the channel logger I linked above.
It can be done for sure - but if you have an authenticated socket, that authentication would need to be considered when connected back to localhost from the server render node process..
Take a look at the kinda hoops are required for hydrating state in apollo for example:
As you point out, this is a bit challenging if you are doing stuff with sockets all over your tree..this is why i suggest very carefully locating the socket related code - and you probably will need to use something like redux to hook it up with react properly - or else you will have re-renders all over the place…