I built an app with Supabase and I liked it

I built a tiny "Tweeter-like" 👉 app where most of the backend is handled in Supabase 🤠. It was super fast, and the DX was great!

Every Supabase project comes with a full Postgres database, which is free and arguably one of the most popular and powerful open-source databases. Authentication is handled via RLS (Postgres Row Level Security), and Supabase Auth was designed to work seamlessly with it.

TLDR - you can skip the middle man and query the database directly from your client. The classic 3 piece flow is 👤Client 🤝 ☁️API 🤝 🐘Database, but here you can skip the API in the middle and send the auth token across from the 👤Client to the 🐘Database, which will use RLS to determine if the user has access to the data or not.

RLS is a feature in 🐘PostgreSQL that grants control over user access to CRUD operations on specific rows within tables and views, via a set of rules, called policies, that you can attach to a table and that gets executed every time a table is accessed. One way to think about RLS policies is like a WHERE clause in SQL or .filter in JS.

For example, this policy

CREATE POLICY "Authenticated users can delete their likes."
ON likes
FOR DELETE
USING (auth.uid() = user_id);

would get translated into a query like

DELETE FROM likes
WHERE auth.uid() = likes.user_id; -- Policy is implicitly added.

Another example would be that you could set up constraints on a tweet_post table to ensure that users can only UPDATE rows where their unique user_id corresponds to the value in the table's author_id column.

Some advantages of setting up an app this way

When building applications, the method in which we interact with the database can have a big impact on both performance and security

• Querying the database from the client directly can make our queries more ⚡️ efficient because we don't need to take that extra trip through the ☁️API.

• But we could also prevent ourselves from writing some bad logic in our API and leaking data from the database. By writing the access rules directly in the database it makes it harder to leak out data because only the users that should have access to it can have access.

Anyways, back to the app

• I bootstrapped the thing in Next.js 14 @latest, 'cause, why not, even sprinkle some server actions like here in the code for adding a new tweet
• set GitHub auth, add tables and policies in the Supabase dashboard
• add UI components and set Supabase helpers, to be able to query the database
  • createClientComponentClient —  in Client Components
  • createServerComponentClient —  in Server Components
  • createServerActionClient —  in Server Actions
  • createRouteHandlerClient —  in Route Handlers
  • createMiddlewareClient —  in Middleware
• style it a bit with Tailwind, add a few entries, and 🪄 ✨ done

Have a look at the deployed app(GitHub login required) and check out the code for details.

Conclusion

It was a pretty fun experience to build the app, with really powerful tools and great DX and I recommend you try out the stack for yourself 🤓. Somee parts of the setup were done in the actual Supabase dashboard, which you would have to set up in your account. Folks over Egghead.io have a great tutorial where Jon Meyers takes you through the flow of building an app very similar to this one 👌.

Take care, and most importantly, have fun coding! 🤘