The infrastructure code for AWS resources
The cdk.json
file tells the CDK Toolkit how to execute your app.
npm run build
compile typescript to jsnpm run watch
watch for changes and compilenpm run test
perform the jest unit testscdk deploy
deploy this stack to your default AWS account/regioncdk diff
compare deployed stack with current statecdk synth
emits the synthesized CloudFormation template
By design, CDK does not support creating secrets with a certain value. Thus, adding a GitHub Oauth Token as a secret in CDK is not possible.
To create it
-
In AWS CLI, run the follows (only change
{the_token_goes_here}
, as the other fields are used with their values in the code )aws secretsmanager create-secret --name iyiye/GithubOauthTokenSecret \ --description "GitHub Oauth Token for iyiye repos" \ --secret-string {"token":"{the_token_goes_here}"}
-
Add/update the
GITHUB_TOKEN_SECRET_ID
value in.env
file.
TBD
I chose DynamoDB since:
- It is easy with the VTLs
However, DynamoDb sucks in the following ways:
- No support for unique indexes.
Show schemas and tables:
SHOW SCHEMAS; -- synonym: SHOW DATABASES;
SHOW TABLES FROM notif;
SHOW TABLES FROM portf;
SHOW TABLES FROM uintr;
SHOW TABLES FROM whs;
SHOW TABLES FROM order;
SHOW TABLES FROM deliv;
Show table contents:
SELECT * FROM notif.in_app_notification;
SELECT * From portf.kit_category;
SELECT * From portf.kit;
Although the basic way is to separate databases, having one instance and sparing distinct schemas to services (AppSync models here) is also an option. However, as MySQL does not support classical way of schemas, we create databases as Chris Richardson primarily proposes.
Although one service may address more than one function (or none), we considered domains as follows and created databases for each. See the DDL. DynamoDB tables are out of scope.