Hey, thanks for sharing this on HN! I'm one of the Edge Functions developers at Supabase and co-author of the blog post. We are very excited about releasing npm support and looking forward to seeing how the community build awesome apps with the Supabase stack.
I am happy to answer any questions or receive feedback.
how deep does the support go? i.e. can we safely import from node platform builtins like `os` or are the same bundling gymnastics still required there? (fwiw this is one of the major issues with vercel's edge funcs)
Most builtin modules should work (except for things like `vm` which we cannot safely sandbox in edge runtime). Deno has a good guide on the compatibility of built-in modules https://docs.deno.com/runtime/manual/node/compatibility
You can do:
```
import os from "node:os"
console.log(os.hostname())
```
and it should just work both locally and when deployed. No extra steps needed.
this is the #1 feature request from our community wrt Edge Functions. Our Functions run Deno, and so a lot of developers struggle to migrate from Node. This update solves that. It was a lot of work - in the words of one of the developers: "the hardest thing I have implemented".
It's nice because it brings 100% feature parity across local dev, the platform, and self-hosting.
We also added a Sentry integration for observability and "Regional Invocations" for connecting to a Function in one particular region (useful if you want to execute a Function close to your database).
I'm just clocking off but the engineer who shipped this is waking up and will be around for any technical discussion.
Do you support Prisma? I don't recommend using Drizzle because their migrations tool is completely proprietary and closed source, but they bundle it with their open source offering in a bait and switch.
Prisma is going to significantly improve support for edge functions soon. We are compiling our Query Engine to WASM, and have already added support for Serverless APIs from PlanetScale and Neon.
Great, I paused my project just waiting on this issue
These last months open source has churned out several projects that are components to what I'm experimenting on and it feels great to be able to build on top of solid projects
Vercel edge functions are Cloudflare Workers under the hood. I'm pretty sure Supabase is using Deno Deploy/Subhosting. There's a lot of nuance to comparing these two offerings but in short what I'd say is if you like the supabase platform offerings with all the tightly integrated goodies than you will likely benefit way more from going with Supabase functions.
Vercel is increasingly trying to offer all these integrated goodies too but imo right now most of them are off-the-shelf things like "a postgres db" (powered by neondb platform) a "kv redis store" (powered by upstash) and they seem to be betting their user's want to use their own pg/redis cli's & sdk's to manage & access the data from the edge functions (versus supabase's sdk's which unify auth, db, functions, etc.).
Both options do have their benefits but if you want everything tightly integrated with a friendly management UI, sdk & auth Supabase can save you tons of time!
In terms of speed I still think nothing beats cloudflare workers (way more geographically distributed points of presence so even closer to more users). However I think vercel's edge functions only use a subset of the total cloudflare workers PoPs. But I highly doubt the average use-case or user would ever notice the difference in latency between cloudflare workers & supabase edge functions so i don't know if that should be your determining factor. (And let's not get started on the debate of "edge doesn't matter if it's far from your db". If supabase is doing any magic to make their edge functions "close" to the db that's a huge win!)
Another option is to go full cloudflare ecosystem (they too have a kv store & now a limited sql db) but, again, I do not think their ecosystem gives you the all-in-one goodness that supabase does (no auth offering, definitely no way to tie together db/kv/auth with one sdk/management dashboard).
Yet another option is to go with fly.io + tursodb. Like deno & cloudflare workers they have their own geographically distributed PoP's that run lightweight, optimized firecracker vms running any of your dockerfile desires. With this you get even more freedom and control but you also need to get your hands a bit dirty in flyio's cli & platform magic. Also while turso is super interesting it's very new and they seem to be pushing more of a "have a database per user" than "host one giant multitenant db".
I have compared all these offerings, weighed the pros / cons. In the end don't let it paralyze you! Nearly all these offerings have enough standardized pathways in and out of them (or similar standard protocols like sql, postgres protocol, exports, cf runtime even has limited node/npm support for instance) to where lock-in should not too big a fear in the beginning. Worst case try to write abstractions for db-access, auth-hooks, kv-access, maybe runtime-specific logic so that you can adapt the abstraction to benefit app-wide if you ever need to migrate to another runtime/db.
We have a cluster of Edge Runtime instances in each region. We run multiple edge functions within an instance using v8 isolates (Deno's core runtime is a wrapper around v8 isolates). This setup provides a good balance between cost and security. Other edge hosting providers like Cloudflare also follow a similar setup.
I am happy to answer any questions or receive feedback.