It is extremely easy to start using Supabase. Create a project, create a table, copy the URL and key into the app and start writing data. That is enough for a prototype. It is not quite enough for a project I want to keep working on.
For a long time, when I heard “backend”, I imagined a server somewhere running all the time. You deploy an application to it, configure the database connection, keep the process alive and worry about the machine underneath. The more side projects I build, the less often my backend actually looks like that.
Webhooks sounded complicated to me mostly because the name makes them sound like some special kind of technology. They are basically HTTP requests sent in the opposite direction.
For a small project, using the same backend while developing and running the live application is incredibly convenient. It is also something I now try to avoid. The problem becomes obvious as soon as development involves anything destructive. Maybe I want to reset some data, test a migration, create hundreds of fake records or run a script that recalculates something for every user.
While designing a simulation-heavy application, I started thinking about what would happen if every user had their own version of thousands of objects that changed over time. The naive solution is easy: copy everything for every user and update it whenever something changes. It also sounded like a good way to create an enormous number of database reads and writes.
At some point almost every app needs to do something when nobody is actively using it. Send a weekly email, refresh some data, clean up old records or generate a report every Monday morning. My first instinct used to be that this meant I needed a server running permanently somewhere.
The more features I add to an app, the more often I run into the same question: should this logic live inside the application, or somewhere on a backend? At first I thought about frontend and backend mostly in terms of screens versus databases. The frontend displays things, the backend stores things.
While building an app, it is very tempting to put everything directly into the code at first. It is fast, there is nothing else to configure, and for a prototype it often feels completely reasonable. I did the same thing with ingredient data in a cooking app I was experimenting with.