-
Notifications
You must be signed in to change notification settings - Fork 154
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
Consider improving API Resource design to avoid manual dependsOn #22
Comments
Before creating an `apigateway.Integration`, we must have created the `apigateway.Method`s associated with the target `apigateway.RestApi`. Similarly, we must have created all of those things before creating the final `apigateway.Deployment` resource. Because the properties of said resources do not naturally lead to the proper dependency graph, however, enabling parallelism can lead to attempting to create the resources out of order. To fix this, we manually link them with dependsOn. Please see #22 for ideas on improving this.
We support two ways of doing this today - the raw resource way, and the swaggger For these specific resources, I’d be inclined not to invent a third way to orchestrate them, at least not baked in to the AWS projection. If we had a genralized solution to mapping dependencies into strongly typed part of the resource model in a resource-specific way that we could apply to all AWS resources, that might be interesting - but it’s not clear to me that could be meaningfully better than what |
I feel like we're in a reasonable place here now. We have |
Before creating an
apigateway.Integration
resource, we need to have created theapigateway.Method
s associated with the targetapigateway.RestApi
resource. Similarly, we must have created all of those things before creating the finalapigateway.Deployment
resource.Because the properties of said resources do not naturally lead to the proper dependency graph, enabling parallelism can lead to attempting to create resources out of order.
We can fix this with manual
dependsOn
annotations, but this is unfortunate, and it seems worth considering whether we can improve the API Gateway class design to avoid needing to do so.The text was updated successfully, but these errors were encountered: