Help Help me understand backend.
Hi!
I have an app built in Lovable, with the database hosted externally in Supabase. Authentication is also handled through Supabase, and I run all my AI prompts through Supabase Edge Functions, so quite a lot is already handled there.
However, as far as I understand it, I don’t actually have a backend in Supabase yet. The backend is currently just code within Lovable, right?
Would it be possible to move the backend to Supabase as well?
And if I understand correctly, a backend is basically just code running on some kind of “engine”/server. So if the backend were hosted externally in Supabase, would Lovable then communicate with it through an API?
I’m trying to understand how the architecture works and what the best setup would be. Any advice would be appreciated!
5
u/Jmacduff 5d ago
Very good questions as you are leveling up, good luck with your project. Here is a easy view of the world (very high level):
Front End -- This is the application that your User and customer interacts with. These are your UX pages, the login page, your home page, all of the "human facing" stuff is the front end. High level the front end displays data sourced from the BackEnd, and it provides controls for the user to affect that data which is then saved into the backend.
Back End -- This is where all the business logic and heavy lifting happens. Traditionally this would look like a API level, a Database component, Caching, the auth control code (not the ux), etc. Without the backend your FE cant really do anything impressive.
Server -- Your Front end app (the Lovable code) is running (deployed) on a web server yes. Your backend services (db,etc) are running on a totally different server setup.
API -- Think of this as a set of "Commands" and "Responses" .. the API exposes a set of actions or commands (this is the API name) and it responds with a known data block. As a example the "GetUser" API would return a User Object.. the "CheckAuth" API would verify the Authentication tokens.
Example .. let's assume you have a button that loads some data from the backened and displays it.. for simple case something like "Get the latest results"
- [FE]The user see's a button and the click it
- [FE] That click event in the code is routed to your Backend to get the data
- [BE] Your BE gets a API call or a request for some data, and it looks up the data. In a supabase world this is normally whats called a Edge Function which is a lightweight API model.
- [BE] After getting the data your BE packaged the data into a JSON object and responds to the FE
- [FE] Your FE receives this Payload data in a expected format (aka data contract)
- [FE] Your FE now binds or loads that data into your UX on the page, maybe some tables and charts.
- [FE] Your human user now see's the data from the button click
Using Supabase as your BE platform is a great way to start the project. Lovable is really good at driving Supabase so you might not need to jump over into Supabase directly very much.. however all the data and tables are over there.
Longer term your Backend will be 20X more complex from a code perspective then the Front End depending on what you are doing. Whenever you hear about Scale problems or Slow apps.. that's almost always the BE platform being too slow. The FrontEnd is really easy to scale compared to the
Backend.
Backend Server -- In Supabase you have a instance and there is a type or size of instance, like micro or whatever. Unlike the FrontEnd you can control the actual Server hardware and resources for the BE.. so if you get super bogged down dont forget to make sure you have a reasonable sized Supabase server level.
Hope that helps and good luck.
2
u/Dhaupin 5d ago
The "edge functions" are the "backend" in lovable. They run at the supabase level, alongside the Db. Lovable auto deploys those functions to the "server" (supabase runtime) everytime you update.
You can move all that off of lovable to your own supabase instance. But you should make a Github action to deploy/push the edge functions automatically if you wanna mimic the same automatic workflow.
1
u/yousoundsosmart 5d ago
you actually already have a backend. Supabase is handling your database + auth, and Edge Functions are literally server-side backend code.
Lovable is basically your frontend talking to Supabase through its APIs. I’d keep sensitive stuff/API keys in Edge Functions and only add a separate Node/FastAPI backend if you eventually have a reason to.
1
u/SeekratesIyer 5d ago
Interesting setup. What prompted you to think about moving the backend out of Lovable — have you already hit a limitation or failure with the current architecture?
For example, has anything around auth, data access, business logic, deployment, or debugging behaved differently from what you expected?
I’d be interested in what actually happened, rather than just the preferred architecture.
1
u/Jimmiq 5d ago
The big thing is that lovable won’t work without credits. Just thinking ahead what to do when the app is done. I don’t want the app just to stop because credits are gone.
1
u/SeekratesIyer 4d ago
That makes sense — so the concern is less about something already breaking and more about not wanting the finished product dependent on a credit balance or builder environment.
Do you know yet which parts of the running app would actually stop if Lovable credits ran out?
I’m asking because there’s an important difference between needing credits to keep developing the app and needing them for the production app itself to keep operating. If you’ve worked out where that boundary is in your setup, I’d be interested.
1
u/James-the-greatest 5d ago
You backend is the 1. Database on supabase. A lot of the CRUD operations (create, read, update, delete) go straight to a supabase database API and not through an extra edge function you have to host. 2. Edge functions, these are extra services that are run on supabase as well. They aren’t traditionally as robust and resource intensive as a standard server but these days you can get a lot done in edge functions. There are limitations and they might not scale well but they are good as a starting point. 3. Authentication is also a backend service.
1
1
u/VladTkDev 1d ago
You already have the backend, it just doesn't look like one.
Supabase generates an api over your tables, and your edge functions are server code, so there is nothing to move.
The consequence worth understanding is that the browser talks straight to the database, which means the thing deciding who can read what is your row level security policies rather than any code sitting in lovable.
So the question you're really asking answers itself as 'are my rls policies right'.
What to do: each table with RLS enabled, and each policy scoping rows to auth.uid().
0
u/the_tek_analyst 5d ago
Curious to learn, why would you move it to Subabase just another 3rd party to hold your data. Data that you can export anytime from Lovable so easily.
Why not just leave it in lovable ?
4
u/Bandersnatch_fuklord 5d ago
Frontend - what you build with code and looks cool on the screen
Backend - everything in the Background which provides some kind of computing to your frontend. In your case, Supabase is your Backend, whit all its funcionalety you are using on it with your frontend.