Wrong URL when using CloudFront in front of API Gateway about bref

[mnapoli]

This is actually the same issue with a custom domain name I believe.

One thing we could do is always drop the stage prefix (/dev) from the URL. That means it's easier to go from local development (e.g. Symfony routes) to online on API Gateway to production with a custom domain/Cloudfront: we use always the same routes.

But that also means that we are "hiding" the real URLs when on API Gateway. And if we use the router to generate URLs (e.g. links to other pages) then we generate wrong links… That sucks.

[nealio82]

@eddmann knows AWS architecture pretty well, any thoughts? Can the URI be mapped from one to the other programattically somehow on the AWS side?

[eddmann]

When you setup a custom domain within API gateway it internally sets up a CloudFront distro with the env. mapping you discuss. I would say the best bet is to have to CloudFront distro. one which API gateway manages and the other which is used to handle requests to static assets in S3 etc.
If you want to manipulate the request/response more in depth you could use Lambda@Edge which allows you to manipulate the client request/response and origin request/response.

[mnapoli]

@eddmann yes, but the problem is when using CloudFront like this:

CloudFront -> API Gateway -> AWS Lambda

[eddmann]

@mnapoli Are you using CloudFront directly or via API Gateway?

[mnapoli]

I am using it in front of API Gateway.

I use it to serve both assets from S3 and dynamic content from Lamdba in the same website/domain name.

I had an interesting answer on StackOverflow:

You could configure your CloudFront distribution to use a custom header that would be passed to the Lambda function. Then you could determine whether to use path or requestContext.path based on if that CloudFront-only header is present.

I guess that would work, but that's definitely not great to ask Bref users to do that for their projects… We could auto-create that header in Bref, but at the moment I haven't automated the creation of the CloudFront distribution.

[wysow]

Sounds like a good "hack" which could be at least partially automated, and if we add some information in bref readme that should be fine for now, no?

[eddmann]

Ahh right. Yes you could add an additional header with CloudFront requests. Another option is to have two separate CloudFront distros. one which API Gateway manages (handling the desired prefix etc). and another which is used for static assets. Doing it this way however would require two separate domains which I'm assuming you are trying to get away from?

Another option that I haven't tried and am unsure on (due to Lambda sizes) is to store all assets within the Lambda along side the code. In this case you have a dedicated handler that gets run when static assets are requested. Performance for this would not be ideal on initial request but as you can tweak the Cache controls and API Gateway is going through CloudFront you will benefit from their caching platform.

[mnapoli]

Doing it this way however would require two separate domains which I'm assuming you are trying to get away from?

Yes, I'm trying to make it possible to do what most PHP applications do, i.e. serve both PHP and assets under the same domain.

store all assets within the Lambda along side the code. In this case you have a dedicated handler that gets run when static assets are requested.

I wondered about this too. The first hit would be slow and that seems overkill to serve assets using PHP. And as you mention, it's too bad to have to upload the assets to the lambda, that doesn't seem ideal 🤔 But maybe for small application it could work… Anyway if I can make it work with CloudFront that's better IMO.

[wysow]

Just my 2 cents, lambda zip file is limited to 50mb so all assets should be optimized, and they should be served by the node handler without ever hit the php handler, what do you think?

[nealio82]

Just my 2 cents, lambda zip file is limited to 50mb so all assets should be optimized, and they should be served by the node handler without ever hit the php handler, what do you think?

Hmm, wouldn't that cause a problem when the routing / management for assets is handled by the PHP framework?

[mnapoli]

Oh that’s definitely simpler to serve assets using Node! Maybe there could be an optional config to let Bref’s JS handler serve assets, and if you want to handle those manually with Cloudfront or PHP then it’s up to you... Le 4 oct. 2018 à 10:35 -0400, Neal Brooks <[email protected]>, a écrit :

…

> Just my 2 cents, lambda zip file is limited to 50mb so all assets should be optimized, and they should be served by the node handler without ever hit the php handler, what do you think? Hmm, wouldn't that cause a problem when the routing / management for assets is handled by the PHP framework? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[nealio82]

Sure - maybe some configurable toggle to serve assets using node / PHP?

[mnapoli]

Should be fixed in 0.3.