Resource Type Providers #170
Conversation
|
Title does not follow the guidelines of Conventional Commits. Please adjust title before merge. |
|
|
||
|
|
||
|
|
||
| # Drawbacks |
There was a problem hiding this comment.
The main drawback as far as I see it is that if we release those custom resources to the registry it means their APIs become public APIs that we must maintain with backwards compatibility, versioning and assurances we are not set out to provide.
The benefit of embedded custom resources is that they can be treated as an "implementation detail" of the construct, and the API stability can only be managed at the construct level.
In a sense every public registry resource is a fully fledged service that must be maintained from an API perspective, and I doubt that we have the bandwidth to do that.
There was a problem hiding this comment.
Agreed and I thought of pointing out that this should initially be implemented for single versioned services in mind. So services somewhat "static" (like IAM OIDC provider, DNS certificate validation, etc) can be easily migrated, but not for "dynamic" services (like EKS cluster creation, etc).
|
I am closing this for now. Please reopen when ready to continue |
Rendered version
By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache-2.0 license