The Supabase/ssr package

With many updating frameworks their logic, growing number of 'application builders', and new frameworks being created every day, Supabase has to make a change. They needed to make their auth-helpers-package available for any and all framework.

Before we get into how it works, let's take a look at the reason why

Frameworks changing their core logic to Server Side Rendering

One of the leading frameworks for React, Next.js, has drastically changed how it works in the past year. Going from state management and useEffects for fetchig, to complete server side rendered application.

This doesn't only impact all Next.js users, more and more frameworks are making the move to complete server side. And for good reason: they can charge you for their server! I mean, they get to improve:

Page Load speed

By completely rendering the website on the server and not on the user's computer, you get to manage the speed at which the page loads. Not only that, but also the First Contentful Picture will load much quicker, resulting in better loading speeds

Search Engine Optimzation (SEO)

With faster pages, your technical SEO will be easier to manage as well. No more low res pictures to get the speed of your site or app a good score.

Helps people with slow internet/pc to experience better performance

Even if your PC is as slow as the Stonehedges (ok, maybe not that old), you will be able to render pages at a decent speed. No more limitations by your hardware, but limitations by the hardware of the server.

More accurate user-metrics

On the client, the application can miss a click or two. When using Server Side Rendering, you will always have all user movements registered. This results in more accurate metrics of the usage of your application.

Disadvantages of Server Side Rendering

With all changes come new downsides or disadvantages as well. Firstly, many developers have to relearn what they have learned with their frameworks. On top of that, all code and execution is on the server, which means that a more powerful server needs to run the application or website.

As SSR is relatively new, also existing frameworks will have to update their functionality to be in line with the new standard.

Moving away from supabase/auth-helpers

Initially, Supabase provided a helper package named Supabase/Auth-helpers. This package made it possible to integrate multiple frameworks, such as Next.js, Nuxt, Remix and Sveltekit.

The downside of this package, was that each specific framework required their own setup. Not only was this a huge development burden for the contributors, it also required to be constantly up to date to make sure it worked with all frameworks. Each of these had their own auth helpers package:

• Next.js: @supabase/auth-helpers-nextjs
• React: @supabase/auth-helpers-react
• Remix: @supabase/auth-helpers-remix
• Sveltekit: @supabase/auth-helpers-sveltekit

Examples of auth-helper packages of Supabase

Within the package, for instance, there were many different supabase components. Let's look at the ones available for Next.js and what they do:

1. createMiddlewareClient: Creates a client that is configured to use cookies
2. createPagesBrowserClient: Creates a client component client
3. createServerComponentClient: Creates a server client specifically for components
4. createRouteHandlerClient: Creates a client which can use cookies for API routes

And then there are more for this package alone. For each of the frameworks mentioned before, there are multiple procedures. Lets take a quick look at some of the examples: Remix (createSupabaseClient), React (createContext), Sveltekit (loadStorageAdapter, serverStorageAdapter, supabaseLoadClient, supabaseServerClient).

As you can see, many components, many procedures, and many frameworks.

Consider the workload without the frameworks constantly changing. Then consider when they do change every few weeks. Not as drastically as client > server side rendering, but enough to constantly manage the components.

The creation of Supabase Server Side Rendering package

With the existing packages and the requirements from all the frameworks, Supabase needed to make a change. The goal was to:

• Make it easier to maintain
• Make it work for all frameworks
• Reduce time spent to implement it
• Make it easier to use for developers
• Make it easier to integrate frameworks with Supabase

This also ment that auth-helpers would not be compatible. The first topic was already of the table, as it's getting harder to maintain wth more and more frameworks and possible integrations with Supabase.

The Supabase/ssr components

Let's take a look at how Supabase tries to solve all of the above, while making it possible to create such as package (sounds seriously hard to come up with such a good solution).

Supabase createServerClient

This components is both easy to understand, and properly named. It does exactly what is says. It creates a Client with Supabase, that uses a server connection. The function takes two parameters and has an options object:

• Supabase URL
• Supabase Anon Key
• Options: Get cookies, set cookies and remove cookies

If you are using this client from a page, you would only need the Get part. If you use it as a route handler or middleware client, you also add the set and the remove options.

createServerClient for Server Side Rendered page

If you were to use this client for a page, it would look something like the code below:

You see that the function takes two parameters and has the cookies setup. Storing the client in a variable, you can then extract the information from Supabase. We add the cookieStore based on the cookies, to make sure we can verify if the user is authenticated, who the user is and retrieve additional header information such as the JWT.

createServerClient for Middleware and Routes

While the above code shows all of the page information, for Middleware and Routes we will just show the function, as the other code is irrelevant for what we want to explain right now. As I mentioned, the SSR package of Supabase makes it easy for all frameworks to be integrated.

Supabase createBrowserClient

Just like the Server component, the Browser component does exactly what it says. It will create a client from the users Browser (Chrome, Firefox, Safari, etc.).

While the Server Client has cookies, the component does not, as cookies can't be imported in a "use client" page in Next.js. As such, the function for createBrowserClient only take in two parameters:

• Supabase URL
• Supabase Anon Key

Below is an example of a createBrowserClient of the Supabase/ssr package:

With just this code, you will be able to retrieve data from Supabase, as long as you have a session.

Supabase/ssr as a package

Concluding what we see so far, we can definitely say the @supabase/ssr package is a step in the right direction. Not in the last place, because the number of components went from 20 to 2, but also because it is useable across all supported frameworks.

To be able to keep it so simple, I'm sure that Supabase will have a challenge keeping it this simple, especially as more and more frameworks are integrated.

Looking to implement the supabase/srr package?

We created free to use templates, for Next.js and the Supabase/ssr package. You can pick it up here: Free Templates