Live data from Hacker News

Supabase Edge Runtime: Self-Hosted Deno Functions

supabase.com

71–80 of 105 posts

Re: Supabase Edge Runtime: Self-Hosted Deno Functions

#71
post #65

How about WASM functions? One of Deno's selling points is sandboxing but WASM takes it to a new level it seems. I've been looking into Spin and also Dapr with WasmEdge. There is even QuickJS which does JavaScript.

[Supabase engineer & author of the blog post] You can already use WASM modules within Edge Functions. We have an example on using WASM modules to generate OpenGraph images - https://github.com/supabase/supabase/tree/master/examples/ed... We are also exploring ways to create functions in WASM-supported languages and run them directly on Edge Runtime. We expect this would be easier WasmGC[0] is shipped and Deno's WASI…

[deleted]

Re: Supabase Edge Runtime: Self-Hosted Deno Functions

#72
post #56

Earlier quoted context omitted.

Congrats on the launch! I’ve been so underwhelmed with Lambda’s lack of forward progress lately and have been wanting to play around a bit with V8 isolates. This looks like a super-easy way to get a runtime spun up and handling requests on AWS.

Open question: what are the benefits of replacing Lambda with this new service, if you’re not using any other Supabase functionalities? Our Lambdas are currently written in Typescript and built with esbuild. We zip them and push to AWS.

These would boot faster since you don’t have to boot a whole OS, just a V8 VM. Downside is compatibility, your lambdas would have to be largely rewritten (especially if they rely on any other AWS services). It’s also probably more expensive since you’d have to keep a EC2 or something up running this.

Kinda wish Amazon would have an alternative runtime that was more like this. They kinda do with lambda@edge, but that’s only for CloudFront stuff, mostly.

Re: Supabase Edge Runtime: Self-Hosted Deno Functions

#73
post #29

just use a regular server for mid/larger sized apps. i started my web dev journey with JAMStack, Vercel, the "edge". everything is easy as long as one only deploys a full-stack NextJS app. the moment other apps come in, just use a server deployed as VPS and avoid "edge runtime hell". edge runtime hell refers to "you can't do this (function with over 2MB payload), you can't do that (because not supported by X)". EDIT:…

I have stuck with cheap VPS servers for as long as I can remember. It takes 5 minutes to deploy a full stack node.js app, along with a database - and I've yet to exhaust the resources on my VPS, even with all my side projects (production grade and hobby stuff). Have always found it weird how so many heroku-style hosting providers charge _per app_, things get costly, quickly, when you have lots of small apps like I do…

I think I want to do the same. Can you describe your stack please? How much downtime do you get and how do you deal with app updates and system updates to the vps machine itself? What about monitoring?

Re: Supabase Edge Runtime: Self-Hosted Deno Functions

#74
post #29

Earlier quoted context omitted.

I have stuck with cheap VPS servers for as long as I can remember. It takes 5 minutes to deploy a full stack node.js app, along with a database - and I've yet to exhaust the resources on my VPS, even with all my side projects (production grade and hobby stuff). Have always found it weird how so many heroku-style hosting providers charge _per app_, things get costly, quickly, when you have lots of small apps like I do…

These PaaScost an arms and a leg and each one have their own DSL u have to learn. Easiest is to just provision ur own vps and run a docker-compose or k8s

Who needs a DSL when you can just have a massively nested undocumented yaml file?

Re: Supabase Edge Runtime: Self-Hosted Deno Functions

#75
post #20

just use a regular server for mid/larger sized apps. i started my web dev journey with JAMStack, Vercel, the "edge". everything is easy as long as one only deploys a full-stack NextJS app. the moment other apps come in, just use a server deployed as VPS and avoid "edge runtime hell". edge runtime hell refers to "you can't do this (function with over 2MB payload), you can't do that (because not supported by X)". EDIT:…

I'm coming around to building everything for a VPS from the outset. There's a lot of upside to VPSes, such as: 1. Can be purchased as a fixed cost, usually at a rate that's much cheaper than on-demand pricing, and especially serverless--this tends to only get better with time as competition keeps prices low 2. It's "just" a Unix/Windows/Mac box, so the issues with runtime constraints you mention are bounded different…

If VPSs had the same marketing and maybe a bit more polished standard tooling I have a feeling it would quickly gain traction and simplify life for most people. As well as prevent vendor lock-in, of course.

