RFC: Server-side rendering for static pages

[ZhangYiJiang]

I believe it should be possible to make NUSMods SSR without too much pain. The main benefit of this is that the static like FAQ and semi-static pages like the module/venue pages should load much faster, and SEO on those pages will also be much better. The additional server load will be mitigated by adding a caching layer in front of the renderer.

The key steps are to making SSR work are (reference: https://medium.freecodecamp.org/demystifying-reacts-server-side-render-de335d408fe4)

• Cordon off components that cannot be server-side rendered using a HoC which only renders them on componentDidMount. Sample code: https://gist.github.com/fdecampredon/037522907cc79183feef83595b9892ae
• Create server that renders <AppShell> with a server side version of the Redux store and React router. This is relatively simple - the code used in the article above is actually pretty close to what we might do.
• Add server side code to fulfill the data requirements of the components.
• Update the nginx config as well as the local dev server to serve HTML from this server instead. We'll probably whitelist specific routes to begin with as we make the site SSR compatible bit by bit
• Add in caching as well as some sort of cache busting mechanism for when the scraper is updated as well as on deploy

Open questions

• The example ships the entire Redux state over, which would mean loading up ~300-500kb of JSON in the HTML - not entirely sure that's a good idea.
• Server side data fetching is messy - the article just put the code inside the component, but that would mean the server side code will also get bundled with the rest of the component and shipped to the client. This is not ideal because it bloats up the component and also makes separation of concerns harder.
• The above would be easier if we have a proper data layer. Maybe GraphQL would make this easier since we can just query the GraphQL server from the web server

[ZhangYiJiang]

Progress on this issue can be tracked on the we-ssr-now branch. It's pretty interesting all of the technical issues I've faced so far

• We used Webpack to rewrite imports, which means we can't just use babel-node to run the SSR server in development. Webpack hot reload is possible in theory, but I'd rather stab myself in the eye then spend another minute writing Webpack config, which leaves us with waiting for a full build to get runnable code. Fortunately Jest is configured to rewrite routes, so now I've written some unit tests and am using those instead to fix bugs

• The DOM cannot be touched in React now. At all. Every window and navigator used should be looked over carefully. Also Portals and ErrorBoundary are completely unsupported in SSR. Oh, and SSR is completely synchronous, so any setTimeout or other async operation will fail miserably.

• The HTML template is surprisingly painful. We want to use the output from Webpack HTML plugin, since that has all of the <script> and <link> tags which link to our compiled assets, but we also need to inject our SSR rendered HTML. Also, React Helmet works in the browser via direct DOM manipulation, which obviously does not work here, so instead it just outputs a bunch of strings and expects us to put it into the correct place in the template.

  I think what we can do is to use Webpack HTML plugin to create a template, then inject default values to create the static index.html and load that template in the SSR server to inject the Helmet HTML snippets

• 404 pages renders correctly, but to actually return the correct status code (as well as for 302 redirects) we need to use the context prop passed down through React Router, with each component connected to the router poking at the object

• Data fetching is problematic as expected. React Router suggests static routing, but that does mean routing code is going to be duplicated on both client and server

• Redux Persist has side effect when importing storage. This was the same issue we ran into the last time. Setting up a flag to only initialize storage on SSR isn't enough because the reducers are initialized on import, and the env var isn't set in the tests in time, so I just mocked it again

Also, on an architecture level I believe implementing SSR will cause the app to be more monolithic. This is because the data layer can now be shared between server and client. Imagine if we have a GraphQL store - the SSR server will then just query it locally to fetch the data. This is pretty neat if you think about it.

[li-kai]

Aside from the DOM and async stuff, the rest of the issues can be solved with webpack on the server side.

• The HTML template will need to be either a string or yet another react component, which will be injected with react helmet's ssr command.
• I don't get the data fetching part, React Router works on ssr.
• Redux Persist is indeed problematic. That codebase I'm interning on uses window._data or something to "hydrate" graphql data, which is pretty cool indeed.

Long ago I actually had an entire SSR code base that I learned over at Carousell, it was intended to be a learning thing so it was private. Just made it public: react-prod-learn. Ultimately I didn't go with SSR because of the problems you raised and we don't actually see much benefit aside from performance (which comes with a pretty heavy cost).

[ZhangYiJiang]

The previous comment is outdated. I've fixed/hacked around most of these issues, and have found some new ones

• The problem is we already have a HTML template that we use with Webpack HTML plugin. I need to inject Helmet's HTML into the result from that compilation, so in the end I created a template that uses two different templating language. Lodash's ES6 style ${ } is used by Webpack HTML plugin, while Mustache {{ }} is used by the SSR https://github.com/nusmodifications/nusmods/blob/we-ssr-now/www/src/index.html. To make sure the Mustache templates don't leak into the HTML served by Webpack Dev Server, I created a tiny Webpack plugin that strips Mustache templates only in development https://github.com/nusmodifications/nusmods/blob/we-ssr-now/www/webpack/webpack.parts.js#L326
• React Router works on server side, but all it does is display the correct components given the path. The components themselves have data requirements. https://dev-blog.apollodata.com/how-server-side-rendering-works-with-react-apollo-20f31b0c7348 goes into detail how you might do this with GraphQL. In our case I create a static list of routes that have data requirements, then used a function that turns files into Redux action to get the data to the components https://github.com/nusmodifications/nusmods/blob/we-ssr-now/www/src/js/ssr/data.js#L25. The entire Redux state is shipped off as window.REDUX_STATE and is passed into the Redux store as initial state https://github.com/nusmodifications/nusmods/blob/we-ssr-now/www/src/js/main.js#L20
• Redux Persist's problem is just that it keeps printing the error to console. It does have a memory fallback, which is perfectly fine for SSR.