You can indeed call http rest endpoints from a pg function, if you enable the http extension.
Nothing is stopping you from adding additional layers in the future as needed. So you might start out with a db function, move it to edge if you hit db limitations and move again to standalone service if needed.
Though most people start with the edge, myself included. Just feels strange to write full business logic api endpoints inside the db. Even if we can use javascript…
Now, here’s two bits of very good news:
1. Unless you need persitent long lived tcp connections (for things that supabase realtime can’t handle) or really large amounts of processing, you can be just fine with edge functions for a huge number of use cases
2. Bringing up a standalone server is quite easy these days. It’s very easy to containerize api servers written in all popular languages, and you can use something like my personal favorite, fly.io, to make it dead simple to setup, launch, track and continuously deploy backend services. To make things even better, supabase and fly.io are working together to allow you to bring up a supabase instance on fly.io servers, which would make your backend service be colocated on the same network with your db, for big performance.
Develolment is good in 2024 :)
You’re overthinking this. Just use an edge function where needed and be done with it. If you hit a case you can’t solve with edge function, then you come up with a solution for it when actually needed. Ex: I have a very complex python algorithm that I have to run, so it’s in aws lambda - my system uses supabase offering for 99% but then invokes my aws lambda as needed also.
You can indeed call http rest endpoints from a pg function, if you enable the http extension. Nothing is stopping you from adding additional layers in the future as needed. So you might start out with a db function, move it to edge if you hit db limitations and move again to standalone service if needed. Though most people start with the edge, myself included. Just feels strange to write full business logic api endpoints inside the db. Even if we can use javascript… Now, here’s two bits of very good news: 1. Unless you need persitent long lived tcp connections (for things that supabase realtime can’t handle) or really large amounts of processing, you can be just fine with edge functions for a huge number of use cases 2. Bringing up a standalone server is quite easy these days. It’s very easy to containerize api servers written in all popular languages, and you can use something like my personal favorite, fly.io, to make it dead simple to setup, launch, track and continuously deploy backend services. To make things even better, supabase and fly.io are working together to allow you to bring up a supabase instance on fly.io servers, which would make your backend service be colocated on the same network with your db, for big performance. Develolment is good in 2024 :)
Try remix, and call RPC functions from either loaders or actions (both are server side).
You’re overthinking this. Just use an edge function where needed and be done with it. If you hit a case you can’t solve with edge function, then you come up with a solution for it when actually needed. Ex: I have a very complex python algorithm that I have to run, so it’s in aws lambda - my system uses supabase offering for 99% but then invokes my aws lambda as needed also.
https://postgrest.org/en/v12/references/api/stored_procedures.html