RFC309: weak cross-stack references #449
Conversation
|
|
||
| * **Original Author(s):**: @rix0rrr | ||
| * **Tracking Issue**: #309 | ||
| * **API Bar Raiser**: @otaviomacedo |
| }) | ||
| ``` | ||
|
|
||
| After you have deployed your stack with `strongToWeak` enabled, you can remove the flag again and do another deployment: |
There was a problem hiding this comment.
Technically no side-effects nor any functionality impact (beyond duplication/ cost) is the second step if accidentally skipped?
There was a problem hiding this comment.
Just duplication, not even cost.
Just not as clean.
|
|
||
| ### Defaults for stacks | ||
|
|
||
| You can choose to configure the default reference style for an entire stack passing the `defaultReferenceStyle` property to a stack constructor: |
There was a problem hiding this comment.
What happens if a team is silly and one change passes a stack-style and the other change passes the style per reference, what's the precedence order -- the more granular, per-reference one?
|
|
||
| Strong references cause a lot of usability problems for CloudWatch Dashboards. That's why starting in new applications, all CloudWatch Dashboards will use weak references by default. | ||
|
|
||
| This is controlled by the feature flag `@aws-cdk/aws-cloudwatch:dashboardWeakReferences`. It can take on the values `true` (for weak references) or `"strongToWeak"`, for the first phase of the two-phase deployment. |
There was a problem hiding this comment.
What case can be made that not switching to weak references in CloudWatch Dashboards is the right thing to do?
There was a problem hiding this comment.
I don't think there is any. Strong references only make sense if the consumer would suffer availability impact if the producer disappears. This is definitely not the case for dashboards: the line will just have a gap in it.
Note: explicitly not saying this for Alarms: they may have impact if the producer disappears, depending on whether the MissingDataPoints property is set to BREACHING or IGNORE.
|
|
||
| And use either `Exports` or SSM parameters to reference itself. | ||
|
|
||
| The explicitness puts users in full control, able to generate exports in either or both styles, even without a consumer. |
There was a problem hiding this comment.
This makes it more generic when compared to the feature flag, right?
There was a problem hiding this comment.
I don't know what generic means in this context. But it sure makes it more explicit, at the cost of:
- having to type more
- having to be aware when you are passing constructs across stacks (might not be obvious when writing higher-level code)
- losing the ability to make decisions on a per-consumption basis (person passing into the consumer stack makes the choice for the entire stack)
- losing the ability to change the producing construct from the consumer stack
|
|
||
| ### Defaults for stacks | ||
|
|
||
| You can choose to configure the default reference style for an entire stack passing the `defaultReferenceStyle` property to a stack constructor: |
There was a problem hiding this comment.
| You can choose to configure the default reference style for an entire stack passing the `defaultReferenceStyle` property to a stack constructor: | |
| You can choose to configure the default reference style for an entire stack passing the `defaultReferenceStyle` (defaults to `ReferenceStyle.STRONG`) property to a stack constructor: |
|
|
||
| ### Why should we _not_ do this? | ||
|
|
||
| It might not be worth the additional complexity in the token and reference system (which is already pretty complex). |
There was a problem hiding this comment.
Could we elaborate on this?
This is a request for comments about Cross stack References. See #309 for
additional details.
APIs are signed off by @Naumel.
By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache-2.0 license