Next.js is a minimalistic framework for server-rendered React applications.

tailwind

Supabase is an open source Firebase alternative. A service to:

- Listen to database changes.
- Query your tables, including filtering, pagination, and deeply nested relationships (like GraphQL).
- Create, update, and delete rows.
- Manage your users and their permissions.
- Interact with your database using a simple UI.

Supabase is not a 1-to-1 mapping of Firebase. Most notably, Supabase uses Postgres rather than a NoSQL store. 

supabase

TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.

typescript

In this course, we build a Twitter clone from scratch, using the [Next.js App Router](https://nextjs.org/docs/app) and [Supabase](https://supabase.com/). We dive deep on the Next.js App Router, learning about:

- Client Components
- Server Components
- Route Handlers
- Server Actions
- Middleware
- Implementing Optimistic UI

On the Supabase side we look at:

- Configuring Supabase Auth to use cookies
- Using Row Level Security (RLS) policies to implement Authorization
- Querying data across multiple tables
- Introspecting PostgreSQL schema to generate TypeScript definitions with the Supabase CLI
- Subscribing to realtime database changes

This course is a deep dive into modern web development and I'm very excited to see what you're going to build on the other side! 🚀

[Supabase](https://supabase.com/) is a collection of open source tools that wrap around a PostgreSQL database - Hosting, Auth, Realtime, File Storage, Edge Functions etc. In this lesson, we go to [database.new](https://database.new) to create a free Supabase project.

Additionally, we create a `tweets` table and populate it with some seed data.

## Code Snippets

**Create a `tweets` table**

```sql
create table if not exists tweets (
  id uuid default gen_random_uuid() primary key,
  created_at timestamp with time zone default timezone('utc'::text, now()) not null,
  title text not null
);
```

**Insert tweets**

```sql
insert into tweets(title)
values
  ('first tweet'),
  ('second tweet'),
  ('third tweet');
```

## Resources

- [Supabase docs](https://supabase.com/docs)
- [Supabase SQL Editor](https://app.supabase.com/project/_/sql)

postgres

Create a New Supabase Project and Basic PostgreSQL Schema

[Next.js](https://nextjs.org/) is a full-stack React framework that provides the client and server building blocks to create powerful web applications. In this lesson we run the `create-next-app` CLI command to create a new Next.js application, configured with:

- [App Router](https://nextjs.org/docs)
- [TypeScript](https://www.typescriptlang.org/)
- [Tailwind CSS](https://tailwindcss.com/)

## Code Snippets

**Create Next.js app**

```bash
npx create-next-app blue-bird
```

## Resources

- [Next.js App Router docs](https://nextjs.org/docs)
- [TypeScript docs](https://www.typescriptlang.org/)
- [Tailwind CSS docs](https://tailwindcss.com/)

Create a Next.js App with the create-next-app CLI

Our [Supabase](https://supabase.com) project is a hosted PostgreSQL database. In this lesson, we install the [Supabase Auth Helpers](https://www.npmjs.com/package/@supabase/auth-helpers-nextjs) and [Supabase.js](https://www.npmjs.com/package/@supabase/supabase-js) npm packages, and configure environment variables to query data from Supabase:

```
NEXT_PUBLIC_SUPABASE_URL=your-supabase-url
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-supabase-anon-key
```

These values can be found in [your Supabase project's API Settings](https://app.supabase.com/project/_/settings/api).

Additionally, we create a new Supabase instance using the `createServerComponentClient` function, then make our Server Component Async and suspend its rendering until our request for Supabase data resolves.

Lastly, we implement a Row Level Security (RLS) policy to enable read access for the `tweets` table.

## Code Snippets

**Install Supabase packages**

```bash
npm i @supabase/auth-helpers-nextjs @supabase/supabase-js
```

**Import createServerComponentClient function**

```tsx
import { createServerComponentClient } from "@supabase/auth-helpers-nextjs";
import { cookies } from "next/headers";
```

**Create Supabase client in Server Component**

```tsx
const supabase = createServerComponentClient({ cookies });
```

**Fetch data from Supabase**

```tsx
const { data: tweets } = await supabase.from("tweets").select();
```

**Pretty print data with JSON.stringify**

```tsx
<pre>{JSON.stringify(tweets, null, 2)}</pre>
```

**Enable read access with RLS policy**

```sql
create policy "anyone can select tweets" ON "public"."tweets"
as permissive for select
to public
using (true);
```

## Resources

- [Supabase Auth Helpers for Next.js](https://supabase.com/docs/guides/auth/auth-helpers/nextjs)
- [Supabase.js docs](https://supabase.com/docs/reference/javascript/installing)
- [Row Level Security](https://supabase.com/docs/guides/auth/row-level-security)

Query Supabase Data from Next.js Server Components

[Supabase](https://supabase.com/) includes many ways to authenticate users - Email and password, magic link, mobile OTP etc. In this lesson we implement social login with GitHub by registering a new OAuth Application and providing Supabase with the Client ID and Secret.

## Resources

- [Supabase guide to Login with GitHub](https://supabase.com/docs/guides/auth/social-login/auth-github)

github

Create an OAuth App with GitHub

[Supabase](https://supabase.com) includes multiple authentication strategies. In this lesson, we create a Supabase client to trigger the OAuth authentication flow with GitHub.

Additionally, we discuss the differences between Client and Server Components in the [Next.js App Router](https://nextjs.org/docs/app):

- Client Components: user interactivity
- Server Components: data fetching

Lastly, we create a Route Handler to exchange an authentication code from GitHub for their Supabase session.

## Code Snippets

**Authenticate with GitHub OAuth**

```tsx
await supabase.auth.signInWithOAuth({
  provider: "github",
  options: {
    redirectTo: "http://localhost:3000/auth/callback",
  },
});
```

**Exchange code for Supabase session**

```tsx
await supabase.auth.exchangeCodeForSession(code);
```

## Resources

- [Supabase Auth Helper docs](https://supabase.com/docs/guides/auth/auth-helpers/nextjs)
- [Next.js App Router docs](https://nextjs.org/docs/app)

Authenticate Users with GitHub OAuth using Supabase and Next.js Client Components

Server Components cannot set cookies in the [Next.js App Router](https://nextjs.org/docs/app). In this lesson, we implement middleware to refresh expired [Supabase](https://supabase.com/) sessions.

[Middleware](https://nextjs.org/docs/app/building-your-application/routing/middleware) runs immediately before the route is loaded. By using it to refresh our user's session, we ensure it is valid by the time it loads the Server Component and attempts to fetch data from Supabase.

## Code Snippets

**Refresh expired sessions**

```tsx
supabase.auth.getSession();
```

## Resources

- [Supabase Auth Helper docs](https://supabase.com/docs/guides/auth/auth-helpers/nextjs)
- [Next.js App Router docs](https://nextjs.org/docs/app)
- [Next.js Middleware](https://nextjs.org/docs/app/building-your-application/routing/middleware)

Refresh Session Cookie for Next.js Server Components with Middleware

Since we're using [Supabase](https://supabase.com/) to authenticate our users, it knows who our user is throughout the rest of the Supabase environment.

In this lesson, we modify our Row Level Security (RLS) policy to only apply to the `authenticated` role to ensure that only authenticated users can select tweets.

Additionally, we use the `useRouter` hook and `router.refresh()` to run our Server Component again and fetch fresh data from Supabase, after the user signs in or out.

## Code Snippets

**Enable authenticated read access with RLS policy**

```sql
create policy "anyone can select tweets" ON "public"."tweets"
as permissive for select
to authenticated
using (true);
```

## Resources

- [Row Level Security docs](https://supabase.com/docs/guides/auth/row-level-security)
- [useRouter hook](https://nextjs.org/docs/app/api-reference/functions/use-router#userouter)

Restrict Access to Authenticated Users with Supabase RLS Policies

The first render of a Client Component happens on the server. This is called Server-side rendering (SSR). However, Client Components are synchronous, so they cannot suspend rendering while fetching data - such as the user's session. This means we either need to display a loading spinner or render the logged out state, while fetching that async data, causing a flash of incorrect state for the user.

In this lesson, we look at rendering a Client Component from a Server Component that can asynchronously fetch the user's [Supabase](https://supabase.com/) session, and pass it as a prop to the Client Component, making the user's session available on its first SSR render.

## Code Snippets

**Render Client Component from Server Component**

```tsx
const {
  data: { session },
} = await supabase.auth.getSession();

return <ClientComponent session={session} />;
```

## Resources

- [Client and Server Components docs](https://nextjs.org/docs/getting-started/react-essentials)
- [Supabase Auth Helpers for Next.js docs](https://supabase.com/docs/guides/auth/auth-helpers/nextjs)

Dynamically Render UI Based on User Session with SSR in Next.js Client Components

Since [Supabase](https://supabase.com/) requires our user to be authenticated to fetch tweets, it doesn't make sense for an unauthenticated user to visit the landing page. In this lesson, we implement protected routes that are only accessible to authenticated users.

Additionally, we create a `/login` route to redirect unauthenticated users, which allows them to sign in with GitHub.

## Code Snippets

**Redirect unauthenticated users**

```tsx
const {
  data: { session },
} = await supabase.auth.getSession();

if (!session) {
  redirect("/login");
}
```

## Resources

- [Supabase Auth Helpers for Next.js docs](https://supabase.com/docs/guides/auth/auth-helpers/nextjs)

Implement Protected Routes for Authenticated Users with Supabase Auth

[Typescript](https://www.typescriptlang.org/) reduces runtime errors and makes our code more maintainable. [Supabase](https://supabase.com/) allows us to introspect our PostgreSQL schema and generate TypeScript definitions.

In this lesson we generate an access token to use the [Supabase CLI](https://supabase.com/docs/guides/cli) and generate TypeScript definitions. Additionally, we write our types to a file, which can be passed to our Supabase client, giving our application full type-safety across client, server and database.

Lastly, we make our Database types globally available so we don't need to import them every time we create a Supabase client.

## Code Snippets

**Login to Supabase CLI**

```bash
npx supabase login
```

**Generate TS definitions file**

```bash
npx supabase gen types typescript --project-id your-project-id > lib/database.types.ts
```

## Resources

- [Generate Supabase access token](https://app.supabase.com/account/tokens)
- [TypeScript docs](https://www.typescriptlang.org/)
- [Supabase CLI](https://supabase.com/docs/guides/cli)
- [Generating TypeScript definitions](https://supabase.com/docs/guides/api/rest/generating-types)

Generate TypeScript Definitions from PostgreSQL Schema with Supabase CLI

[Supabase](https://supabase.com/) uses the `auth.users` table to store information about our users and their sessions. In this lesson, we add a column to the `tweets` table to associate each tweet with one of our users.

Additionally, we set up cascading deletes, so when a user is deleted from the `auth.users` table, their tweets are also deleted.

Lastly, because our database schema has changed, our TypeScript definitions are now incorrect. Therefore, we use the Supabase CLI to introspect our PostgreSQL schema and create a new `database.types.ts` file.

## Code Snippets

**Add foreign key relationship to auth.users**

```sql
alter table public.tweets
add user_id uuid references auth.users on delete cascade not null;
```

**Generate TypeScript definitions**

```bash
npx supabase gen types typescript --project-id your-project-id > lib/database.types.ts
```

## Resources

- [Supabase Auth docs](https://supabase.com/docs/guides/auth)
- [Supabase CLI](https://supabase.com/docs/guides/cli)
- [Generating TypeScript definitions](https://supabase.com/docs/guides/api/rest/generating-types)

Setup a Foreign Key relationship between PostgreSQL tables

[Supabase](https://supabase.com/) has an `auth.users` table that contains information about our user and their session. We want to display the user's name, username and avatar alongside their tweets, but the `auth.users` table cannot be publicly accessible, as it contains sensitive information.

In this lesson, we create a new table called `profiles` and populate it with the data we want to display from the `auth.users` table. Additionally, we set up a PostgreSQL Function and Trigger to create a new profile for any user added to the `auth.users` table.

Lastly, we create an RLS policy for the `profiles` table to enable read access, and re-generate our TypeScript definitions file to contain our new table.

## Code Snippets

**Create profiles table**

```sql
create table public.profiles (
  id uuid not null references auth.users on delete cascade primary key,
  name text not null,
  username text not null,
  avatar_url text not null
);
```

**Enable Row Level Security**

```sql
alter table public.profiles enable row level security;
```

**Enable read access with RLS policy**

```sql
create policy "anyone can select profiles" ON "public"."profiles"
as permissive for select
to public
using (true);
```

**Create PostgreSQL Function to create profile**

```sql
create function public.create_profile_for_user()
returns trigger
language plpgsql
security definer set search_path = public
as $$
begin
  insert into public.profiles (id, name, username, avatar_url)
  values (
    new.id,
    new.raw_user_meta_data->'name',
    new.raw_user_meta_data->'user_name',
    new.raw_user_meta_data->'avatar_url'
  );
  return new;
end;
$$;
```

**Create PostgreSQL Trigger to create profile**

```sql
create trigger on_auth_user_created
  after insert on auth.users
  for each row execute procedure public.create_profile_for_user();
```

## Resources

- [Managing user data docs](https://supabase.com/docs/guides/auth/managing-user-data)
- [Row Level Security docs](https://supabase.com/docs/guides/auth/row-level-security)

Automatically Generate a Profile for Every User with PostgreSQL Function Triggers

[Server Actions](https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions) are a way to perform server-side mutations in the [Next.js App Router](https://nextjs.org/docs/app). In this lesson, we create a `<NewTweet />` component that renders a form for the user to enter a new tweet. This form is submitted to a Server Action, which writes this data to [Supabase](https://supabase.com/).

Additionally, we create a Server Action Supabase client and call the `getUser` function to fetch the currently signed in user.

Lastly, we write a Row Level Security (RLS) policy to enable the `insert` action for `authenticated` users.

## Code Snippets

**Posting form to Server Action**

```tsx
export default function NewTweet() {
  const addTweet = async () => {
    "use server";
  };

  return <form action={addTweet}>...</form>;
}
```

**Create Supabase client in Server Action**

```tsx
const supabase = createServerActionClient<Database>({ cookies });
```

**Get user from Supabase client**

```tsx
const {
  data: { user },
} = await supabase.auth.getUser();
```

**Insert tweet with Supabase**

```tsx
await supabase.from("tweets").insert({...});
```

## Resources

- [Server Action docs](https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions)
- [Supabase Auth Helpers for Next.js](https://supabase.com/docs/guides/auth/auth-helpers/nextjs)
- [Inserting data with supabase-js](https://supabase.com/docs/reference/javascript/insert)

Run Authenticated Server-side Mutations with Next.js Server Actions

We create a PostgreSQL join table for `likes` in the [Supabase](https://supabase.com) dashboard. This has a many-to-many relationship between the `profiles` and `tweets` table, allowing us to store each instance of a like between a user and a tweet.

Additionally, we create Row Level Security (RLS) polices to enable `select`, `insert` and `delete`.

## Code Snippets

**Create likes table**

```sql
create table public.likes (
  id uuid default gen_random_uuid() primary key,
  created_at timestamp with time zone default timezone('utc'::text, now()) not null,
  user_id uuid references public.profiles on delete cascade not null,
  tweet_id uuid references public.tweets on delete cascade not null
);
```

**Enable Row Level Security**

```sql
alter table public.likes enable row level security;
```

**Enable insert action with RLS policy**

```sql
create policy "authenticated users can insert their own likes" ON "public"."likes"
as permissive for select
to authenticated
using (user_id = auth.uid());
```

**Enable delete action with RLS policy**

```sql
create policy "authenticated users can delete their own likes" ON "public"."likes"
as permissive for delete
to authenticated
using (user_id = auth.uid());
```

**Enable select action with RLS policy**

```sql
create policy "authenticated users can select likes" ON "public"."likes"
as permissive for select
to authenticated
using (true);
```

## Resources

- [Managing user data docs](https://supabase.com/docs/guides/auth/managing-user-data)
- [Row Level Security docs](https://supabase.com/docs/guides/auth/row-level-security)

Create a PostgreSQL Join Table in Supabase Studio

In this lesson, we create a new component to display the likes from [Supabase](https://supabase.com/). This component will be interactive so it needs to be a Client Component.

Additionally, we extend our Supabase query for `tweets`, and join the columns from our `likes` table.

Lastly, we make this button dynamic by checking whether the user has previously liked this tweet. If they have not, we increment the likes by 1, otherwise, we decrement them by 1.

## Code Snippets

**Querying data across tables**

```tsx
const { data } = await supabase
  .from("tweets")
  .select("*, profiles(*), likes(*)");
```

## Resources

- [Client Component docs](https://nextjs.org/docs/getting-started/react-essentials#client-components)
- [Querying across tables with supabase-js](https://supabase.com/docs/reference/javascript/select)

Implement Dynamic Buttons with Next.js Client Components

[TypeScript](https://www.typescriptlang.org/) reduces runtime errors and makes code more maintainable. In this lesson, we use the [Supabase](https://supabase.com/) CLI to introspect our PostgreSQL schema and generate TypeScript definitions.

Additionally, we resolve a collection of TypeScript errors and create a custom union type for our transformed tweets - making it globally available throughout our Next.js application.

## Code Snippets

**Custom type for TweetWithAuthor**

```tsx
type TweetWithAuthor = Tweet & {
  author: Profile;
  likes: number;
  user_has_liked_tweet: boolean;
};
```

**Generate TypeScript definitions**

```bash
npx supabase gen types typescript --project-id your-project-id > lib/database.types.ts
```

## Resources

- [TypeScript docs](https://www.typescriptlang.org/)
- [Supabase CLI](https://supabase.com/docs/guides/cli)
- [Generating TypeScript definitions](https://supabase.com/docs/guides/api/rest/generating-types)

Declare Global Intersection Types for Transformed Supabase Data with Typescript

"Optimistic UI" is a pattern for updating the page immediately with the data you have available, rather than waiting for the database query to resolve. In this lesson, we use React's `useOptimistic` hook to create an array of tweets that we can instantly update with our new state, when the user clicks the like button.

## Code Snippets

**Call useOptimistic hook**

```tsx
const [optimisticState, addOptimisticState] = useOptimistic(
  initialState,
  (currentState, newState) => {
    // merge state
    // return new state
  }
);
```

**Add optimistic tweet**

```tsx
addOptimisticTweet({
  ...tweet,
  likes: tweet.likes - 1,
  user_has_liked_tweet: !tweet.user_has_liked_tweet,
});
```

## Resources

- [useOptimistic hook](https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions#enhancements)

Implement Optimistic UI with the React useOptimistic hook in Next.js

[Supabase](https://supabase.com/) allows us to subscribe to changes in the database, and update our UI, without the user needing to refresh the page. In this lesson, we create a subscription for `postgres_changes`, listening for any change events - insert, update or delete - on our tweets table.

Additionally, we call the `router.refresh()` function to re-run our Server Components, fetching fresh data from Supabase.

## Code Snippets

**Subscribe to database changes**

```tsx
const channel = supabase
  .channel("realtime tweets")
  .on(
    "postgres_changes",
    {
      event: "*",
      schema: "public",
      table: "tweets",
    },
    (payload) => {
      router.refresh();
    }
  )
  .subscribe();
```

## Resources

- [Supabase Realtime docs](https://supabase.com/docs/guides/realtime)
- [useRouter hook docs](https://nextjs.org/docs/app/api-reference/functions/use-router)

Dynamically Update UI with Database Changes using Supabase Realtime

[Tailwind](https://tailwindcss.com/) is an atomic CSS framework that makes styling an application more consistent and maintainable. In this lesson, we look at building out a similar UI to Twitter using only Tailwind classes.

Additionally, we use a heart icon from Feather Icons for our like button, and create a new `<GitHubButton />` component that displays a nicely styled GitHub logo to trigger the user authentication flow.

## Resources

- [Tailwind docs](https://tailwindcss.com/)
- [Feather Icons](https://feathericons.com/)
- [GitHub Logo](http://github.com/logos)

Style a Twitter clone with Tailwind CSS

[Vercel](https://vercel.com) is a hosting platform that works very well with [Next.js](https://nextjs.org) - because it's their framework! In this lesson, we prepare our project to be deployed to production by:

- Pushing code to [GitHub](https://github.com/)
- Deploying repo to [Vercel](https://vercel.com)
- Updating [GitHub OAuth app](https://github.com/settings/developers) to use production URL
- Updating [Supabase](https://supabase.com/) project to use production URL

## Resources

- [Deploy Next.js to Vercel guide](https://nextjs.org/learn/basics/deploying-nextjs-app/deploy)
- [GitHub OAuth App settings](https://github.com/settings/developers)
- [Vercel](https://vercel.com)
- [Supabase URL configuration](https://app.supabase.com/project/_/auth/url-configuration)

Deploy Next.js App Router project to production with Vercel

Build a blazing fast chat app with Remix and Supabase! This course covers everything you need, from database hosting to authentication and authorization, all with real-time updates

Build a Realtime Chat App with Remix and Supabase

Combining Supabase, Cloudflare Workers and KV Storage give you the benefits of reduced lag in a smooth and streamlined process.

Cache Supabase data at the Edge with Cloudflare Workers and KV Storage

Build a Twitter Clone with the Next.js App Router and Supabase

https://app.egghead.io/api/v1/lessons/postgresql-create-a-new-supabase-project-and-basic-postgresql-schema/subtitles

Instructor: Head over to database.new to create a new Supabase project. Then I'm going to sign in with GitHub, enter my username and password, and click Sign in. You'll see this has selected my default organization. We're going to be building a Twitter clone. The name of my project is going to be Blue Bird.

I'm going to click this button here to generate a database password. Make sure you copy this value into something like a password manager as this is your database password and the only time you'll be able to read that value. For the region, I'm going to select Sydney as this is closest to my geographical location. You want this region to be close to your users for the best performance.

Everything we'll do in this course will be on the free plan. I'm going to click this button to create my new project. You'll see this will take a little bit of time to set up our project. Once that's finished, we want to come over to the Table Editor to create a new table to store our tweets.

I'm going to leave row level security, or RLS enabled, as this is recommended. For the structure of our table, we've already got an id, but I'm going to change the type of this from int8 to uuid, and then click these three dots to set the default value for this column to be a freshly generated random uuid.

We also have a created_at timestamp which has a default value set to the time that this row was created. Now, if we click this cog, we can see some more options for this column, and we'll see the value for this column can be set to NULL.

Since this timestamp is automatically generated for us and we're going to use it for sorting our tweets, we're always going to want this column to have a value. Let's untick Is Nullable, and then add a new column for the title of our tweet. The type for this one is going to be text. We won't have a default value for this one, but we always want our tweets to have a title.

Let's also untick Is Nullable, and then click Save to create our tweets table. Now we can insert a new row. Again, these two values will be generated for us. We just need a title, which is going to be, first tweet, and then click Save to insert that new row into the tweets table.

I'm going to magically add two more tweets. We can see we have our first, second and third tweet in our Supabase database.

https://app.egghead.io/api/v1/lessons/postgresql-create-a-new-supabase-project-and-basic-postgresql-schema/transcript

https://app.egghead.io/api/v1/lessons/next-js-create-a-next-js-app-with-the-create-next-app-cli/subtitles



Instructor: We're going to use MPX to run the create-next-app package to create our new Next.js app. We're going to call this one blue-bird, and then this will step us through some questions to configure our project.

I'm going to use TypeScript. I do want ESLint. I want Tailwind CSS. I don't want to use the source directory. I do want to use the new app router, and I don't want to customise the default import alias. Once that's finished, we can change into our new directory and open it up in VS Code.

You can see we've got a starter project using the app directory with our index route that looks something like this. We can run npm run dev to start our development server, and if we navigate over to localhost over port 3000, we'll see the contents of that page.tsx file rendered in the browser.

https://app.egghead.io/api/v1/lessons/next-js-create-a-next-js-app-with-the-create-next-app-cli/transcript

https://app.egghead.io/api/v1/lessons/next-js-query-supabase-data-from-next-js-server-components/subtitles

Instructor: Let's replace the contents of this page with our tweets from Supabase. Back over in VS code, we can quit our development server and then run npm install or i @supabase/auth-helpers-nextjs. This requires the @supabase/supabase-js library.

Then once that's installed, we can run npm run dev to start our development server again. Then we want to create a new file in the root-most directory of our application. This is going to be called .env.local. In here, we want a NEXT_PUBLIC_SUPABASE_URL and also an ANON_KEY.

We can get these from our Supabase dashboard under Settings and then API. The Project URL section will have our URL which we can paste in here. Then under Project API keys, we want this anon public key. We'll copy this here, paste it here.

Then back over in our page.tsx file, we want to create a new supabase instance. We can do this by calling the createServerComponentClient function which comes in from that @supabase/auth-helpers-nextjs package. This function takes in an object which has a cookies function which we can import above from next/headers.

The reason we're specifically creating a server component client here is that, by default, any pages in the app directory are automatically server components. This means, when the browser requests this page, this function runs on the server. It then generates the HTML for the page and sends that back to the browser.

No client-side JavaScript is required to render out this page, so Next.js doesn't send any client-side JavaScript back to the browser. Another cool thing about server components is, they can now be marked as async, which means we can fetch data directly in this server component.

For example, we could get all of our tweets by awaiting a call to supabase, and from the tweets table, selecting all rows. Our route is now going to wait for these tweets to come back from supabase before rendering this HTML.

We don't need to return a loading spinner while we're fetching that data. As soon as we hit this return statement, we've already got our tweets from supabase. We can just render a <pre> tag and use JSON.stringify to pretty-print out our list of tweets.

If we go over to the browser and refresh, we'll see this empty array. If we go over to our Supabase dashboard and look at our tweets table, we can see that we have those three tweets, so why aren't they displaying in our Next.js app?

This is because we enabled row level security or RLS for the tweets table. RLS automatically denies all requests to that table. No one can select, insert, update, or delete any of the rows in this table. If we want to enable one of those actions, we need to write a policy.

There are some templates to help you get started, but we're going to create this one from scratch. Our policy name is going to be, anyone can select tweets. It's going to enable the SELECT action. We're going to leave Target roles as public, and then our USING expression needs to have a condition that either evaluates to true or false.

If it's true, then the select action will be allowed. If it's false, then it will continue to be denied. In this case, we want to use the value true, which means that anyone can select tweets. Let's click Review, which will show the SQL that's been generated for this policy. Then we can click Save policy to run this SQL against our Supabase database.

Now that we've got that SELECT policy, if we go back to our application and refresh, we'll see our list of tweets are being sent back by Supabase and successfully rendered by our Next.js server component.

https://app.egghead.io/api/v1/lessons/next-js-query-supabase-data-from-next-js-server-components/transcript

https://app.egghead.io/api/v1/lessons/supabase-create-an-oauth-app-with-github/subtitles

https://app.egghead.io/api/v1/lessons/supabase-create-an-oauth-app-with-github/transcript

https://app.egghead.io/api/v1/lessons/supabase-authenticate-users-with-github-oauth-using-supabase-and-next-js-client-components/subtitles

https://app.egghead.io/api/v1/lessons/supabase-authenticate-users-with-github-oauth-using-supabase-and-next-js-client-components/transcript

https://app.egghead.io/api/v1/lessons/supabase-refresh-session-cookie-for-next-js-server-components-with-middleware/subtitles

Instructor: There's a small bug with our Auth logic where when the cookie expires and the user refreshes the page, the cookie is removed putting them in a logged out state. This is because back over in our server component, where we're creating a server component client with these cookies from Next.js, we only have read access to these cookies.

When we try to select all of those tweets, Supabase recognizes that that cookie has expired and refreshes it, but since our server component has no way to update that cookie value, it remains that expired token which gets removed from the browser. Now this is only the case for server components, so client components, route handlers, server actions, and middleware can all set a new cookie for a refreshed session, but there's no way to currently do this in server components.

Since we can do this in middleware, we want to create a new file at the rootmost part of our application called middleware.ts. In here we want to export this middleware function which takes a request and creates a response, then passes those along to the createMiddlewareClient function from our Superbase auth helpers package.

Now, since this Superbase client can now modify this request and response, we can call the Superbase.auth.getSession function which will refresh the session if it's expired, and then return this response which will load our server component route, but this cookies function will contain that updated cookie with a fresh session from Superbase.

Now, in our application, when we log in, a cookie is set for our user's session. Once this session has expired, our middleware function will refresh that session in the background. The only time our user should be logged out is when they choose to click the logout button.

https://app.egghead.io/api/v1/lessons/supabase-refresh-session-cookie-for-next-js-server-components-with-middleware/transcript

https://app.egghead.io/api/v1/lessons/next-js-restrict-access-to-authenticated-users-with-supabase-rls-policies/subtitles

https://app.egghead.io/api/v1/lessons/next-js-restrict-access-to-authenticated-users-with-supabase-rls-policies/transcript

https://app.egghead.io/api/v1/lessons/supabase-dynamically-render-ui-based-on-user-session-with-ssr-in-next-js-client-components/subtitles

Instructor: Our application has buttons for the user to log in and log out. If they are logged out, it probably doesn't make sense for them to see this button anymore. They should probably only see the Login button. When they log in, they should only see the Logout button as this is the only one that's relevant to their current state.

Let's make these buttons aware of our user's session so we know which one to show. If the user does have a session, then we want to show them the Logout button, and then if they don't have a session, then we want to show the Login button. We can get rid of this fragment.

Where do we get this session? One way we can do this is by using useState to create a variable for our session. We can then use useEffect to run some logic when our component mounts. We need to do some async stuff here. We're going to declare a new function called getSession. This is going to be an async function which gets some data by awaiting a call to supabase.auth.getSession.

Now, we want to call our getSession function that we declared above and update our session variable to be that session that we got back from supabase. Let's not worry about TypeScript for now because we're not going to use this block of code, but we need to make sure we call that getSession function.

Now, if we go back to the browser, we'll see our Logout button. This looks like it's all working. Let's click Logout. Our list of tweets is now an empty array, but our button still says Logout. Let's try refreshing. OK, it says Login. That's good. Now let's click Login. That seems to have updated our tweets and our button, but when we refresh, we see this flash of the Login button.

This is because this session variable is undefined on the first render of our application which happens on the server. Even though our user should be authenticated and seeing the Logout button, the session is undefined, so they see Login instead. Now when this page is loaded in the browser, this will then call useEffect.

This calls the getSession function which goes off to supabase and gets a session. Then we update our local session, which then causes this component to re-render, only this time there is a session, so it displays the Logout button. Seeing that flash of the Login button is not a very good user experience.

How can we make this session variable available and correct on that initial server rendered version of our component? Well, if we have a look at the server component for our learning page, it can be an async function. Just suspend the rendering of our component until this promise from supabase resolves.

Let's wrap this client component in an async server component that can fetch that session from supabase before the initial render, and then pass that session down to our client component, which will then have the correct state for our session on its first render.

Let's create a new file called auth-button-server.tsx. This -server part is not required, it's just to help us easily distinguish between our server and client component. We could rename this one to be -client. Now, in our auth-button-server component, we want to export a default async function for our AuthButtonServer component.

In here, we're going to need a new supabase client which we can get by calling the createServerComponentClient function which comes in from our auth-helpers package. We then need to pass it our cookies function which we can import from next/headers. Now we can move that call to supabase to get our user session from our client component across to our server component.

I'm going to destructure the session object directly here. We can then clean up our client component by removing useEffect, and now useState variable, and then this session can come in from our component's props. We're going to pass it a session.

We can type this correctly to say our session is going to either be of type Session, which comes in from our auth-helpers package, or it's going to be null, if our user is not signed in. We can now get rid of that import for useEffect and useState.

We could also update the name of our function to be AuthButtonClient, which makes it super clear over in our server component when we want to return our AuthButtonClient component, which comes in from ./auth-button-client. If we close this one off, it's going to tell us that we need to pass it a session. We can pass it a prop for session, which is that session that we got from supabase.

Back over in page.tsx, we want to import our AuthButtonServer from auth-button-server, which is then what we want to render from our component. Now, if we go back to the browser, we see the correct Logout button.

When we refresh, we can see that our Logout button is stable. We don't see that flash of Login. If we log out, we see our Login button. When we log in, our tweets and our Logout button are updated.

To quickly recap, we wanted to dynamically render a different piece of UI from our client component based on the user's session. Since client components are synchronous, there was no way to fetch the user's session before the initial render of our component, which happens server-side.

Since server components can be async, we first fetched our user's session from supabase, and then passed that to our client component as the session prop, which made it available on the first render of our client component.

https://app.egghead.io/api/v1/lessons/supabase-dynamically-render-ui-based-on-user-session-with-ssr-in-next-js-client-components/transcript

https://app.egghead.io/api/v1/lessons/supabase-implement-protected-routes-for-authenticated-users-with-supabase-auth/subtitles

Instructor: Currently, a user sees a list of tweets when they're signed in, but when they sign out, they just see this empty array. It doesn't really make sense for someone to visit this page unless they're signed in. Let's redirect unauthenticated users to a login page.

Back over in our application, before we get a list of tweets from Supabase, we're going to add our redirection logic. We can start by getting some data, which is our session, by awaiting a call to supabase.auth.getSession. This will give us back our user's session, or null if they're not signed in.

If we don't have a session, then we want to redirect the use. This is a function that comes in from next /navigation. We then just need to give it a path to redirect to. In this case that would be /login, which we'll create in a moment.

Then if we do have a session, then we'll continue on to get our tweets from Supabase and then render our component. Let's create this login route. Under app, we want a new file at login/page.tsx.

It's going to export a default async function for login. It's going to need a Supabase client, so we can create that by calling the createServerComponentClient function, which comes in from our auth helpers package. We should know this by now, it takes a cookies function, which we can import from next/headers.

Then it doesn't really make sense for someone to visit our login page if they're already authenticated. We're going to do the reverse of our redirection logic from our landing page. If we do have a session, then we want to redirect to our landing page.

If we don't have a session, then we want to return a login button, so we can just reuse our auth button client component, which comes in from ../auth-button-client.

It then takes a session prop, which can be set to our user's session, which will just be the value null at this point, otherwise we would have been redirected above. Now, if we go back to the browser and refresh, you'll see I've already been redirected to /login because I'm not currently authenticated.

If I log in, it's going to redirect me to that landing page. Again, if I log out, we're back on our login route.

https://app.egghead.io/api/v1/lessons/supabase-implement-protected-routes-for-authenticated-users-with-supabase-auth/transcript

https://app.egghead.io/api/v1/lessons/supabase-generate-typescript-definitions-from-postgresql-schema-with-supabase-cli/subtitles

Instructor: Our Next.js application is a TypeScript project. When we're doing generic things with supabase, we have some type safety. We know this getSession function is going to give us back either the user's session or null.

But when we're doing things that are unique to the structure of our supabase project, like selecting these tweets from the tweets table, you'll see supabase is doing its best, but it doesn't know the shape of that tweet that's going to come back.

Let's generate some TypeScript definitions based on our database's schema. We can do that by using npx to run the supabase CLI. The first thing we want to do is log in. This is asking us for an access token. We can go to this URL to generate one. I'm going to generate a new token.

The name for this one is going to be blue-bird. Again, this can be anything you'd like. Let's generate that token. Here's our new access token. Let's go back over to the terminal and paste that one in. You should see, Finished supabase login. Now, the supabase CLI has the same permissions that we do when we're signed into the Supabase dashboard.

If we want to generate TypeScript types for one of our projects, we can run npx supabase gen, or generate, types typescript, and then give it a project-id. We can get that from the Supabase dashboard for our project by going to Settings, and then under General settings, we have Reference ID. Let's copy this and paste it into our command.

Then if we run this, we're going to see all of the types for our project dumped out into the console. You can see we have Tables, tweets, and then each of these rows represent one of our tweets from the database. This doesn't help us, dumped out in the console, we probably want to save this to a file.

If we run that same command, we can then use > to write the output to a file. The file we want to write this to is lib/database.types.ts. If we run this, we're going to see, no such file or directory exists. We need to create this lib folder. We can run mkdir, or make directory, and then lib.

Now, when we run our command to generate our types and go back over to our project, we'll see we have this new lib folder with our database.types.ts file, which has all of the information about our database schema. Now we need to tell our SupabaseClient about our Database types.

If we scroll up to where we're creating our server component client, we can then pass this, our Database type, which we can import from @/lib/database.types. Now our SupabaseClient is correctly typed. If we scroll down to our tweets variable, we can see it's going to be an array of this specific type or null.

We have several instances throughout our application where we're creating a SupabaseClient. We don't want to have to import this file every single time. Let's declare this Database type as a global type so it's available throughout our application.

Let's start by creating a new file in the app directory called global.d.ts. Then we can move that import statement from page.tsx into our global types file. We can then declare our global types, which is an object, where we can say we want the type of Database to be equal to our Database type that we imported above.

Now, annoyingly, this doesn't work if the name of the type is the same on either side of the equal sign. We can use an alias to import Database as DB, and then we can declare a global type for Database = DB. Now, if we go back to page.tsx, we can see that even though we've removed that import statement, our SupabaseClient is still correctly typed.

If we scroll down to tweets, our Database types are correctly flowing through. Now, as mentioned before, we do have several places where we're creating SupabaseClients, but we can do a find and replace for anywhere. We're saying Client(, with a capital C, and then an open parenthesis.

You'll see each of these are us creating a SupabaseClient except for this first one, because we called this component AuthButtonClient(. We can right-click this one, and dismiss, and then confirm that each of these are us creating a SupabaseClient. We can then click this arrow to add a replace.

That's going to be Client, with a capital C, and then our <Database>( types. Make sure we have that open parenthesis, and then we can replace all occurrences. Yes, we want to do that. Now we have a properly typed SupabaseClient throughout our entire application.

https://app.egghead.io/api/v1/lessons/supabase-generate-typescript-definitions-from-postgresql-schema-with-supabase-cli/transcript

https://app.egghead.io/api/v1/lessons/postgresql-setup-a-foreign-key-relationship-between-postgresql-tables/subtitles

Instructor: Now that our users can sign in, let's associate each one of these tweets with their author. Back over in the Supabase dashboard, if we go to the Table Editor, we can see this tweets table that we created. If we go over to Authentication and Users, we can see there's a list of users being stored somewhere, but they're not listed here next to our tweets table in the Table Editor.

That's because by default, any tables that we create from the Supabase dashboard are in the public schema. If we open this dropdown list, we can see a list of these protected schemas which are associated with supabase features like graphql, realtime or things that might be needed by other extensions in our project.

We're looking for a list of users. This would probably come under auth. Now we can see a list of tables that are associated with auth. At the bottom, we have our users table. There's our user's ID, and then all the information that supabase uses to manage our user's session. Let's associate each of our tweets with the user that created them.

If we change this back to the public schema, and then go to our tweets table, we can click here to add a new column. The column_name is going to be user_id. Then we want to click this Add foreign key relation button. This lets us set up a relationship between two tables. We can say the user_id column of the tweets table is a link to the auth schema.

Then the users table. The column we want to reference from the auth.users table is the id column. Then here we can set up an action for, if the user is removed from this auth.users table, what do we want to do with their tweets? We can either have No action, which will raise an error when trying to delete that user if that user has any tweets.

Our other options are Cascade, Restrict, Set default or Set Null. In this case, we want Cascade, which means, deleting a record from the auth.users table will also delete any records that reference it in this table. Essentially, we delete the user, Cascade will automatically delete their tweets. Let's click Save. That's set up the relationship between these two columns.

Then if we scroll down, we can see Allow Nullable is enabled. This means tweets can be created without an author or a user ID. Now, that's not what we want. We want all of our tweets to have an associated user. If we try and save this, we're going to get an error when creating the column user_id because our current tweets contain null values.

We could either delete our existing tweets here, or a more realistic example would be to migrate these tweets to be correct. Let's leave Allow Nullable enabled for now so that we can create our column. We can get rid of these errors here. Now we need to set a value for the user_id for each of our tweets.

We can do that by double-clicking, which is going to look up all the rows in the auth.users table. We can click this one here and the same for these other two tweets. Now that all of the rows in our tweets column have a user_id, we can edit this column, scroll down to Allow Nullable, disable this one so that every tweet needs to have a user associated with it, and click Save to apply those changes.

Now, if we try to insert a new row for the tweets table and set the title to be fourth tweet, if we leave the user_id column blank and try to save, we're going to get this error because a null value in the column user_id of relation tweets violates not-null constraint, so this one cannot be null.

We can click here to select a record, choose our only user, and click Save to successfully insert that fourth tweet. Now, if we go back to our application and refresh, we'll see we're getting back our four tweets as well as this new user_id column because back over in our code, we're selecting all of the columns.

If we have a look at the type for our tweets, we only have created_at, id, and title. This is because any time we change the structure of our database, we need to go and generate a new version of our lib/database.types.ts file to contain the correct TypeScript definitions.

We can do that by running the same command as earlier, so npx supabase generate types for typescript, passing the project-id of our supabase project and telling it to write that result to lib/database.types.ts.

Let's run this to add our user_id column. We can see our file has been updated with the user_id and our types are correctly flowing through to our tweets, keeping our Next.js application in sync with our database schema.

https://app.egghead.io/api/v1/lessons/postgresql-setup-a-foreign-key-relationship-between-postgresql-tables/transcript

https://app.egghead.io/api/v1/lessons/postgresql-automatically-generate-a-profile-for-every-user-with-postgresql-function-triggers/subtitles

Man: Each of our tweets have a user ID column who is the author of the tweet. This ID is not going to be very helpful when we come to styling our application.

If we have a look at Twitter, we have an avatar for the user, we have their name, we have their username, and so rather than this big string of characters, we want to look up the name, username, and avatar URL for the author of this specific tweet.

Back over in the Supabase dashboard, we can go to the table editor, and if we change this schema to auth and then look at our users table, we can see we have a whole bunch of data about our user. Let's say we wanted to look up this email column.

Back over in our application, where we're making a request for all tweets, we're getting back all of the columns for our tweets table, and this is the same as passing the string star. We can also grab columns from related tables, so in this case if we had auth.users, we could grab the email column.

If we go back to our application, we're seeing the value null instead of our list of tweets, so something's not working. The problem here is that while we can look up related tables, we can't look up tables that exist in a different schema.

Even if we could, this table is protected by RLS, as it contains sensitive information that we don't want to be publicly available. Instead, let's create a new table in the public schema called Profiles.

We're going to leave row-level security enabled, and then for our columns, we want to set up a foreign key relationship with this ID. To our auth.users table, we want to reference the ID column, and again, if that user is deleted, we want to cascade the deletes to this profiles table. Let's click save to set up that relationship.

We're going to copy across the data from the auth.users table that we want to display in our application. We don't really care about this created at column, but we want a new column for name, and the type for this one is going to be text. We're going to click this cog to say we don't ever want this value to be null, and then we want another column for username.

Again, this one is going to be text, and we don't want it to ever be null. Lastly, we want a column for avatar_url. This will also be text and not null. Let's click save to create our table, and now we want there to be a profile for every single one of our users, and so anytime a new user is added to the auth.users table, we want to create an associated profile with the same ID.

As for our name and username and avatar URL, we want to find this raw user metadata column, which is a big JSON blob, and if we extend this out, we'll see we have a name field. We also have a user_name, and an avatar_url. This is because we implemented authentication using OAuth with GitHub, so we get access to some extra information about our user that's publicly available on GitHub.

To copy this data across to our profiles table when a new user is added, we need to create a Postgres trigger function. We can do this by going to database and then Functions. We want to create a new function.

The name of our function is going to be insert profile for new user, and this one can have spaces that's why we're using these underscores. We want this to be on the public schema. The return type is going to be trigger, and then in the definition section, we need a begin and an end.

Then we want to insert into the public.profiles table, and the columns we're going to set are going to be ID, name, username, and avatar_url. We then need to provide values for each of those columns.

Because this function is going to be called by a trigger, we get access to a special variable called new, which, in this case, will represent the full row being inserted into the auth.users table. If we want to set our ID value, we can access that with new.id.

Then for our name, we can say new, and then this was in the raw_user_meta _data column, and then the way we access a particular property in that big JSON blob is with the - and then >> and then the key we want to access. In this case, name.

We then want the username, so we can copy most of this, and then rather than the name field, this was user_name, and then we also want the avatar_url. We need a semicolon for our insert statement, and then we need to return that new variable.

Under advanced settings, we want to scroll to the bottom and change our type of security from SECURITY INVOKER to SECURITY DEFINER. SECURITY DEFINER is used for system actions like moving data around in our database, and then SECURITY INVOKER is used when we want to call a Postgres function on behalf of the user of our application.

Let's click confirm to create that Postgres function. Now we have a function to create a new profile, but we need to set up a trigger to call this function when a new user is added to the auth.users table. Let's create a new trigger.

The name of this one is going to be on_auth.users_insert. The table we want to listen to is auth.users. The event we care about is insert, and then we want this trigger to fire after the event.

After we've created that new user, we want it to trigger for every row, and the function we want to call is our insert profile for new user function. Let's click confirm to create that new trigger. Now we can check this is working by logging our user out of our application and then going over to authentication.

Then under users, we see our user, and we just want to click these three dots to delete them and then click confirm. Because we set up cascade deletes, our tweets table will now be empty. Then let's create a new user by clicking the login button.

Then back over in Supabase, we have a look at our profiles table. We'll see our new user with their name, username, and avatar URL pulled from the auth.users table. Let's update the foreign key relationship from our tweets table so our user ID column points to our profiles table.

We can edit the relation here and then select the schema public. The table is profiles and the column is ID. Again, we want to set up an action to cascade the deletes. If our profile is deleted, that user's tweets are deleted too.

Let's click save and then save again to apply that change. Now, we can insert a new tweet with the title hello, and then select a record from our profiles table, which is our signed in user, and then click save to insert that new tweet.

Now our application is still showing the value null, so we still need to fix up our code. Now, rather than the auth.users table, we want the profiles table. Then rather than email, we can just grab all of the columns.

Then back over in our application, we're seeing the correct data for our tweet, but our profiles are null. This is because we've created these new profiles table and we've enabled RLS, but we haven't written a policy. Let's create a new policy.

We're going to create this from scratch. We want to enable read access for profiles. We want to enable the select action for all roles with the condition true. Let's click review and then save policy.

Then back over in our application, when we refresh, we see the profile data for the user that created that tweet. Now back over in our application, if we have a look at this tweets variable, doesn't really know much about our profiles and that's because we've changed our database schema.

We just need to run our Supabase CLI command to generate our TypeScript types. Now, we're back to full type safety across our application.

https://app.egghead.io/api/v1/lessons/postgresql-automatically-generate-a-profile-for-every-user-with-postgresql-function-triggers/transcript

https://app.egghead.io/api/v1/lessons/supabase-run-authenticated-server-side-mutations-with-next-js-server-actions/subtitles

https://app.egghead.io/api/v1/lessons/supabase-run-authenticated-server-side-mutations-with-next-js-server-actions/transcript

https://app.egghead.io/api/v1/lessons/postgresql-create-a-postgresql-join-table-in-supabase-studio/subtitles

Instructor: Let's add a like button for each of our tweets. Rather than just pretty-printing out our array, let's take our array of tweets and map over them. For each tweet, we want to render out a div with its key set to our tweet's ID.

Inside here, let's have a paragraph with our tweet.profiles.name and our tweet.profiles.username, and then another paragraph with our tweet.title. We can see some red squigglies here because TypeScript is not happy. Our tweets could be null. We can use optional chaining here to say, only map over it if it's an array.

Tweet.profiles is also possibly null. Our good friend, optional chaining, can help us out again, and for this name, for this one and for this one. Now, if we go back to the browser and refresh, we'll see each tweet with its author's name, their username and the contents of the tweet. Let's add a like button. For this, we're going to create a new table for likes.

From the Supabase dashboard, go to the Table Editor and then New table. The name of this one is going to be likes. We're going to leave row level security enabled, and then we're going to make the created_at column not nullable and add a new column for user_id, which we're going to set up with a foreign key relationship to the profiles table pointing to the id column.

When that profile is removed, we want to cascade those deletes through to this likes table. Let's click Save to set up that relationship. We're going to click this cog and untick Is Nullable as it doesn't make sense for there to be a like without a user. Let's add another column for the tweet that this user is liking.

Again, we're going to set up a foreign key relationship to the public schema and the tweets table, referencing the id column, and set up cascade deletes. Let's click Save on that one, make this one not nullable and click Save to create our likes table.

Now, we want to be able to insert new rows into this table to represent a user liking a particular tweet and delete rows from this table to represent a user unliking a tweet. Let's enable those two actions with RLS policies. Under Authentication and then Policies, we want to create a new policy on the likes table. We'll create this one from scratch.

Our policy name is going to be, authenticated user can like tweet. It's going to enable the INSERT action. We're going to target the authenticated role, and again, we want to make sure that the user_id column for this like matches the user that's trying to perform this action. They're not trying to like a tweet as another user.

Now we can click Review and then Save policy. Then create another policy from scratch. This one's going to be, authenticated users can delete their likes. We're going to enable the DELETE action targeting the authenticated role and checking that the user_id column matches this user's ID. Let's review and save this policy.

So that our application can display those likes, we're going to need a select policy. We're going to create this one from scratch as well. The policy name is going to be, anyone can select likes. It's going to enable the SELECT action. We want this to apply to all roles, and we want our condition to be true. Let's click Review and then Save policy.

Now we have a likes table which we can insert, delete and select values from.

https://app.egghead.io/api/v1/lessons/postgresql-create-a-postgresql-join-table-in-supabase-studio/transcript

https://app.egghead.io/api/v1/lessons/supabase-implement-dynamic-buttons-with-next-js-client-components/subtitles

Instructor: [0:00] Let's display the data from our likes table in our Next.js application. Let's start by creating a new component in the app directory called likes.tsx. Because we're going to be clicking buttons and things, we need this to be a client component. We can then export a default function for Likes. For now, we're going to return a button that says Likes.

[0:21] Then back over in page.tsx, let's render our Likes component which comes in from ./likes. Then over in the browser, we can see our Likes button underneath each tweet. Let's fetch the number of likes for each of our tweets.

[0:35] Back up where we're making a request to supabase for all of our tweets, we're selecting all columns from the tweets table. Then because we have a foreign key relationship with profiles, we can get all of those as well. Since we have a relationship with the likes table, we can also grab all of those columns.

[0:49] Where we're rendering our Likes component, we can pass this one a tweet prop which is set to the current tweet we're iterating over. Then in our Likes component, let's get that tweet, and then, let's console.log out our tweet so we can see what it looks like. Because this is a client component, we can see it in the browser's console.

[1:09] Our Likes are currently an empty array. We can use the length property to show how many likes each tweet has. Back over in our code, we can remove this console.log. Then before the word Likes, let's render out our tweet.likes.length. Now we can see that both of our tweets have  likes.

[1:26] Let's wire up incrementing the likes by clicking the button. Since this is a client component, we can use an onClick handler and set this to a handleLikes function which we can declare above, so handleLikes is an async function. Firstly, we're going to need a supabase client which we can get by calling the createClientComponentClient function, which comes in from our auth-helpers package.

[1:49] Then we want to await a call to supabase. From the likes table, we want to insert a new like. We're going to need a user_id and a tweet_id. Since we have this tweet prop, we can get our tweet.id, and we can get our user_id from our supabase client. Let's say const data, and destructure our user from awaiting a call to supabase.auth.getUser. We can then get our user_id from user.id.

[2:19] Since user may be null, we want to wrap this call to supabase in an if statement that checks that we do have a user. Now, if we go back to our application and click one of our Likes, we see nothing happens, but if we refresh, the Likes for our tweet have incremented.

[2:33] Let's refresh that data automatically, which we can do with a router which we get back from the useRouter hook, which comes in from next/navigation. Then after we've inserted our new like, we can call router.refresh.

[2:47] Now, back over in the browser, we can increment the Likes for either of our tweets, and continue incrementing them, but hang on, a user should only be able to like a particular tweet once. Clicking the Like button again should decrement it rather than increment. Let's remove those likes from supabase and refresh our application. We're back to a clean slate of  likes.

[3:07] Back over in our application, we need to detect whether this user has already liked this tweet, and then either increment the value or decrement it. Back up in page.tsx, when we get back our list of tweets, we also get every instance of a like. Rather than aliasing this data prop to tweets, let's create a new array for our tweets which can be equal to mapping over our data.

[3:29] Then for each of those tweets, we want to construct a new object with all of our tweet data, and then a new field for user_has_liked_tweet, which we can get by calling tweet.likes.find. For each of those likes, we want to find a like with a user_id field that matches our session.users.id, which is in scope from our redirection logic above.

[3:53] Since we're transforming our tweets array into a convenient shape, we can also set our likes property to be a tweet.likes.length. We only want to do this if we actually have data, and if we don't, we just want an empty array. We'll see TypeScript is not happy, so we'll fix that soon.

[4:09] For now, over in our Likes component, we can render out our tweet.likes, which is now a number, rather than needing to get the length of the array. Then to check whether we want to increment or decrement the number of likes, we can add another if statement to check. If the tweet.user_has_liked_tweet is true, then we want to dislike, otherwise, we want to insert a new Like.

[4:32] To dislike the tweet, we can await a call to supabase. From the likes table, we want to delete the row where there's a match on the user_id column and our users.id, and the tweet_id column matching our tweets.id. Now, if we go back to the browser and like one of our tweets, we can see it increments to 1, and if we click it again, it decrements.

https://app.egghead.io/api/v1/lessons/supabase-implement-dynamic-buttons-with-next-js-client-components/transcript

[Ampt](https://getampt.com/) lets developers rapidly build, deploy, and scale JavaScript/TypeScript apps in the cloud without complicated configs or managing infrastructure.

In this quick lesson we're going to learn:
- What is [Ampt](https://getampt.com/)
- How does it simplify our development workflow by configuring and provisioning infrastructure for us
- How to install @ampt/cli
- How to create a new Ampt project by choosing a TypeScript express API template
- How to iterate on a newly created API by taking advantage of Ampt's fast feedback loop.


https://app.egghead.io/api/v1/lessons/supabase-declare-global-intersection-types-for-transformed-supabase-data-with-typescript/subtitles

Create a serverless API with Ampt and TypeScript

[00:00] According to AMPed landing page, it is the fastest way to get things done in the cloud. The whole idea is that AMPed lets developers rapidly build, deploy, and scale JavaScript applications in the cloud

[00:14] without messing with complicated configs, managing infrastructure, logging into AWS console, and so on. So the whole promise is that we are going to get all the power of the cloud with none of the complexity. And this small example shows AMPed developer experience.

[00:31] So we can see that we can import many modules from AMPed SDK, including HTTP. We can use well-known frameworks and libraries, such as Express.

[00:42] And with a single line, AMPed is going to figure out what kind of infrastructure does it need to provision in the cloud for us to get the server up and running. So again, we don't have to think about the cloud. The only thing that we need to think about is what kind of behavior we want to implement. Here's another example.

[01:01] Suppose that we have some kind of business logic that we would like to execute every hour. So we can import tasks from AMPed SDK. And if I scroll down a little bit, we can see that we can create an instance of a task and have it execute every hour.

[01:15] And again, AMPed is going to provision, configure, and figure out how exactly do we run a task every hour using AWS. The only part that we are actually responsible for is our custom business logic. With all of that, let's get started.

[01:32] First of all, we need to go ahead and install the AMPed command line interface. Once this is done, I'm going to go ahead and run AMPed. And this is going to open a new browser tab, which we can see over here. So I'm going to go ahead and click on Confirm. And now we need to sign in. So I'm going to sign in with Google.

[01:49] And my device is now connected to AMPed. So I'm going to create a new directory for my project, which I'm going to call my Egghead AMPed API. I'm going to cd into it and run the AMPed command again. Do you want to create a new app? Yes, I do. And we have a number of templates to choose from. So there are templates for JavaScript.

[02:08] There are templates for TypeScript, Fastify, Koa, Hono, many frameworks like Astro, Next.js, Remix, Angular, so many to choose from. I'm going to go ahead and choose the TypeScript API Express and hit Enter. Next, enter a name for your app. I'm going to go ahead with my Egghead AMPed API.

[02:27] After a while, we can see that AMPed has generated a brand new app for us. And we can see our app in the dashboard over here. So let me go ahead and click on that link. And here we can see the overview of our app. So we have an active sandbox, which is deployed to AWS in the US East 1 region. And currently, there isn't much happening here.

[02:46] But we can see that we can use schedules and tasks and events and storage and many other things in our AMPed applications. So let's go to the code editor to see what exactly was deployed to AWS. So this is the project that was generated for us.

[03:01] And if I open up the index.ts file, we can see that this file is creating an express server. We are also importing HTTP module from AMPed SDK. Over here, we are defining three different routes. So there's a route for hello, greet slash name. There's also a post submit.

[03:18] And over here, we are passing the express app to AMPed in order for it to do its magic. Let's go back to the terminal for a second. Here we can see that AMPed has provisioned a personal sandbox for us.

[03:29] A sandbox is your own personal development workspace that automatically syncs and deploys changes from your local environment into the cloud in under a second. Let's give it a shot. So I'm going to go ahead and copy that. And I'm going to test the hello route. So it should respond with a 200 and a message hello from the public API.

[03:48] So let me just go ahead and hit that. API slash hello. And here it is. Hello from the public API. So I'm going to modify it to hello, egghead, friends from the public API. I've saved those changes. We can see that AMPed has successfully updated our code in a few seconds.

[04:07] And if I hit this endpoint again, we can see that those changes were deployed. And for the record, this part of the video is not edited. Let me just go ahead and add some more characters over here. Save. Go ahead. Hit this endpoint again. And we can see that our code changes were already deployed into the cloud.

[04:26] So in addition to getting all of our infrastructure configured for us in AWS cloud, we also get a very fast feedback loop.

https://app.egghead.io/api/v1/lessons/supabase-declare-global-intersection-types-for-transformed-supabase-data-with-typescript/transcript

https://app.egghead.io/api/v1/lessons/next-js-implement-optimistic-ui-with-the-react-useoptimistic-hook-in-next-js/subtitles

Instructor: When a user clicks the Like button, there's a little bit of a delay before this value is updated. This is even more noticeable if we go to the Network tab, then throttle down to Fast 3G and then click one of our buttons. You'll see there is a noticeable lag before that value changes to a 1.

Since we already know the current number of likes and whether that number should go up or down, we can update the UI optimistically rather than waiting for that value to change in supabase. Let's start by moving the rendering logic for our tweets to a new component which we want to create in the app directory.

We'll call it tweets.tsx, and we'll export our default function for Tweets. This is going to take a tweets prop. We can declare the type for tweets, it's going to be a TweetWithAuthor [] . Then in our component, we want to return our rendering logic. We need to import our Likes component from ./likes. We know tweets is going to be an array, so we can get rid of our optional chaining.

Now, up in page.tsx, we can render our Tweets component which comes in from ./tweets. We then need to pass it a tweets prop which is going to be the tweets that we got back from supabase. Now, if we go back to the browser, we should see nothing has changed.

To implement our optimistic UI, we're going to import the experimental_useOptimistic hook from react. Then, so that we don't need to change much of our code, when this becomes stable, we can alias this to useOptimistic.

Now, since we're using client-side hooks, this component needs to be a client component. Let's add the use client directive as the first line of our component. Then in our component, when we call the useOptimistic hook, we get back an array with the first value being our optimistic collection. In this case, that's going to be optimisticTweets. We then get back a function to add an OptimisticTweet.

We need to provide it the initial value. In this case, that's going to be our tweets. Then we declare a callback function which gets passed our current list of OptimisticTweets, and then the newTweet that contains our changes. Then in the body of this function, we need to specify how to merge these two values.

In our case, we want this newTweet to replace the old version of this Tweet in the array. Let's start by creating a new variable for our newOptimisticTweets. We're going to use the spread operator to take a copy of our currentOptimisticTweets. Then we want to find the index of the old version of this Tweet.

We can create a new variable for our index and set that to newOptimisticTweets.findIndex, which is going to run over each tweet. Then we want the index of the tweet where the id matches our newTweet's id. Now that we have the index of the old tweet, we can say, newOptimisticTweets at the index of the old tweet. We want to replace it with our newTweet.

Then we need to return a new value for our OptimisticTweets. We can return our new array of OptimisticTweets. TypeScript is very unhappy, so let's correctly type our useOptimistic hook to say, the type of our collection is going to be a TweetWithAuthor [] , and our new tweet is going to be a TweetWithAuthor.

Now, this may look a little intimidating. To recap, we passed it our initial value for our tweets, we then declared a function to say how we want to merge our newTweet into our list of Tweets, then we get back this optimisticTweets value, and then a function we can call any time we want to change the state of a Tweet.

Let's use our optimisticTweets array for a collection we're iterating over to display on the page. If we go back to the browser, this should look exactly the same. When we click this button, that's when we want to change the number of likes.

If we have a look at our Likes component, that will be in this handleLikes function, just before we make a call to supabase to either remove a Like or insert a new one. Let's pass down a new prop for addOptimisticTweet, which will be set to our addOptimisticTweet function. Then our Likes component is going to receive an addOptimisticTweet function.

The type for this one is going to be a function that receives our newTweet, which is of type TweetWithAuthor. It doesn't return a value, so we can specify void. Then before we make our call to supabase, we want to call our addOptimisticTweet function and pass it the new state of our tweet. We can spread in our current tweet, and then overwrite the value for likes.

In this case, we're decrementing the value. That'll be tweet.likes-1. We also need to change the state for whether our user_has _liked_tweet. We can negate the current value for our tweet.user_has _liked_tweet. Now, if we go over to the browser, we can see that when we're unliking a tweet, it's instantaneous, but when we're liking a tweet, we have to wait for that value to update in the database.

Let's make our likes optimistic as well. We can copy this block, and then before we insert a new like, we first want to increment that number of likes. Back over in the browser, we can see that liking and disliking are now instantaneous.

https://app.egghead.io/api/v1/lessons/next-js-implement-optimistic-ui-with-the-react-useoptimistic-hook-in-next-js/transcript

https://app.egghead.io/api/v1/lessons/next-js-dynamically-update-ui-with-database-changes-using-supabase-realtime/subtitles

Instructor: Our application shows all the tweets that were available when we navigated to this page. If someone puts up a new tweet, we won't see it in our UI until we refresh. Let's subscribe to changes in the tweets table so our UI remains in sync with the database.

Over in the Supabase dashboard, we want to go to Database and then Replication. Then under supabase_realtime, we want to click 0 tables and enable replication for the tweets table. This tells Supabase to send us all updates about the tweets table, which we can then subscribe to in our tweets component.

Let's use useEffect which comes in from react. This takes a callback function that we want to run when our component mounts, so we give it an empty dependency array. Now we need a supabase client to set up this subscription. Let's declare that outside our useEffect by calling the createClientComponentClient function which comes in from our auth-helpers package.

Then inside our useEffect, we can get a channel by calling supabase.channel. The name of this one can be anything. I'm going to call it realtime tweets. We then say, on postgres_changes. The name of this one is important, needs to be all lowercase and with an underscore.

We can then pass a filter to say the event that we want to know about is *. This is, insert updates and deletes. The schema is going to be public, and the table is our tweets table. We then give it a callback function which supabase will call any time there's a change detected on the public.tweets table. It will pass in a payload which represents what's changed.

Let's console.log that payload for now, and then we call subscribe. This gives us back a channel which we want to unsubscribe from when our component is no longer mounted. We can return an arrow function and call supabase.removeChannel, and pass it that channel variable.

Now, if we go over to the browser, open up the console and add another tweet, we'll see our payload in the console. If we open this up, we can see more information about what's happened. What our eventType is, this one was an INSERT. We can also see the new record that's been inserted. This gives us the information from the tweets table.

If we wanted to use it to update our UI, we'd also need the author's name, their username, and the number of likes for this particular tweet. Rather than trying to stitch all of that together in our callback function, we can just call router.refresh, and we can get an instance of the router above by calling the useRouter hook, which comes in from next/navigation.

Now, because the callback function has been triggered, we know one of the rows in the tweets table has changed. By calling router.refresh, it's going to reload our server component, which is going to fetch fresh data from supabase, then transform it into the shape that we want in our application and pass it down to our Tweets component, which is then adding all of our optimistic UI logic.

The last thing we need to do is fix up our dependency array on our useEffect because we now have a dependency on the router as well as supabase. Let's add those to the dependency array.

Now, back over in the browser. If we have our Jon user on the left, and our Cooler Jon user on the right, if either of them put up a new tweet, both UIs are updated immediately without needing the user to refresh.

https://app.egghead.io/api/v1/lessons/next-js-dynamically-update-ui-with-database-changes-using-supabase-realtime/transcript

https://app.egghead.io/api/v1/lessons/tailwind-style-a-twitter-clone-with-tailwind-css/subtitles

https://app.egghead.io/api/v1/lessons/tailwind-style-a-twitter-clone-with-tailwind-css/transcript

https://app.egghead.io/api/v1/lessons/deploy-next-js-app-router-project-to-production-with-vercel/subtitles

Instructor: Let's deploy our Next.js application to Vercel. Back over in our code, we have localhost:3000 hard-coded in our auth-button-client and our github-button. Our auth flow will only work when running locally.

We can make this value dynamic based on the environment that we're running in by using backticks and then replacing our localhost origin with our location.origin. Let's copy this value across to our github-button and replace our callback URL. Now, if we quit our development server and run npm run build, and if we scroll up a little bit, we can see some errors printed to the console.

If we go all the way to the top, we can see this, cannot resolve encoding in the node-fetch library. This one's an easy fix. We can run npm install or i and then -D for a dev dependency, and install that encoding library.

Now, if we run npm run build again, we're left with this DYNAMIC_SERVER_USAGE error which is saying that it's detected that we're using our cookies function in a route it expected to be static. This is because server components are cached and static by default, but we're using this cookies function to create our authenticated supabase client.

We can tell Next.js that this route is intentionally dynamic by exporting out a const variable for dynamic and setting this to the string force-dynamic. We can copy this value, and then do a find across our project for anywhere we're using our cookies function. Then in each one of these components, exporting out our dynamic variable set to force-dynamic.

Now, if we run npm run build again, we'll see we have no errors printed to the console. We're ready to push our code up to GitHub and deploy to Vercel. Let's run git add . to stage our changes, and then git commit with a message, "deploy app". Now we need a GitHub repository to push these changes too. Let's go to github.com and click New to create a new repository.

Our name is going to be blue-bird. Then if we scroll down, we don't want any of these. Let's create our repository. Now, copy this value, and then back in our project. We want to run git remote add origin and then paste in our value. Now we can push up our changes with git push origin main. If we go back to our GitHub repo and refresh, we'll see our project has been pushed up.

Let's head over to vercel.com to add a new project. I've signed in with my GitHub account previously, so it has access to all of my repos. Once you've done that, we can import our blue-bird project, which it has detected is a Next.js project. We need to set some environment variables. We can copy these across from our .env.local file.

We can select all, then copy and then paste directly into this input box to automatically populate our SUPABASE_URL and also our SUPABASE_ANON_KEY. Let's deploy our application. We can see confetti falling from the sky because we've successfully deployed our project. We can click this little preview here to go through to our deployed application, which in my case is blue-bird-seven.vercel.app.

Let's copy our Production URL. Then back over in GitHub, click your avatar, then go to Settings, then scroll down to Developer settings at the bottom, then OAuth Apps, select our Blue Bird app, then scroll down to our home page URL and replace this with our Production URL from Vercel. Let's click Update application.

Now, over in our Supabase project, let's go to Authentication, then URL Configuration, change our Site URL to our Production URL from Vercel and click Save. Now, if we go to the production version of our application and click our GitHub logo to sign in, we can see all of our tweets and like the ones we think are funny.

If we're signed in as different users, we can see when one of those adds a tweet, like, "The Supabase brand color should be purple." We'll see it shows up at the top of our tweets for both users without needing to refresh.

https://app.egghead.io/api/v1/lessons/deploy-next-js-app-router-project-to-production-with-vercel/transcript

Build a Twitter Clone with the Next.js App Router and Supabase

Jon Meyers

Free Community Resource

You might also like these resources:

Build a Realtime Chat App with Remix and Supabase

Cache Supabase data at the Edge with Cloudflare Workers and KV Storage

Free Community Resource

Course Content

You might also like these resources:

Build a Realtime Chat App with Remix and Supabase

Cache Supabase data at the Edge with Cloudflare Workers and KV Storage