Enabling "true" SSR for Clerk components

[colinclerk]

Background

The architecture for Clerk's components was selected over 2 years ago when SSR was still uncommon. Over time, it's become clear that SSR will play a bigger role in the future than we anticipated.

Since launching our Remix package in particular, we've heard from several customers who are surprised that Clerk's components render client-side instead of server-side.

Current architecture

Currently, our <SignIn/> component only renders a placeholder <div>. When Clerk loads on the client, we actually create a second instance of React and use createPortal to render into that placeholder.

The intent of this architecture was to enable Clerk to work with non-React libraries... just pass us a <div> and we'll render inside. At present, the only two options we have are Vanilla JS and React.

Goal

We'd like to enable true SSR for our React customers. Meaning, if a user visits/sign-in/factor-two, the dom for the second factor collection page should render directly from the server.

We'd still like the ability for Vanilla JS (and therefore any library) to use our components from the client-side, but we are not concerned with the ability of other libraries to implement SSR. This may become a concern in the future, but it is not one we are worried about today.

What about RSC? (React Server Components)

In general, our mindset around server components has been to "wait and see" how frameworks (Next.js, Remix, Gatsby, etc) approach them.

We are eager for this change since our DX will be easier when loading is packaged inside our components instead of facilitated through out-of-band loaders (e.g. Next.js getServerSideProps, Remix loaders/actions).

Known challenges

"client" data must be made available to our SDKs

Currently, Clerk only makes "session" data available to our server-side SDKs, while "client" data is only accessible from the client.

While this is enough to render our <UserProfile/> and <UserButton/> components from the server, it is not enough to render <SignUp/> or <SignIn/>.

Components will need access to the current path

Currently, our components determine the current path by inspecting window.location.href. We will need to revise this so the path can be retrieved from the request object (or through framework helpers like useRouter).

Hash routing does not work with server-side rendering

By default, Clerk's components use a "hash" routing strategy (/sign-in#/factor-two instead of /sign-in/factor-two). This strategy cannot work with SSR because the hash is not sent with the request object.

This is more an acknowledgement than a challenge - most prefer path routing anyhow.

SSR will amplify the desire to revisit OAuth "transfer" callbacks

Currently, when an OAuth "sign in" must be transferred to a "sign up", it is handled client-side. Because there is significant backend overhead associated with this change, it is possible the first version of SSR for Clerk components will still need to handle this transfer on the client-side.

[dvargas92495]

YES! Gonna do another read through tomorrow, but some initial thoughts:

On board with the focus on React over other s libraries/frameworks. It could even be helpful to start with one (Remix or Next) and then take the step back to see how it could be reworked to apply to the rest of the SSR frameworks.

I've not done much research on RSC, but it could be a good idea to proceed without considering them. The Remix team in particular is taking the position that it's currently two times slower than Remix and at best it will only ever be an implementation detail: https://remix.run/blog/react-server-components.

The last sentence in the first known challenge seems like it's missing some words, making it harder to parse. Looks like words formatted with backticks were stripped.

Defaulting to using the node Request object could be a good approach for accessing current path, as it's a standard api (and one Remix already uses).

Definitely prefer path routing over hash. In addition, would love for there to be a way for Clerk to just use whatever router the host framework is using instead of relying on its own router.

[dvargas92495]

I started doing some hacking on the Clerk Remix Starter and noted my observations there on the PR: clerk/remix-auth-starter#1

It doesn't work yet, but it helped illuminate to me what some of the challenges to solve would be

[collinversluis]

+1 for SSR for clerk. I immediately took a step back when I realized putting <SignedIn> around my content made it client side. If there's any work around so far I would love to know it.

[benkovy]

I was able to get a non remix, non nextjs, server side rendered react app going with the @clerk/clerk-react and @clerk/backend packages. Pretty smooth sailing using the remix package as a reference. The @clerk/clerk-react package does not advertise it but it can be given an initial state to populate the auth context. Those control components (<SignedIn />, etc...) just check the context to see if there is a userId if there is not, then they return null and if there is they render their children.

Just as an aside. They way Clerk has set up their JS ecosystem is second to none. The composability of these packages is fantastic. Kudos to the team

[aerojeyenth]

+1 server side rendering. And also please kindly support Edge runtimes like Cloudflare workers.

[mikey0000]

Another issue with the hashing is it breaks on using hash router, unless there is some workaround?
[EDIT] managed to get it to work using memory router.

[dragos99]

It's been over 2 years. Any updates here?

[thatguyinabeanie]

update?