Why does it seem like

Lambda@Edge

is a completely under-rated, under-used, u*nder-appreciated* but absolutely ⭐ AMAZING flexible, multi-use AWS service? Here are my thoughts for why that might be… 1. I’m missing something and there is something serverless that is way better, cheaper, easier. 2. It’s a complete nightmare to develop with despite its usefulness. a. CFN can’t delete them without failing once and waiting 2 hours. b. Finding the CW logs is a game in itself. “Which region are they in today?” c. Deploys require waiting for the CF distro to completely propagate. Why not have a dev-mode that only propagates to the closest edge location fast and then the others later. 3. None of the CFN frameworks allow for live/local editing of edge functions, even though all support the same with standard lambdas. (CDK, SST, SLS, SAM etc) I’m either missing some very amazing serverless alternative, or can AWS Lambda team fix the above limitations so that we can all start to LOVE this amazing service?

what do you use it for?

• SSR • _redirects file in S3 as redirect/rewrite/proxy • Image Resize+Cache Service (Cloudinary in 100 lines of code) • A / B Testing SSR alone opens up a huge treasure trove of amazing solutions and features and for pennies. 🪙

ah makes sense, SSR is definitely an area of inexperience for me (at least recently). Most of the things I've worked on have been heavy client side apps, which definitely is probably uncommon

JAMStacks are our go-to. But MANY challenges around SEO, Perf, and Social Links without SSR. So we use crack-filling services like prerender.io etc to fix some of that. Again, I would bet many of those services are using edge functions under the hood.

yeah I'd opt for SSR for most things nowadays

Here’s my take against Lambda@Edge: 1. An edge platform that needs a CDN in front of it is no edge platform at all 2. An edge platform that can’t stream bytes is no edge platform at all 3. An edge platform with the same burst and concurrency limitations as the non-edge variant is no edge platform at all This might sound harsh but I’m saying this as someone who has tested Fastly Compute@Edge and Cloudflare Workers extensively. Both of the platforms correctly have the cdn behind the edge platform. This is a weird concept but it makes a dramatic difference. It means your functions get to run on all requests and you get full streaming ability. Lambda@Edge can’t stream at all so you need to do image resizes, compression, etc. in the lambda (with limitted RAM) or rely on features from Cloudfront being in front of the lambda

@Andrew Barba Ya that seems like valid concerns for your needed solution. For us, streaming functions is not really something we need. I’d be happy with simple SSR solution that doesn’t require a server.

For what its worth: a little birdie told me Lambda is getting true streaming Q2/Q3 this year

my issue with edge functions is I find them hard to fit into my architecture

Totally. And all the platforms know this. Until a proper (affordable) edge database comes into play this is going to be a major stopper for typical API workloads. The edge platforms are awesome at read-only, stateless validation, etc.

@thdxr ah… ya again… not something we’ve wanted to do. I guess our main interest with EdgeLambda is less about “edge” and more about SSR, dynamic server responses etc. Less about the “perf” of edge, although thats great too.

For what its worth: a little birdie told me Lambda is getting true streaming Q2/Q3 this year

PLEASE and thank you. This is my #1 biggest issue using Lambdas versus Workers. Also agree with the statement about the worker being in front of the CDN and general issues with Cloudfront being unweildy compared to alternatives though.

You could always just deploy a 13-region API Gateway + Lambda if Lambda@edge is annoying you. It amounts to the same thing, besides the flexibility of before/after cache, and has none of the limitations and annoyances. (You mentioned Vercel above, and this is actually what they do for SSR, not Edge, besides maybe their new “middleware”) I wanted to love them too, but when push comes to shove, I almost never choose them over standard lambdas. I have chosen cloudfront functions in more cases than them.

@Derek Kershner would love to know more about how you can use APIG and lambda to do the same. I think the before the “origin” (s3) is what I need. So that you can setup redirects, rewrites and proxy’s. Also SSR. So if you have something, I’d love to hear more details. At this point it’s not even the “edge” or multi region I’m after.

The first three are squarely in CloudFront territory, and should be left where they are. Although, I struggle to come up with a scenario where you couldnt fully unit test a lambda that does rewrites or redirects and would require live infrastructure...

@Derek Kershner ah you mean to do

CDN -> APIG -> Lamnda -> S3

? Something tells me that would be significantly slower (distro cache aside) but definitly worth a test.

I don’t know about significant, @Dan Van Brunt, Http

APIG

is basically the only difference and it is pretty quick. Both have CDNs, both have a lambda run, both query S3 the same way.

@Derek Kershner do you have something in production doing this now?

Not for SSR (we only use Next.js due to requiring some of the advanced features), but in the past I have only made a 13-region API (and Dynamo), something where worldwide low latency was important, and chose this pattern over edge. It’s very consistent in terms of worldwide performance, but I didn’t do comparisons vs edge.

hmmm…. @Derek Kershner so why don’t we setup NextJsSite to use this method and forget Edge functions?

I am pretty sure it is because the SST gang doesn’t want to fully break from the Serverless constructs (I don’t blame them, Next.js might be the most complex to deploy framework I have ever come in contact with, so many features) The Serverless guys have the idea in alpha, but its really slow. @Frank may know more.