-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: Split Stateful Single Stack to Multi Stack #216
Conversation
- Name files with camelCase (for example, ebsVolumes.tsx or storage.tsb) | ||
|
||
For folder name, we will be using `kebab-case` | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have been inconsistent with naming convention, but I think we could follow what AWS suggests.
Folder naming convention is not mentioned, but in general kebab-case
is more common. For example, AWS uses kebab-case
in their CDK library (import { IVpc } from 'aws-cdk-lib/aws-ec2';
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will refactor on the stateless stack after this PR along with removing the parent (of the µ-app) stack (#157 (comment))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sound good. I support this.
@@ -1,44 +1,7 @@ | |||
# Shared Resources | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should remove this entirely and have this docs at the folder where the resource is deployed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel, 😬 a little bit of double efforts/handling here, yes.
Up to the team with favour the change/remove; ie stick the README closer to the stack/resource that is deployed. At least for these early days taking off phases. We tend to change .. a lot, frequently.
This might need a redeployment of resources here as stack id will change. We could also roll this to all of our account env (dev, stg, prod) once this is approved |
.. will review today |
reviewing... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 from me.!
- Name files with camelCase (for example, ebsVolumes.tsx or storage.tsb) | ||
|
||
For folder name, we will be using `kebab-case` | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sound good. I support this.
@@ -1,44 +1,7 @@ | |||
# Shared Resources | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel, 😬 a little bit of double efforts/handling here, yes.
Up to the team with favour the change/remove; ie stick the README closer to the stack/resource that is deployed. At least for these early days taking off phases. We tend to change .. a lot, frequently.
lib/workload/components/vpc/index.ts
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can also remove this VPC lookup function i.e. rather promote to use the vpcProps
pass down from the constants.ts
and, reconstruct at the stack level. Like the way it does in Token Service stack.
What chu think, Will? Leaving it is fine, too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree on lookup at µ-stack level rather than passing IVpc
as a stack props. I feel it is more isolated and it is simpler to get onboard when dev the µ-app rather depending on resource as the props.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just thought this function is just a quick single-line wrapper of common resource lookup
@@ -112,7 +112,7 @@ export class Database extends Construct { | |||
constructor(scope: Construct, id: string, props: DatabaseProps) { | |||
super(scope, id); | |||
|
|||
const dbSecret = new rds.DatabaseSecret(this, id + 'DbSecret', { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for cleaning this id thingy up.! 😬
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bye, bye, my dear "component". Hehe. J/K 😬
@@ -35,7 +36,7 @@ export class TokenServiceStack extends Stack { | |||
super(scope, id, props); | |||
this.props = props; | |||
|
|||
this.vpc = Vpc.fromLookup(this, 'MainVpc', props.vpcProps); | |||
this.vpc = getVpc(this); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah. You want the function one. Please check with the Flo! 😃 Think, he prefer the other way, vpcProps
pass down. Leave it with you two.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm,... does the function add much?
It's a bit easier for me without... first I don't need to know about any outside function and second it's just a lookup like I'd need to do for any other (provided) resource.
Also, getVpc()
hides away configuration details that otherwise would be in the usual, expected spot (config constants), right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup. Since we change to independent "stack" concept, the props pass down become more make sense.
Think, Will agree (somewhere ^ there comment; deprecating this function lookup all together). Perhaps, Will could help make necessary changes and, use vpcProps
pass down. I reckon, that should work... But, leaving the final call to Will.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will remove it! It will be easier for native lookup rather than understanding a custom function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yay! 🎉
icaEventPipeStackProps: IcaEventPipeStackProps; | ||
} | ||
|
||
export class StatefulStackCollection { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, the "collection" class. I like this naming.! Good one, Will. 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initially was set to "manager" class, but I think we had enough managers in OrcaBus 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks nice and neat! Go for it!
@@ -35,7 +36,7 @@ export class TokenServiceStack extends Stack { | |||
super(scope, id, props); | |||
this.props = props; | |||
|
|||
this.vpc = Vpc.fromLookup(this, 'MainVpc', props.vpcProps); | |||
this.vpc = getVpc(this); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm,... does the function add much?
It's a bit easier for me without... first I don't need to know about any outside function and second it's just a lookup like I'd need to do for any other (provided) resource.
Also, getVpc()
hides away configuration details that otherwise would be in the usual, expected spot (config constants), right?
}); | ||
} | ||
|
||
private createTemplateProps(env: Environment, serviceName: string): StackProps { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added a few more initial tagging template here for each µ-stack @victorskl @reisingerf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
}); | ||
} | ||
|
||
private createTemplateProps(env: Environment, serviceName: string): StackProps { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
StatefulStackCollection
when defined in stageExample on
cdk ls
command after refactoring:resolves #188