4 ms·

I don't want to argue that the feature should be built in (and most importantly free, because that's something you forgot to mention, those lamdba functions are

by forty 5y ago

I don't want to argue that the feature should be built in (and most importantly free, because that's something you forgot to mention, those lamdba functions are paid for each run) but > doesn't executing code for every single request sound insane How would you strip some url path without executing code for every single request? It could be code you did not write, but some code is always needed to do something. If latency of lamdba@edge is an issue, you can try CloudFront functions, which should be better for small tasks like this (though I don't have any experience with them as we switched to a similar competitor)

9dev 5y ago
I don't know. This doesn't feel like something that should require edge logic. nginx handles this with a single rewrite directive, so I'd expect some part of the AWS routing layer to have a setting to rewrite the URL accordingly. OTOH, AWS can't and shouldn't account for every edge case, probably.
- spullara 5y ago
  A rewrite directive is just writing code.
  - 9dev 5y ago
    Rewrite directives handled by low-level routing logic of the web server are definitely different to a container image that gets spun up in a distributed network and queried for each request, don't you think?
    - scubbo 5y ago
      Not really, no. In fact the only significant difference (that the Lambda@Edge function is run at the closest geolocation to the client, rather than on the origin server) is an advantage to Lambda@Edge. What difference are you alluding to?
      - pas 5y ago
        A HTTP URI path prefix mapping is done in nginx, in the same process, no context switching, no buffering, I think it is even done without any allocation. Of course it doesn't matter, basically logging takes more resources than whatever routing is needed. (Especially because even if it requires running a Cloudflare worker it's just a NodeJS V8 isolate, very lightweight. As far as I know. But I have no idea of its costs.) But AWS Lambdas are pretty pricey compared to a free nginx rewrite.
        dragonwriter 5y ago
        > But AWS Lambdas are pretty pricey Kind of why CloudFront Functions we're invented for this use case, AWS Lambda@Edge is the more general purpose edge computing facility.
    - dragonwriter 5y ago
      > Rewrite directives handled by low-level routing logic of the web server are definitely different to a container image that gets spun up in a distributed network and queried for each request, don't you think? I’m pretty sure Lambda@Edge is not a container image like regular Lambda (why it only supports JS and not the broader set of Lambda runtimes) and is relatively local to the edge environments serving CloudFront anyway (why it is support in CloudFront the way regular Lambda isn't, and what the @Edge part refers to.)
    - fivea 5y ago
      > (...) are definitely different to a container image that gets spun up (...) I'm not sure you're making a informed observation. "Spinning up a container image" is just fancy jargon/handwaving to refer to launching a process, which is something nginx already does under the hood in a myriad usecases without warranting complains from users. > and queried for each request, don't you think? I'm not sure if either you framed your sentence poorly or you don't have a clear idea about what you're talking about. In AWS lambda, you don't "spin up containers" at each request. You launch your lambda once it's deployed or when it scales up, and it stays up as long as you see traffic.
      - 9dev 5y ago
        Poor phrasing, then. Meant to say a container is started once, then queried on every subsequent request. And what I’m talking about is not the user-facing lambda, but what AWS does on the infrastructure layer below, which involves running a containerised process on firecracker VMs, communicating via HTTP. There was a great summary of how AWS works a while ago, going into way more detail, that I sadly can’t find anymore. But there’s definitely more work involved in calling a lambda function than forking a process in nginx.
herpderperator 5y ago
CloudFront Distributions cannot pass the request to CloudFront Functions before sending to the origin. In other words, they cannot be used to modify origin request/responses. They can only modify the viewer request/responses. [0] Only Lambda@Edge can help the scenario which I provided, which is also AWS's recommended solution. [1] [0] https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope... [1] https://aws.amazon.com/blogs/architecture/serving-content-using-fully-managed-reverse-proxy-architecture/ https://aws.amazon.com/blogs/architecture/serving-content-us...
- ep103 5y ago
  Personally, I did it with templates in api gateway, as at least then I'm not paying for the cpu time to do these sorts of manipulation. But yes, stuff like this made me really shake my head at 'the cloud'
- forty 5y ago
  From your link [0] "URL redirects or rewrites" is a supported use case. For stripping /api/ from the path, I don't know what would be the benefit of doing it at the origin request, rather than at the viewer request? Cloudfront functions are pretty new, so some older docs might still reference lamdba@edge only.
  - herpderperator 5y ago
    The origin request is your backend. The viewer request is the one you're requesting from the client. You want the viewer to have /api. You want the origin to not have /api. Therefore stripping must be performed on the origin request, which is not supported by CloudFront Functions.
    - forty 5y ago
      Both the viewer request and origin request hook both happen early enough that you can update the path See https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/images/cloudfront-events-that-trigger-lambda-functions.png https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope... I have used lamdba@edge and our primary use case was to rewrite url (to add languages information for example) so I'm sure it works in viewer request events.

