3 ms·
> They invented Another Cloud Thing, namely Lambda@Edge, to solve this. Yes, designed for usecases like those handled by Cloudflare Workers, which boil down to
by fivea 5y ago
> They invented Another Cloud Thing, namely Lambda@Edge, to solve this.
Yes, designed for usecases like those handled by Cloudflare Workers, which boil down to updating data cached in edge servers without requiring global redeployments or pinging a central server. We're talking about stuff like adding timestamps to images or adding headers to HTTP responses or pre-rendering some HTML or emit CDN-aware metrics.
> Now you can run a JS function for every single request that hits your CloudFront Distribution
Not exactly. Lambda@Edge are event handlers from CDN events. You use them when they suit your needs.
> so that you can run logic in there to strip the prefix before it gets passed to your origin.
Your strawman example doesn't even feature among the dozen examples provided by AWS regarding how to use Lambda@Edge.
Everyone is free to come up with silly ideas and absurd examples, but if you design systems around braindead ideas then that says a lot about you and nothing about the tools you chose to abuse
> You read that right! Execute code every time a request hits your proxy!
Yes, that's what web servers do. What exactly is your point?
> But wait, doesn't executing code for every single request sound insane
It doesn't. That's what a web server does. Moreso, Lambda@Edge (and Cloudflare Workers too) only do it if you explicitly decide to make them do it, to match precisely what you tell them to do.
What point are you trying to make, exactly?
> AND doesn't it also add latency which this was trying to remove?
It does. It adds tens of milliseconds when the alternatives can add hundreds of milliseconds. You're also expected to do basic engineering work and do basic performance work when seeking performance improvements, such as measuring things instead of mindlessly jumping on bandwagons without caring for the outcome.
> Isn't cloud just lovely?
I feel your comment manifests too much cinicism to cover too much ignorance on a topic you are not familiar nor understand the basic premise.
- herpderperator 5y agoYou shouldn't be so stern. The use case I provided is AWS's recommended way to solve this problem[0]. :) > Yes, designed for usecases like those handled by Cloudflare Workers, which boil down to updating data cached in edge servers without requiring global redeployments or pinging a central server. We're talking about stuff like adding timestamps to images or adding headers to HTTP responses or pre-rendering some HTML or emit CDN-aware metrics. > Not exactly. Lambda@Edge are event handlers from CDN events. You use them when they suit your needs > Your strawman example doesn't even feature among the dozen examples provided by AWS regarding how to use Lambda@Edge. For all of these counterpoints, see [0]. > Everyone is free to come up with silly ideas and absurd examples, but if you design systems around braindead ideas then that says a lot about you and nothing about the tools you chose to abuse I take it you are directing this particular comment at AWS considering they are recommending this solution? [0] > Yes, that's what web servers do. What exactly is your point? Don't be daft. You know what I mean. Obviously web servers execute code. In this case the web server (CloudFront Distribution) is passing the request to yet another "thing" which happens to be a JS function that is invoked specifically to handle something web servers like nginx were built to do extremely efficiently on their own. CloudFront could easily support this without additional dependencies that add complexity to your system design and introduce additional failure modes. In this case, I am making your point for you: using Lambda@Edge for this IS ridiculous, but that's the AWS way. > It doesn't. That's what a web server does. Moreso, Lambda@Edge (and Cloudflare Workers too) only do it if you explicitly decide to make them do it, to match precisely what you tell them to do. > It does. It adds tens of milliseconds when the alternatives can add hundreds of milliseconds. You're also expected to do basic engineering work and do basic performance work when seeking performance improvements, such as measuring things instead of mindlessly jumping on bandwagons without caring for the outcome. Sorry for not writing a detailed blog post to describe all of my findings. FYI, the latency added with Lambda@Edge caused my request time to double and added much more variance. I'm surprised a lot of your counterpoints are just blaming me for doing the wrong thing, when this is actually what is recommended by AWS. Invoking a custom function to process the request. See [0]. Of course the right solution is to use nginx (but then you lose out on AWS scaling) or completely redesign your system to fit another solution like API Gateway. From AWS's blog: > In this scenario we can use Lambda@Edge to change the path pattern before forwarding a request to the origin and thus removing the context. For details on see this detailed re:Invent session. [0] [0] https://aws.amazon.com/blogs/architecture/serving-content-using-fully-managed-reverse-proxy-architecture/ https://aws.amazon.com/blogs/architecture/serving-content-us...