RFC 499: AppConfig Constructs #500

chenjane-dev · 2023-05-04T18:03:07Z

This is a request for comments about AppConfig L2 constructs. See #499 for
additional details.

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache-2.0 license

text/0499-appconfig-constructs.md

otaviomacedo · 2023-05-09T13:07:20Z

text/0499-appconfig-constructs.md

+### Example
+```ts
+const appconfig = new AppConfig(this, 'MyAppConfig',{
+  deploymentStrategy: <IDeploymentStrategy>,


Other than AppConfig, what construct is DeploymentStrategy associated to, and how is it consumed?

Other than AppConfig, the DeploymentStrategy will not be associated to anything else, however it could be potentially associated with a CfnDeployment from our L1 constructs. The DeploymentStrategy construct is only relevant when we are deploying configuration which the AppConfig construct (and CfnDeployment if users want) will handle. Does this answer your question of how is it consumed?

It does. By the way, how does AWS::AppConfig::Deployment work? Do you have to modify its logical ID every time you make a change to make sure your change is actually published (a la API Gateway)?

You don't have to modify the logical ID, it looks like when I redeploy a AWS::AppConfig::Deployment, it will create a new resource in CFN but it will still retain the old deployment

text/0499-appconfig-constructs.md

otaviomacedo · 2023-05-09T13:11:25Z

text/0499-appconfig-constructs.md

+  deployTo: [           // will deploy to all environments by default
+    Environment.create('beta'),
+    Environment.create('prod'),
+    Environment.from(<IEnvironment>),


What would this from factory method do?

This method will use the existing environment passed in instead of creating a new environment

Why do you need a method at all in this case?

Ah, you're right, I don't

text/0499-appconfig-constructs.md

otaviomacedo · 2023-05-09T13:23:59Z

text/0499-appconfig-constructs.md

+
+# AppConfig
+
+An AppConfig construct will be the simplest way to create and deploy configuration. This construct will handle deployments for you and start deploying configuration on creation.


Similar question to the configuration one: AppConfig seems to be a higher-level version of Application. Why have both?

Same answer as above

text/0499-appconfig-constructs.md

Pull request has been modified.

otaviomacedo · 2023-05-09T20:46:08Z

text/0499-appconfig-constructs.md

+  deployTo: [           // will deploy to all environments by default
+    Environment.create('beta'),
+    Environment.create('prod'),
+    Environment.from(<IEnvironment>),


Why do you need a method at all in this case?

text/0499-appconfig-constructs.md

otaviomacedo · 2023-05-10T08:54:53Z

text/0499-appconfig-constructs.md

+
+# Configuration
+
+A configuration is a higher level construct that can either be a HostedConfiguration (stored internally through AppConfig) or a SourcedConfiguration (stored in S3, Secrets Manager, SSM Parameter, SSM Document, or Code Pipeline). This construct will be used as a building block to deploy configuration through the AppConfig construct (detailed in the next section). For a HostedConfiguration, this construct will combine both a configuration profile and a hosted configuration version.


I see where you're coming from. But here's what I find confusing (and users also probably would): there is an L2 that is basically the same as the L1, and then there is an another L2, which looks very similar to the first one, but with additional features. Not only that, but the "higher-level" L2 can be constructed with a reference to the the "lower-level" L2.

Can you expand on the use case for importing existing resources?

text/0499-appconfig-constructs.md

otaviomacedo · 2023-05-10T09:39:44Z

text/0499-appconfig-constructs.md

+### Example
+```ts
+const appconfig = new AppConfig(this, 'MyAppConfig',{
+  deploymentStrategy: <IDeploymentStrategy>,


It does. By the way, how does AWS::AppConfig::Deployment work? Do you have to modify its logical ID every time you make a change to make sure your change is actually published (a la API Gateway)?

chenjane-dev · 2023-05-10T15:20:33Z

Responding to #500 (comment) since it wouldn't let me reply directly.

I think this could be from a number of factors. For one, there could be a customer who has been deploying configuration through other means and want to migrate to managing config through CDK. Another possibility is people already using L1 constructs can easily migrate their resources to using L2 constructs.

otaviomacedo · 2023-05-15T12:58:12Z

Responding to #500 (comment) since it wouldn't let me reply directly.

I think this could be from a number of factors. For one, there could be a customer who has been deploying configuration through other means and want to migrate to managing config through CDK. Another possibility is people already using L1 constructs can easily migrate their resources to using L2 constructs.

Can't you have the import methods in the higher-level constructs?

otaviomacedo · 2023-05-22T10:51:39Z

text/0499-appconfig-constructs.md

+
+  // optional
+  name: 'ExtensionName',
+  resources: [


This will complicate the API unnecessarily. My suggestion:

Keep Extension as simple as possible, serving only as an abstraction to CfnExtension. In particular, don't add the resources property to it. The list of Actions is a good addition, though.

Create a behavioral interface (e.g., IExtensible) and make AppConfig, Environment and IConfiguration implement/extend it. This interface should have a on(ActionPoint, EventDestination). If you want, you can also add convenience methods such as onDeploymentComplete(). When these methods are used, an extension association is created with the method's target. This is essentially what you are proposing down below for AppConfig, but applying it to the other two types of resources as well.

Have an addExtension in this interface, so users can add extensions they created by instantiating Extension directly.

Maybe create a base class ExtensibleBase to avoid re-implementing the same thing multiple times.

otaviomacedo · 2023-05-22T10:53:50Z

text/0499-appconfig-constructs.md

+const extension = new Extension(this, 'MyExtension', {
+  actions: [
+    new Action(this, 'MyAction', {
+      actionPointEvent: <IFunction|IQueue|IBus|ITopic>,  // ex. ActionPointEvent.fromFunction(<IFunction>)


I don't know if "action point event" is the term commonly used when talking about AppConfig (the data type in the CloudFormation spec is just Json, so I can't tell what exactly an action entails). But, from my outside perspective, this name doesn't mean anything. I would expect it to be called something like eventDestination or eventTarget, with a matching data type name, like IEventDestination or IEventTarget.

By the way, here you can follow the s3.Bucket.addEventNotification() pattern and create different implementations like LambdaDestination, SqsDestination etc.

RFC 499: AppConfig Constructs

e5c6fe0

otaviomacedo previously requested changes May 9, 2023

View reviewed changes

RFC 499: AppConfig Constructs

c54969e

otaviomacedo reviewed May 10, 2023

View reviewed changes

RFC 499: AppConfig Constructs

b385855

RFC 499: AppConfig Constructs

e4c329f

otaviomacedo reviewed May 22, 2023

View reviewed changes

RFC 499: AppConfig Constructs

9cb5f78

otaviomacedo approved these changes May 23, 2023

View reviewed changes

otaviomacedo merged commit 28dfa75 into aws:master Jul 1, 2023

TheRealAmazonKendra mentioned this pull request Jul 25, 2023

feat(appconfig): L2 constructs aws/aws-cdk#26467

Closed

evgenyka added the l2-request request for new L2 construct label Oct 11, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RFC 499: AppConfig Constructs #500

RFC 499: AppConfig Constructs #500

chenjane-dev commented May 4, 2023

otaviomacedo May 9, 2023

chenjane-dev May 9, 2023

otaviomacedo May 10, 2023

chenjane-dev May 10, 2023

otaviomacedo May 9, 2023

chenjane-dev May 9, 2023

otaviomacedo May 9, 2023

chenjane-dev May 10, 2023

otaviomacedo May 9, 2023

chenjane-dev May 9, 2023

otaviomacedo May 9, 2023

otaviomacedo May 10, 2023

otaviomacedo May 10, 2023

chenjane-dev commented May 10, 2023

otaviomacedo commented May 15, 2023

otaviomacedo May 22, 2023 •

edited

Loading

otaviomacedo May 22, 2023


		# AppConfig

		An AppConfig construct will be the simplest way to create and deploy configuration. This construct will handle deployments for you and start deploying configuration on creation.


		# Configuration

		A configuration is a higher level construct that can either be a HostedConfiguration (stored internally through AppConfig) or a SourcedConfiguration (stored in S3, Secrets Manager, SSM Parameter, SSM Document, or Code Pipeline). This construct will be used as a building block to deploy configuration through the AppConfig construct (detailed in the next section). For a HostedConfiguration, this construct will combine both a configuration profile and a hosted configuration version.

RFC 499: AppConfig Constructs #500

RFC 499: AppConfig Constructs #500

Conversation

chenjane-dev commented May 4, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chenjane-dev commented May 10, 2023

otaviomacedo commented May 15, 2023

otaviomacedo May 22, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

otaviomacedo May 22, 2023 •

edited

Loading