SSR vs. CSR

[matt-d-webb]

An appropriate evaluation of server-side rendering (SSR) vs client-side rendering (CSR) should be written up in the context of modular's enterprise scale (unified tool chain) aspirations.

As it stands, this project has adopted create-react-app (CRA) which is client-side rendered as its default view / app starter kit.

However, as is becoming increasingly popular through the work of Next.js, evidence shows this can out perform CRA across many significant performance categories see ref. As such, this is something that needs to be evaluated for potentially further adoption.

I would therefore like to consider the following questions:

1. Should modular provide both options 'out-of-the-box'? i.e., using CRA & Next.js

   • What additional overhead does this bring?
   • How do we help direct teams to select the correct approach?

2. Should modular switch to solely SSR, if so, what drawbacks or limitations does this introduce?

   • Does this make bespoke UI component libraries more difficult to integrate?
   • Does this introduce additional friction / further learning to the quick 'get started' development flow?

I think there are perhaps many questions on this topic but would like to collate a set of references and opinions to ensure the decisions made in this project are thoroughly researched and documented.

[NMinhNguyen]

Should modular switch to solely SSR, if so, what drawbacks or limitations does this introduce?

• Does this make bespoke UI component libraries more difficult to integrate?

Related to this is #121 (comment) that I made which shows how to build a traditional SPA (with client-side routing not using Next.js's router but React Router) using Next.js. It's also possible to use https://nextjs.org/docs/advanced-features/dynamic-import#with-no-ssr to avoid loading a library that doesn't work well with SSR.

[LukeSheard]

Yeah - I agree with this only for some other reasons. Authentication being the main one on my mind, a lot of UIs need to be protected for various reasons and so it would be good to tie these things together and expose some kind of server framework we could use out of the box for these common use cases.

[threepointone]

It's trivial to make any kind of package inside modular, and folks inside jpm are already using them to make servers and api proxies and such. Folks who want to do anything custom are free to do so, there's nothing in modular that would block them. Use next.js, express, whatever; we don't stop you, but we don't provide support for the solutions themselves. (We can keep reevaulating to see if we can do anything better in terms of foundational pieces, of course. For example, the upcoming modular package command assumes browser packaging, we may want to provide an opt-out of that.) This should our primary recommended thing for now.

While it would be tempting to bless a server side framework (express/fastify/whatever), I feel that the ground is shifting in terms of how folks are writing servers. Specifically, there's movement away from deploying on to raw metal servers; the so called 'serverless' (i.e. managed environments) revolution is real. It's not even clear that node.js will be the base solution here, providers like cloudflare and fastly have proven that plain javascript/wasm environments can beat every aws lambda benchmark. We should take our time on this decision.

We don't have a direct usecase for server rendered pages right now inside jp morgan, and I'd be wary of taking on the whole of nextjs only for some of its nicer dx features. (To clarify, we currently choose solutions for long running applications whith heavy interactivity, not for time-to-first-interaction or SEO. This might change, but isn't our primary thing at the moment.) That said, it's not hard to use next.js inside a modular environment; since their configuration is extensible, as long as someone makes changes similar to what we do in our craco config, they can get the same experience and guarantees that we already provide (like jsx working across workspaces, etc).

But further, the nature of server rendering is going to change dramatically with concurrent mode/react flight, so I wouldn't want us to buy into current strategies anyway. In that scenario, we can get even better performance and dx experiences than what's available today. We shouldn't commit to something that'll be hard to mvoe away from, with no clear current benefit for our usecase. We should keep an eye on it.

To summarise, let's not take any decisions just yet, but keep evaluating as information presents itself.

(I'll leave it up to you whether you want to keep this issue open.)

[NMinhNguyen]

'serverless'

That's actually how Next.js' API routes work, and they can be deployed to serverless (zero config when deploying to Vercel, but there's also community efforts such as https://github.com/serverless-nextjs/serverless-next.js for other cloud providers such as AWS).

But further, the nature of server rendering is going to change dramatically with concurrent mode/react flight, so I wouldn't want us to buy into current strategies anyway. In that scenario, we can get even better performance and dx experiences than what's available today. We shouldn't commit to something that'll be hard to mvoe away from, with no clear current benefit for our usecase. We should keep an eye on it.

I don't think by picking Next.js you're necessarily buying into any particular SSR strategy as the way Next.js does SSR is abstracted away from you as an end user, and they're always re-evaluating their approach and making changes to be compatible with latest versions of React. There are several benefits to Next.js (as outlined in Tanner's gist), not least the ability to have a unified (i.e. not having to run the server in a separate process) experience when writing full-stack apps (i.e. not having to configure TypeScript or nodemon or whatever for the server code), webpack 5 (admittedly, a somewhat weaker argument because it's probably only a matter of time before CRA catches up but still), and as mentioned previously, serverless.

[matt-d-webb]

No concrete actions to take on this topic as yet so closing. Will reopen / create new, if an actionable introduction for SSR is required.