Our servers behave just like a browser, so it fetches the code that starts the rendering, and instead of showing the results to the user, it transfers it to you.
We do this for 2 main reasons:
- Web crawlers — without SSR you won't have your results in any search engines
- Performance — we can render pages faster
But it's always the same code that's used for the SSR and for the rendering on the client.
To go into a bit more detail:
We generate the SSR HTML on the server for every request that comes in with Accept-Header text/html, which is most like the first “real” request from the browser to our server. We'll then return the pre-rendered HTML and the application. React will then hydrate these results and replace them with the local browser rendered versions.
If the SSR for some reason fails, we will still provide the application and an HTTP status code 503 (so that searchbots won’t take these results). The application will then be initialized and React will take care of rendering the components.
As we have a PWA all other requests will then be sent with Accept-Header application/JSON from the inside of the application and will therefore return just JSON which then re-renders the necessary parts.
Currently, we have no caching there in place but also do a full-cycle instead for the HTML requests.
So, what we do in the backend is send the request result including the data and Frontastic componentFrontastic component - A customizable building block that's used together with other components to create a commerce site. Known as `tastic` for short in code. configuration to our SSR server, which is a small NodeJS application. And there we use 'react-dom/server' to render the HTML.
Also, translations would be available as we send the context we have to our SSR, which also includes the current locale the user uses.
Updated 4 months ago