21–30 of 68 posts
It feels the CDN edge functions are the new Jamstack. It's fast but comes at a high cost and the excitement shifted from static pages to literally data distributed near the user.
> Serverless compute options can be broken down into two broad categories: > Containers as a Service (e.g. Google Cloud Run, Fly.io) > Functions as a Service (e.g. Cloudflare Workers, Fastly Compute @ Edge, Suborbital) There are also Google Cloud Functions, which is odd to not mention here. For what I'm working on, I've put CF Workers in front of my GCF's. This allows me to terminate the SSL at the CF Worker (along w…
Amazing work, kudos to the Supabase team! > However, Supabase already offers a flexible solution for that - Database Functions! As such, for Supabase [Edge] Functions, we decided to deploy far-and-wide so that they are as close to your end-users as possible. Does this mean that a choice has to be made between high latency (Edge Functions) and specialised SQL-only functions (Database Functions)? I see that cron-like t…
We are also exploring running Deno directly inside your database - https://github.com/supabase/postgres-deno
Awesome! Congrats for shipping! 90% of the projects I work on are built on Firebase, our main worry with that is that we are locked-in, not only to "Firebase", but to Google as well which has a nasty history of just pulling the rug from under your feet without even telling you why. Having alternatives to try and implement is always a priority for us and Supabase now (w/ edge functions) seems to cover most of our use…
I am curious how the edge functions can replace Firebase?
Auth + Storage + Functions is all we really need, and that triad is now complete on Supabase.
1) Do the functions "freeze" once the response body has been sent back? Is it possible to return a response to the user (for a quick API response) and then continue doing some background work? This is has been a source of pain with AWS Lambda based services like Vercel that freeze execution once the response has been sent.[1]
2) How does keeping a connection pool work between function invocations? For example using Prisma for the nice typed DB functions.
[1] https://vercel.com/docs/concepts/limits/overview#streaming-r...
Amazing work, kudos to the Supabase team! > However, Supabase already offers a flexible solution for that - Database Functions! As such, for Supabase [Edge] Functions, we decided to deploy far-and-wide so that they are as close to your end-users as possible. Does this mean that a choice has to be made between high latency (Edge Functions) and specialised SQL-only functions (Database Functions)? I see that cron-like t…
Just to double-up on Inian's comment - there is definitely a world where this happens, perhaps even inside the database itself (like plv8). We were focused on the Edge experience this time, but I'm excited about the future that an open-source TS runtime like Deno enables.
> I dream of a world where database schemas, functions, security access and the rest can be saved to source control for reproducibility
this was one of the main reasons we started supabase. we hope to make database development as easy as application development
Two questions: 1) Do the functions "freeze" once the response body has been sent back? Is it possible to return a response to the user (for a quick API response) and then continue doing some background work? This is has been a source of pain with AWS Lambda based services like Vercel that freeze execution once the response has been sent.[1] 2) How does keeping a connection pool work between function invocations? For…
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...
Two questions: 1) Do the functions "freeze" once the response body has been sent back? Is it possible to return a response to the user (for a quick API response) and then continue doing some background work? This is has been a source of pain with AWS Lambda based services like Vercel that freeze execution once the response has been sent.[1] 2) How does keeping a connection pool work between function invocations? For…
> 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 (…
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.