Replies: 2 comments 2 replies
-
I think this is a great idea, and an error-prone area that CDK also always wanted to tackle, so I'm all in favor of adding support for it. One more case here that is especially important in Wing is correctly handing refactoring of the class name, because the name doubles as the default identifier of resources, including stateful ones. So, if I write my own Resource in Wing: resource MyResource {
init() {
this.bucket = new cloud.Bucket();
// stuff & things...
}
}
// usage of MyResource
let myResource = new MyResource(); And I decide to rename let myResource = new StorageLayer() as "MyResource"; Now, if I like both ideas nr 1 and 2, but I'm not a huge fan of idea 3 - I think it kind of goes against composability of resources, which is a very important tenet of the construct programming model. Just my 2 cents! |
Beta Was this translation helpful? Give feedback.
-
Wing resources are built on top of
constructs
, a minimal library for creating infrastructure-as-code frameworks. Based on our previous experience usingconstructs
with AWS CDK, we realized when designing Wing that there could be benefits from knowing during compilation which resources in an app are "stateful" as not.Background
Stateful cloud resources are those that typically hold important application state -- state that would typically be lost if the resource was deleted and re-created on a cloud provider.
By contrast, a stateless resource does not remember information about past transactions or events, and can typically be replaced by a cloud provider with a fresh copy without any consequences.
For example, a DynamoDB table created on AWS typically represents a stateful resource, whereas a Google Cloud Function would be a stateless resource. (I say "typically" because one could use a table to store temporary/ephemeral data that is OK to delete, but we can provide an override mechanism in the SDK for those situations).
Managing stateful resources using
constructs
can sometimes have pain points because reorganizing the constructs in an application may result in a resource's logical ID getting changed. Since the resource's physical name is typically generated based on its logical ID, changing the ID results in the resource being regenerated in the underlying cloud provisioning engine.To mitigate this problem, users in frameworks like AWS CDK have had to resort to manually overriding the logical IDs of each resource through APIs like overrideLogicalId. (A similar API also exists in the CDKTF framework).
As a starting point, Wing SDK resources include a field named
stateful
indicating whether they are stateful or not, and through the Wing compiler we may be able to automatically annotate resources asstateful
as or not.Related links:
Question 1: Does Wing need to support a similar escape hatch mechanism for
construct
IDs for all resources?Question 2: How can we utilize data about resource statefulness to improve the experience of building and updating/maintaining cloud applications?
Idea 1
Based on whether a resource in your application is stateful, if your resource gets removed or renamed, e.g.:
...then upon compiling, based on your past compilation history, Wing might be able to provide a warning that one or more sensitive resources will be deleted or recreated upon deploying the cloud artifact (terraform, cloudformation, etc.).
To determine this, a statefile would have to be generated by Wing tracking the IDs and metadata of different stateful resources in the user's application. When the list of stateful resource names are changed, some heuristics would be applied to find resources with the same properties that were once named X and are now named Y, and infer the mapping. An interactive prompt would be used to let the users confirm the mappings, and inform the user on how to override them via code.
Idea 2
(Alternative for when the above fails)
Provide alternative escape hatch APIs that are not just for overriding the logical IDs of individual resources, but of entire constructs (which may contain multiple stateful resources) - see this RFC for more ideas.
Perhaps the Wing console could provide a GUI-like interface where if you drag a stateful resource (or construct containing a stateful resource) elsewhere in the tree, code could be automatically generated and inserted into the user's app to keep the original logical IDs intact.
Idea 3
(Encourage best practices)
One possible mitigation / best practice might be to always define stateful resources at the root of your application tree, so that they never have to get shuffled around. To guide users towards this, Wing could include a linter warning if the user defines a resource containing a stateful child resource. Recommend the user to refactor the child resource into a resource prop / argument, so that the user can define stateful resources at the root of their app and pass them directly to constructs instead. This warning could possibly be silenced by annotating that the parent resource is a "singleton" and will only be created once.
For example:
Beta Was this translation helpful? Give feedback.
All reactions