by forty 5y ago

9dev 5y ago

I don't know. This doesn't feel like something that should require edge logic. nginx handles this with a single rewrite directive, so I'd expect some part of the AWS routing layer to have a setting to rewrite the URL accordingly. OTOH, AWS can't and shouldn't account for every edge case, probably.

spullara 5y ago
A rewrite directive is just writing code.
- 9dev 5y ago
  Rewrite directives handled by low-level routing logic of the web server are definitely different to a container image that gets spun up in a distributed network and queried for each request, don't you think?
  - scubbo 5y ago
    Not really, no. In fact the only significant difference (that the Lambda@Edge function is run at the closest geolocation to the client, rather than on the origin server) is an advantage to Lambda@Edge. What difference are you alluding to?
    - pas 5y ago
      A HTTP URI path prefix mapping is done in nginx, in the same process, no context switching, no buffering, I think it is even done without any allocation. Of course it doesn't matter, basically logging takes more resources than whatever routing is needed. (Especially because even if it requires running a Cloudflare worker it's just a NodeJS V8 isolate, very lightweight. As far as I know. But I have no idea of its costs.) But AWS Lambdas are pretty pricey compared to a free nginx rewrite.
      - dragonwriter 5y ago
        > But AWS Lambdas are pretty pricey Kind of why CloudFront Functions we're invented for this use case, AWS Lambda@Edge is the more general purpose edge computing facility.
  - dragonwriter 5y ago
    > Rewrite directives handled by low-level routing logic of the web server are definitely different to a container image that gets spun up in a distributed network and queried for each request, don't you think? I’m pretty sure Lambda@Edge is not a container image like regular Lambda (why it only supports JS and not the broader set of Lambda runtimes) and is relatively local to the edge environments serving CloudFront anyway (why it is support in CloudFront the way regular Lambda isn't, and what the @Edge part refers to.)
  - fivea 5y ago
    > (...) are definitely different to a container image that gets spun up (...) I'm not sure you're making a informed observation. "Spinning up a container image" is just fancy jargon/handwaving to refer to launching a process, which is something nginx already does under the hood in a myriad usecases without warranting complains from users. > and queried for each request, don't you think? I'm not sure if either you framed your sentence poorly or you don't have a clear idea about what you're talking about. In AWS lambda, you don't "spin up containers" at each request. You launch your lambda once it's deployed or when it scales up, and it stays up as long as you see traffic.
    - 9dev 5y ago
      Poor phrasing, then. Meant to say a container is started once, then queried on every subsequent request. And what I’m talking about is not the user-facing lambda, but what AWS does on the infrastructure layer below, which involves running a containerised process on firecracker VMs, communicating via HTTP. There was a great summary of how AWS works a while ago, going into way more detail, that I sadly can’t find anymore. But there’s definitely more work involved in calling a lambda function than forking a process in nginx.

herpderperator 5y ago

CloudFront Distributions cannot pass the request to CloudFront Functions before sending to the origin. In other words, they cannot be used to modify origin request/responses. They can only modify the viewer request/responses. [0] Only Lambda@Edge can help the scenario which I provided, which is also AWS's recommended solution. [1] [0] https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope... [1] https://aws.amazon.com/blogs/architecture/serving-content-using-fully-managed-reverse-proxy-architecture/ https://aws.amazon.com/blogs/architecture/serving-content-us...

ep103 5y ago
Personally, I did it with templates in api gateway, as at least then I'm not paying for the cpu time to do these sorts of manipulation. But yes, stuff like this made me really shake my head at 'the cloud'
forty 5y ago
From your link [0] "URL redirects or rewrites" is a supported use case. For stripping /api/ from the path, I don't know what would be the benefit of doing it at the origin request, rather than at the viewer request? Cloudfront functions are pretty new, so some older docs might still reference lamdba@edge only.
- herpderperator 5y ago
  The origin request is your backend. The viewer request is the one you're requesting from the client. You want the viewer to have /api. You want the origin to not have /api. Therefore stripping must be performed on the origin request, which is not supported by CloudFront Functions.
  - forty 5y ago
    Both the viewer request and origin request hook both happen early enough that you can update the path See https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/images/cloudfront-events-that-trigger-lambda-functions.png https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope... I have used lamdba@edge and our primary use case was to rewrite url (to add languages information for example) so I'm sure it works in viewer request events.