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

>But don't worry!

I don't, I can just teach my backend to process /api. The backend is running code under my control anyway. This seems like one of the least difficult "problems" to solve in any non-trivial codebase.

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)

Crafty alternative: just.. don't strip it? It seems like a perfectly reasonable and simple route that avoids complexity and cost to just keep /api.

>doesn't executing code for every single request sound insane AND doesn't it also add latency which this was trying to remove? Yes!

but surely executing code at the source of your web app is more efficient than having the client and server attempt to perform it? faster than 40-90ms per request at least

> But don't worry! AWS thought of this! They invented Another Cloud Thing, namely Lambda@Edge, to solve this.

No, CloudFront Functions is the Another Cloud Thing AWS invented more specifically for this use case. Lambda@Edge is the older and more general purpose edge computing facility.

> You read that right! Execute code every time a request hits your proxy!

Any rewrite rule in any platform, and heck, any other functionality provided by the distribution, is executing code every time it gets a request (whether or not you are writing code for the purpose.)

Not sure why you cannot strip in your backend, and it's a huge deal. Code needs to be run somewhere though. While Lambda@Edge sucks, Cloudfront runs functions now which is not Lambda@Edge, and faster because it executes on the PoP location. https://aws.amazon.com/blogs/aws/introducing-cloudfront-func...

CloudFront is a CDN, it should cache static resources, not so much manipulate incoming requests - that's more a job for a load balancer / proxy like Elastic Load Balancer.

We ran into the same issue and we had to use API gateway to rewrite urls. but it had the added benefit of handling CORS there and the preflight requests never hits the application servers. Additionally preflight requests are cached at cloudfront and at browser with "Access-Control-Max-Age" and for the first request we do pre connect during the main domain load so the users never notice the small latency it may have.

I agree that AWS products are all over the place.

In asp.net we just use:

app.UsePathBase("/api");

And we have 0 issues.

Similar to Lambda@Edge, Cloudflare also offers Workers (https://workers.cloudflare.com/) which is the same thing, but only with a JavaScript runtime (no nodejs, they use V8), so I believe that it's significantly faster.