> Do the functions "freeze" once the response body has been sent back?
Just checked with the Deno team. These functions should not be used as "background workers" - perhaps that is something we explore in the future. It will work for a short time in theory, but it's not guaranteed.
> How does keeping a connection pool work between function invocations
Supabase offers several options here. You can either use the API (PostgREST)[0] - an autogenerated REST API, or the connection pooler (pgbouncer)[1] which we offer with every project.
> For example using Prisma
Supabase is a popular database hosting service for Prisma users because of the built-in pooling - it's a great product, especially their typed interface.
> These functions should not be used as "background workers"
Thanks for checking on it. We actually had to create a Cloudflare worker based "fire-and-forget" system to allow our Vercel functions to shoot off background tasks. Was hoping to replace that.
> Supabase is a popular database hosting service for Prisma
Agreed! We actually use Supabase as our backend for Willow[1] and use Prisma when writing backend functionality. It's been a real easy and fast process to use Supabase's JS client on the frontend to access data (with RLS!) and then Prisma+Supabase on the backend to modify data (with types!). We would love to allow user's to directly change data everywhere directly from the browser but we need to do some background tasks (sending notifications or updating related rows).
The dream would be to have a great DX experience around using insert/update triggers to call Supabase functions to run background tasks. Some type of Terraform-esque configuration (in a SCM) to set it up and keep it in sync would be awesome. We have some triggers that make http calls but we're limiting usage as keeping track of them outside of our other code isn't simple.
> The dream would be to have a great DX experience around using insert/update triggers to call Supabase functions to run background tasks
We have something for this: Function Hooks (soon to be renamed "Async Triggers")[0]. They are still in alpha, but the extension [1] is getting close. It was important to build something which works with PG background workers so that it's non-blocking. We'll make quick progress on this now that we've released Edge Functions.
> sending notifications or updating related rows
Tune in for tomorrow's announcement - it's related.
TBH the average user would be confused if their autoscaling workers were "online and billed for" if some random npm package or a coding accident had "background behavior". Firing off a background task into something similar to AWS SQS is really the right way for this scenario to be handled.
Just checked with the Deno team. These functions should not be used as "background workers" - perhaps that is something we explore in the future. It will work for a short time in theory, but it's not guaranteed.
> How does keeping a connection pool work between function invocations
Supabase offers several options here. You can either use the API (PostgREST)[0] - an autogenerated REST API, or the connection pooler (pgbouncer)[1] which we offer with every project.
> For example using Prisma
Supabase is a popular database hosting service for Prisma users because of the built-in pooling - it's a great product, especially their typed interface.
[0] PostgREST API: https://supabase.com/docs/guides/api
[1] pgbouncer: https://supabase.com/docs/guides/database/connecting-to-post...