serverless-next.js
serverless-next.js copied to clipboard
Allow overriding of lambda@edge origin-request for custom paths
Is your feature request related to a problem? Please describe. I have a custom path on my NextJS app that I want to route through a custom Lambda@Edge function of my own, but this code overrides it even if I provide it in the input configuration.
Describe the solution you'd like Allow the override to happen, I don't think it makes sense to have a configuration that gets overridden always.
Describe alternatives you've considered
Since I can't do this override I have to manually edit the default-lambda
code using a custom script on the build.postBuildCommands
.
Additional context
nextApp:
component: '@sls-next/[email protected]'
inputs:
cloudfront:
/custom-route/*:
viewerProtocolPolicy: 'redirect-to-https'
allowedHttpMethods:
['GET', 'HEAD', 'OPTIONS', 'PUT', 'POST', 'PATCH', 'DELETE']
minTTL: 0
maxTTL: 31536000
defaultTTL: 0
forward:
cookies: 'all'
queryString: true
compress: true
lambda@edge:
origin-request: THIS_GETS_OVERRIDEN_WITH_THE_DEFAULT_LAMBDA_ARN
Currently looking for this too. I have a laravel API that I currently proxy through with a fetch request on /api/ to the execute but that way im currently running 2 lambdas (the nextjs lambda for /api) and the remote lambda. So its about 400ms roundtrip.
If I could override the cloudfront origin under /api directly I could hook in my api directly instead of proxying through 2 lambdas
Any updates on this or maybe some workaround?
I haven't actually had a look yet if this is possible with the new 3.6 version ill have a dig through the new documentation when i get a chance
@dphang any idea where would be a good start for looking at this for someone who has never looked under the hood in this repo?
@mattvb91 yes I think as mentioned in the OP, https://github.com/serverless-nextjs/serverless-next.js/blob/828b9dde89a9cb2559c58ab4e798ee7cbcbdd5e6/packages/serverless-components/nextjs-component/src/component.ts#L647 as mentioned is the code that sets up the CloudFront configuration. Or you can try to use the CDK deployer as it might provide more flexibility