4 ms·

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. Thi

by ovao 4y ago

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.

helsontaveras18 4y ago
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.
- easton 4y ago
  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.
  - ovao 4y ago
    Lambda@Edge is a great solution for the locality problem (CloudFront can just route to the nearest edge function, and despite certain headaches, it works well), but what it doesn’t help to solve is the cold start problem. In a sense Lambda@Edge works against it, as provisioned concurrency is only supported for ‘regular’ Lambda functions. At a certain level of scale, the cost of spinning of an ALB Fargate task (which could run these servers relatively easily) ends up being relatively negligible. Although that’s certainly not true for every org.
- ovao 4y ago
  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.

by ovao 4y ago

helsontaveras18 4y ago

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.

easton 4y ago
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.
- ovao 4y ago
  Lambda@Edge is a great solution for the locality problem (CloudFront can just route to the nearest edge function, and despite certain headaches, it works well), but what it doesn’t help to solve is the cold start problem. In a sense Lambda@Edge works against it, as provisioned concurrency is only supported for ‘regular’ Lambda functions. At a certain level of scale, the cost of spinning of an ALB Fargate task (which could run these servers relatively easily) ends up being relatively negligible. Although that’s certainly not true for every org.
ovao 4y ago
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.