The biggest announcement from Next.js Conf 2022 was the release of Next.js 13, which introduces a collection of improvements, most exciting of which is Server Components. The combination of Server Components and Suspense allow for a more streamlined, reimagined way to fetch and cache data in Next.js applications. This provides excellent DX improvements — such as async components — and aligns the Next framework even closer with the future of React.

This article is going to look at how we can use these brand new async components to simplify fetching and caching data from Supabase. We will look all things auth in a separate article. Check out the Server Components example in the Auth Helpers repo if you just can't wait!

To learn more about any of the concepts covered in this article, check out the Next.js beta docs.

A good distinction to understand at this point, is that Next.js 13 is stable and ready for production, however, the app directory is still in beta and likely to change. This article will be focusing on the app directory, Server Components and Suspense so let's get experimental!

For an example of the code covered in this tutorial, check out this repo.

If you prefer video, check out our recent live stream where we stepped through a similar example.

Let’s get started by creating a brand new Next.js 13 app using the create-next-app package:

Now we can run our app in development mode:

And navigate to http://localhost:3000.

This should look pretty familiar, and scanning the folder structure for the app, it should look almost identical to Next.js 12, but with a new folder called app. This is where the new data fetching and caching magic takes place. 🪄

Each folder within the app directory represents a route in our application. Each folder must have a page component, which is rendered when the user navigates to the route, and optional layout, loading and error components.

Learn more about Page, Layout, Loading and Error components in the Next.js beta docs.

Before we jump into fetching data, we need some data to fetch. Let’s create a new Supabase project.

Once your instance is up and running, head over to the SQL Editor, paste in the following snippet and click RUN.

This will create a table called posts, and populate it with some example data.

Let’s install the supabase-js library to fetch our posts.

And add a .env.local file with the following environment variables:

The values for these can be found in your project’s API settings.

Lastly, we need to create a Supabase client. Create a file at utils/supabase.ts with the following content:

For automatically adding types to the Supabase client, check out how to generate types.

Okay, let’s look at some different data fetching and caching strategies.

Static

By default any page component in the app folder is a Server Component, and its data is fetched and cached by Next.js every time we build a new version of our application. This is equivalent to exporting a getStaticProps function from a component in the pages directory.

Let’s create a new file at app/static/page.tsx and populate with the following:

Server Components support async/await by default, and suspend the rendering of the component until the data has been fetched. This means we don’t need to handle error or loading states in our component, keeping our rendering logic clean.

To learn more about displaying loading and error states, check out the documentation.

Let’s modify this component to render out a collection of <Link /> components, that navigate to a dedicated page for each post.

Since we are only using id and title in our component, we can scope our query down to only return these two columns for each post.

Let’s create a dynamic route to handle displaying an individual post. Create a new file at app/static/[id]/page.tsx and populate with the following:

Currently, this page is generated on-demand and then cached. This means the first person who visits the page will need to wait for the server to get the post data from Supabase. This won’t take long at all, because Supabase is Supa awesome! But, we can still make this slightly more efficient by telling Next.js a finite collection of paths that we want to generate at build time.

We do this by exporting out a generateStaticParams function from our dynamic page.

This is similar to getStaticPaths in a pages component. Learn more here.

The full component should look something like this:

Awesome! We now have a Supa snappy blog! The user never needs to wait for data to be fetched. All pages are statically generated at build time, and cached at CDN nodes close to our users! 🎉

Unfortunately, this means any changes we make in Supabase — adding, updating or deleting posts etc — will not be reflected in our blog. If we want to refresh this data on a regular basis, we need to tell Next.js when to revalidate.

Static with Revalidation

By exporting a revalidate variable from our component, we can specify how many seconds we consider this data to be “fresh”.

This is similar to returning a revalidate key from the getStaticProps function in a component from the pages directory.

So, for 60 seconds Next.js will continue to respond with the static version of our page. After 60 seconds, it will fetch fresh data from Supabase and generate a new static page. However, there is no downtime while this happens, as the previous static page will continue to be served until the “fresh” one has been successfully generated.

The Posts component should now look like this:

And the Post component should look like this:

We now get all the benefits of static — users not waiting around while data is fetched at request time — but we also get the benefits of dynamic data, as it is being refreshed on a regular basis.

Very cool! 😎

Dynamic

If we want fresh data to be fetched on every single request, we can simply set our revalidate value to 0.

Posts Component

Single Post Component

This is similar to exporting a getServerSideProps function from a component in the pages directory.

All this server stuff is great, but what if you want to use Supabase client-side? 🤔

Client-side

There are many use-cases where you need to use Supabase client-side:

1. Authentication

   Supabase Auth does a bunch of stuff behind the scenes — handling 3rd party OAuth flows, for example. This will break if you try to sign users in and out on the server.

2. Realtime

   Supabase manages the awesome power of websockets on your behalf — something that is not yet solved in this serverless world.

3. You prefer it

   There is nothing wrong with this! You do you!

To use Supabase client-side, we need to tell Next.js that this is a Client Component. We do this by specifying the use client directive at the top of our component. This opts into a similar flow to the pages directory — the component is rendered on the server and hydrated client-side.

The React team is working on an awesome new hook called "use", which will drastically simplify fetching data client-side, but for now, we still need to rely on the combination of useState and useEffect.

Let’s implement client-side data fetching.

Again, check out how to generate types to add proper typing for Post.

But now we have loading spinners! Yuck!

Realtime

Realtime allows us to subscribe to changes in Supabase — inserted, updated or deleted posts — and update our UI dynamically. In order to receive realtime events, we need to enable replication on the posts table.

Let’s merge the two previous concepts and fetch the initial state of our posts in a Server Component, and then render a Client Component to do client-y things — like subscribe to changes in the DB and update the UI dynamically:

Server Component

Client Component

useEffect is used to subscribe to changes to the serverPosts prop. Without this, our component would not display fresh server-side results when the parent component is re-rendered, only on the first render.

This is a great pattern for fetching initial data server-side and subscribing to realtime changes client-side. This will likely be replaced by the use hook once it is stable with Next.js — it also uses suspense to suspend the rendering of a component while fetching data, and cleans up those loading and error states.

Conclusion

Next.js 13 Server Components are awesome! Suspense is awesome! Async components are awesome!

The combination of these concepts allow us to think about data fetching and caching as separate concerns, rather than specifying completely different data fetching functions like getStaticProps and getServerSideProps. If our caching requirements for a component change, we simply update the caching value, rather than refactoring our data fetching logic.

Additionally, by allowing any component in the tree to be either a server or client component — that is responsible for its own data and suspends rendering until it is ready — drastically simplifies our code, and provides much more flexible patterns for creating maintainable applications as complexity grows.

More Next.js 13 Resources

• Next.js Quickstart
• Next.js 13 Beta Docs
• Creating an authenticated Supabase client in Next.js 13 Server Component
• Data fetching and caching with Next.js 13 - Supabase Happy Hour #26