It’s in the SaaS business model. The incentives, even for fully open source like supabase, is misaligned with self-hosting. Even if they’re super honest and trying to be helpful, their fully managed globally available offering is going to have very different needs than self-hosters.

I actually more like the model of having FOSS where the company behind it offers consulting instead, to build, deploy and operate the product for customers who lack the in-house expertise. It’s not perfect, but it helps align the incentives towards simplicity.

Re: Supabase Edge Runtime: Self-Hosted Deno Functions

#76
post #44
post #40

Earlier quoted context omitted.

Any details about the removing of Kong? What did you use it for and how will this help with removing it?

We use Kong as our API Gateway, so it is responsible for authentication, rate limiting, routing, etc. By moving that to edge runtime, we simplify our stack since we already run a edge runtime container to run user functions. The other motivation for doing this is that it makes our API Gateway programmable with user defined functions. For example, you could implement custom transformations for storage or augment the A…

This is really exciting Inian. I’ve long felt that api gateways are one of the heavier and more complex parts of the modern infra stack and the work you’re doing to make this more self hostable is laudable!

Re: Supabase Edge Runtime: Self-Hosted Deno Functions

#77

does any one have good practical experience running Supabase locally? Its against their business model to have this run well so I'm a bit scared of the growing lock-in. (P.S. if Supabase is listening some customers like myself would be willing to pay a significant amount for support in a kubernetes/docker deployment running on our servers. We currently pay $50k - $100k simply for enterprise support contracts for each…

I have run self hosted Supabase for awhile in Kubernetes. One of the main gotchas I will warn against is becoming too attached to the CLI, as it’s currently quite tied to assumptions that you’re using hosted Supabase.

Also be prepared to do your own infra work if you want something scalable and production ready. The HA guarantees are kind of “bring your own” eg not really there out of the box and IMO the default docker compose setup provided, while thorough and working, serves as more of a proof of concept of the system than something you should actually be running in production.

Re: Supabase Edge Runtime: Self-Hosted Deno Functions

#78
post #56

Earlier quoted context omitted.

Congrats on the launch! I’ve been so underwhelmed with Lambda’s lack of forward progress lately and have been wanting to play around a bit with V8 isolates. This looks like a super-easy way to get a runtime spun up and handling requests on AWS.

Open question: what are the benefits of replacing Lambda with this new service, if you’re not using any other Supabase functionalities? Our Lambdas are currently written in Typescript and built with esbuild. We zip them and push to AWS.

The largest advantage currently (in my opinion) is with respect to cold starts. Lambda has gotten significantly better over the years, but cold starts are still a concern, largely because it’s difficult to anticipate the level of needed provisioned concurrency needed to mitigate it. Not having to think about that at all would be a large advantage (I’m ignoring Lambda SnapStart since it’s strictly limited to Java at this time).

It’s also the case that there’s just so much historical baggage within Node, mainly with regard to CJS. Developing against Deno at least presents the opportunity for us to move past that and improve DX.

Re: Supabase Edge Runtime: Self-Hosted Deno Functions

#79

This is the third big release this week (along with a Postgres Pooler and a Logging Server). If you're wondering why there are so many, we generally "build for three months" then do all of our big product announcements in a "Launch Week". We're 2 days into this Launch Week so there will be a few more releases to come.

I think this is great, but a growing question in my mind from these is what is the long tail plan for maintenance of this constellation of stuff? Especially because you guys are building on technologies that you can’t really just casually find developers for eg Elixir and Haskell. I keep seeing missing critical features in Realtime and Postgrest, and I know these are armies of 1-2, but it does kind of worry me when I think about investing time and effort into the Supabase ecosystem as a whole seeing more and more launches while there isn’t much action on existing issues.

Example: https://github.com/PostgREST/postgrest/issues/915#issue-comm...

Re: Supabase Edge Runtime: Self-Hosted Deno Functions

#80
I’ve been using Deno Deploy as as a paying customer for the last year, both because I want to support what they’re doing and because I appreciate the amazingly tight deployment times.

That said, it’s suffered for the lack of access to the file system or dynamic imports which makes things like MDX challenging without adding additional build steps.

Do Supabase Edge Functions allow read/write file system access? What about dynamic imports?

Post reply on HN