examples/todo-list/nextjs-todo-list/README.md
The Vercel deployment will guide you through creating a Supabase account and project. After installation of the Supabase integration, all relevant environment variables will be set up so that the project is usable immediately after deployment 🚀
Sign up to Supabase - https://supabase.com/dashboard and create a new project. Wait for your database to start.
Once your database has started, run the "Todo List" quickstart. Inside of your project, enter the SQL editor tab and scroll down until you see TODO LIST: Build a basic todo list with Row Level Security.
Go to the Project Settings (the cog icon), open the API tab, and find your API URL and anon key, you'll need these in the next step.
The anon key is your client-side API key. It allows "anonymous access" to your database, until the user has logged in. Once they have logged in, the keys will switch to the user's own login token. This enables row level security for your data. Read more about this below.
NOTE: The service_role key has full access to your data, bypassing any security policies. These keys have to be kept secret and are meant to be used in server environments and never on a client or browser.
cp .env.production.example .env.productionSUPABASE_ENV=production npx supabase@latest link --project-ref <your-project-ref>
SUPABASE_ENV=production npx supabase@latest config push
SUPABASE_ENV=production npx supabase@latest db push
Supabase integrates seamlessly with Vercel's preview branches, giving each branch a dedicated Supabase project. This setup allows testing database migrations or service configurations safely before applying them to production.
Ensure the Vercel project is linked to a Git repository.
Configure the "Preview" environment variables in Vercel:
NEXT_PUBLIC_SUPABASE_URLNEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEYCreate a new branch, make changes (e.g., update max_frequency), and push the branch to Git.
This project uses very high-level Authorization using Postgres' Row Level Security.
When you start a Postgres database on Supabase, we populate it with an auth schema, and some helper functions.
When a user logs in, they are issued a JWT with the role authenticated and their UUID.
We can use these details to provide fine-grained control over what each user can and cannot do.
This is a trimmed-down schema, with the policies:
create table todos (
id bigint generated by default as identity primary key,
user_id uuid references auth.users not null,
task text check (char_length(task) > 3),
is_complete boolean default false,
inserted_at timestamp with time zone default timezone('utc'::text, now()) not null
);
alter table todos enable row level security;
create policy "Individuals can create todos." on todos for
insert with check ((select auth.uid()) = user_id);
create policy "Individuals can view their own todos. " on todos for
select using ((select auth.uid()) = user_id);
create policy "Individuals can update their own todos." on todos for
update using ((select auth.uid()) = user_id);
create policy "Individuals can delete their own todos." on todos for
delete using ((select auth.uid()) = user_id);
Supabase is open source. We'd love for you to follow along and get involved at https://github.com/supabase/supabase