-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(type-safe-api): create a new asset with PrepareApiSpecOptions props and used it in PrepareApiSpecCustomResourceProperties instead or raw properties in order to avoid large payload that can cause the PrepareSpecCustomResource to fail #773
base: mainline
Are you sure you want to change the base?
fix(type-safe-api): create a new asset with PrepareApiSpecOptions props and used it in PrepareApiSpecCustomResourceProperties instead or raw properties in order to avoid large payload that can cause the PrepareSpecCustomResource to fail #773
Conversation
…ps and used it in PrepareApiSpecCustomResourceProperties instead or raw properties in order to avoid large payload that can cause the PrepareSpecCustomResource to fail
Hi @agdimech, Here is a pull request, I don't have any more time at the moment to work on it, I will test it tonight (in ~12h in my time zone) I just pushed it if you want to take a look |
Sorry for the delay - just wanted to check in to see whether this is ready for review and has this been tested? |
I just tried but I got an error now when I run
|
Can you try downgrading your Node version to 18? |
Thanks, I downgraded my version to node@20 and will stay on that version from now. It now builds as expected. I followed the official documentation in order to use my local package and tried it with a production use case in a sandbox environment. By looking at assets in S3, we now have a new input-config.json asset generated that corresponds to all the prepareSpecOptions. The previous error related to the prepare spec resource has now been resolved. Previously, there was an error with the ApiPrepareSpecCustomResourceAF67685F resource:
However, I now have encountered a new error in the API. The new error on ApiCD79AAA0 is:
So, I tried to find differences between the output prepared spec and discovered that tokens weren't resolved. Indeed, by looking at the input-config.json asset, I found occurrences of the following throughout the file: "getCompanies": {
"integration": {
"type": "AWS_PROXY",
"httpMethod": "POST",
"uri": "arn:aws:apigateway:eu-west-1:lambda:path/2015-03-31/functions/${Token[TOKEN.2257]}/invocations",
"passthroughBehavior": "WHEN_NO_MATCH"
},
"methodAuthorizer": {
"authorizerId": "cognito-authorizer",
"authorizationScopes": [
"${Token[TOKEN.2208]}/companies.read"
]
}
}, I think that synchronously write the prepareSpecOptions is not the right way to achieve this |
Hi @agdimech, I hope you're doing well. I wanted to follow up on my previous comment. I've been diving into the issue and think I might've stumbled upon a workaround for token resolution at deploy-time. I've looked into the official AWS CDK documentation regarding S3 Deployment and it appears that S3 Deployment supports deploy-time values, which could be a good solution for our use case. I'm thinking we could tweak our approach a bit and play around with the deployment structure. Something like this perhaps:
and create a new This could help keep things neat and tidy. Before I dive deeper into this, I'd love to hear your take on it. Let me know if you think it aligns with what we're aiming for or if you have any other solution that keep current asset in default CDK asset bucket. |
Hi @valebedu, The BucketDeployment definitely looks like the way to go! I wasn't entirely sure about what the timestamp represented above (perhaps asset deployment instance?) although I am wandering, could we re-use the Asset bucket and do something like this instead?
|
…ead of asset NOTE: S3 deployment supports deploy-time values
Yes it's simpler to do that, it was just a proposition to move assets to separate buckets and to support history with a timestamp or datetime as a root folder. I've pushed changes and try to build but I got an error everytime time. I'm using node@20 and pnpm@8, I clean deps and really don't understand why I got an issue about deployment and didn't find any related issue on github. Any idea?
|
Hmm i'm not too sure - I triggered a build via CI and it all built successfully. Try deleting the |
In order to instanciate bucket deployment before prepare spec custom resource
I attempted with some changes, but now I encounter the same error with ApiOptionsDeploymentCustomResource859991B0:
Adding a bucket deployment with deploy-time values merely shifts the problem to the bucket deployment. It appears there is no effective solution for this issue at the moment. 😞 This suggests a virtual limit to the API Gateway size due to the Lambda payload limit, which constrains how large the API can be. |
Fixes #771