This is the first in a series of articles on my experience using the Supabase platform instead of writing a backend server. I put "serverless" in quotes, because some would consider Supabase to be a server. From my perspective, I'm not writing a server in the traditional sense. I'm defining tables and other components in a database, and the rest is handled for me, authentication, the API, object storage, and more.
The first several articles will cover setting up the PostgreSQL database that is supplied with your project. After that, I'll dive into the other components of Supabase.
My project
I'm creating a new website that contains several entities, e.g. users, groups, members, events, attendees. Naturally I started writing a server in one of my favorite languages, Python. I've used Django and Flask in the past, but decided to try FastAPI for this project due to its everything-included style of defining an API.
For the frontend, I wanted to try Svelte. I've used Angular and React professionally and found both of them to be cumbersome. Svelte (plus its framework counterpart SvelteKit) feels lightweight and simple while delivering amazing performance.
So there I was writing the frontend in Typescript plus the backend in Python and constantly context switching between two very different languages, when it dawned on me that eventually I would need to find a hosting platform for the server. SvelteKit provides an amazingly simple path for deploying a production-ready site on Vercel and other platforms, but standing up a FastAPI server + SQL database looked like it was going to be difficult. And that's when I ran across Supabase.
Why Supabase?
Supabase is similar to Firebase, but based on open-source technologies. You can even stand up your own Supabase server if you want. So in theory no lock-in with a single vendor. At its core a Supabase project is a PostgreSQL database with some extensions to provide an API, authentication, object storage (based on AWS S3), logging, and other basic services. It also provides a very nice administration console to interact with your project and data.
And yes there is a free tier so you can get started with your project without spending a fortune.
Why not Supabase?
Once you start investigating, you will very quickly have one more more of the following questions or concerns:
Where's the server code?
Short answer: there isn't any.
Using the full power of PostgreSQL plus some open-source extensions and a few other services, writing a traditional web server isn't necessary. You don't have to write, test, optimize, host, deploy, monitor, and update all that code. Yes you will have to learn some new technologies and write some SQL and probably some PostgreSQL functions, but that will be far easier than creating and maintaining an entire server architecture.
Why not use SvelteKit's server?
That is certainly an option for my project, and a pretty good one. However, where is that server going to run? Where is the database? They should be very close together to minimize data lag, and ideally running on the same host. And the usual coding steps (write, test, optimize, etc.) will still be required.
Is Supabase better than Firebase?
I haven't tried using Firebase. I did look at Pocketbase, which is another open-source backend platform written in Go. These platforms seem to rely on row-level security (the next few articles in this series cover RLS in depth). The issue with Firebase is that the RLS policies are written in a proprietary language. Same with Pocketbase. Which locks you into those platforms. Supabase uses PostgreSQL RLS, so you could host your own PostgreSQL database and use the same policies. Same issue for functions you need to write (a later article covers writing functions).
And that's the advantage of a platform that is based on open-source technologies. No lock in.
Row-Level Security (RLS) looks hard.
Like many technologies, RLS takes a while to grasp. But once you understand the basics you'll realize how it will greatly simplify your application while maintaining tight security of your data.
Check out the other articles in this series for an introduction to writing and testing RLS policies.
The JS client library queries don't look very powerful.
Good news! You don't have to use them. Personally I prefer to work with SQL. Every database library I've ever used attempts to make things simple, but instead increases the complexity.
Instead write PostgreSQL SQL functions (or even write the functions in Javascript!) and call them via supabase.rpc('function_name', {param1: 'value'});. Or it's even simpler to write Postgres Views, but be careful because by default run they may use an elevated security context.
What if some fields have different visibility?
Separate the fields into separate tables based on their visibility. For example, in my application for events the name is public but the location is only visible to group members. Create a one-to-one relationship between the tables and create separate RLS policies for each. Is that a little convoluted? Perhaps. But it's much simpler than writing an entire backend server.
How can I test the server?
Since you no longer have a server, you just need to test your database. Supabase supports pgTAP for writing database tests, but I personally found it much easier to write client-side tests against the database using test data. Check out the article for more info.
Can I use GraphQL?
Yes. I haven't personally tried it, but [Supabase supports the GraphQL extension for PostgreSQL].(https://supabase.com/blog/graphql-now-available).
I need cron jobs.
Check out the pgcron extension. I also haven't used this yet, but seems like it will work fine for my needs.
Conclusion
Hopefully this article is piquing your interest in using Supabase for your next project. Follow along in this series for more articles on using Supabase and PostgreSQL.
And please comment with any questions or concerns you had while considering or using Supabase.
(I have not been compensated by Supabase in any way for these articles. I'm just a customer that is very happy with the service so far.)
Top comments (0)