Module 6 Exercises — Full CRUD + auth with user isolation
Your app is about to get a memory and real user accounts. The skill checks cover the must-know API and the one security rule that matters most; the real-work challenges wire up your own database and auth.
Quick skill checks
One right answer each — paste Claude's output and grade yourself instantly.
The key that must never leak
Supabase gives you two keys. One is safe in the browser; the other must stay server-only and never go in a NEXT_PUBLIC_ variable. Name the dangerous one (two words).
Read from a table
In the Supabase JS client, you read rows like this: supabase.from('tasks').____() . Which method goes in the blank to fetch rows?
Reason over your data
Here's a tasks table. Paste it into Claude and ask how many tasks are still NOT done. Enter the number.
tasks id | title | done 1 | Buy groceries | true 2 | Email landlord | false 3 | Renew passport | false 4 | Call dentist | true 5 | Pay invoice | false
Take it to your real work
No single right answer — this is where the value is. Use your own material.
Create a real table with RLS on
In Supabase, create a table your app needs (e.g. tasks or notes). Enable Row Level Security and add a policy so users can only see their own rows. Connect it to your app using the anon key in .env.local.
Win: Data persists across refreshes, RLS is ON, and the service_role key is nowhere near your client code.
Add sign-up and per-user data
Ask Claude to add email/password auth (signUp, signInWithPassword, signOut). Then make the data user-specific: a logged-in user only sees rows they created. Test it with two different accounts.
Win: Two accounts see two different sets of data — your app now has real users.