chore(guidelines): guidance on which constructs are included in the CDK #13218
Conversation
Adding a section of general guidance in the DESIGN_GUIDELINES to explain the L1, L2, and beyond constructs, and what types of behaviors L2s should include versus what types likely belong in separate repositories. This guidance is by no means complete or without controversy. I expect pushback and hope for both more supporting examples as well as counter examples.
|
|
|
Focusing-in on AppMesh, where's the line for a Virtual Gateway's compute? For instance, what about a construct that provides a load-balanced Fargate service for a Virtual Gateway: is it an included integration construct? included pattern? excluded? What about the similar, but for ECS with EC2-based capacity? Or how about EC2 instances in an ASG? |
Disclaimer: I'll admit I'm not super familiar with AppMesh and its constructs. Your example of a load-balanced Fargate service for a Virtual Gateway would be considered a pattern construct ("L3+") and (IMO) would not be a candidate for inclusion in the CDK. Generally, constructs that piece together multiple resources across multiple services to achieve a common use case are extremely useful, but also suffer from either exposing the full surface area of all of the underlying L2s or providing a subset of options that works for half of users but not the other half. We've found that publishing these as separate libraries and allowing users to customize and/or consume the options that fit their use cases is the better path forward. |
| configure all resource properties, which requires a complete understanding of | ||
| the details of the underlying AWS CloudFormation resource model. | ||
|
|
||
| The next level of constructs, L2, also represent AWS resources, but with a |
There was a problem hiding this comment.
Would it be worth mentioning that L2 resources interact with other CloudFormation resources only via other L2s, never via L1s?
There was a problem hiding this comment.
Definitely worth capturing somewhere in this doc, but I'm not sure if this is the right section. Maybe under the Props section, or Implementation, depending on if we're talking about the public surface area or implementation details?
Elad's suggested changes. Co-authored-by: Elad Ben-Israel <benisrae@amazon.com>
eladb
changed the title
njlynch
changed the title
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
…DK (aws#13218) Adding a section of general guidance in the DESIGN_GUIDELINES to explain the L1, L2, and beyond constructs, and what types of behaviors L2s should include versus what types likely belong in separate repositories. This guidance is by no means complete or without controversy. I expect pushback and hope for both more supporting examples as well as counter examples. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Adding a section of general guidance in the DESIGN_GUIDELINES to explain the L1,
L2, and beyond constructs, and what types of behaviors L2s should include versus
what types likely belong in separate repositories.
This guidance is by no means complete or without controversy. I expect pushback
and hope for both more supporting examples as well as counter examples.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license