This is the first PR in the effort to remove the usage of queues in our backend.
Doesn't fully close IS-186, but am putting a feature flag in the spirit of merging some work into prod first.
Solution
The flag ARE_QUEUES_DEPRECIATED in InfraService.ts will determine whether or not to use the existing queues or use the dynamodbs vs queues for the site launch process. Idea is after the integration work in the infra side + enough testing, we can swap swap the value of the flag for one site launch process, and then if there are no issues for a while in production, we can remove this feature flag + queues related code altogether.
Breaking Changes
[ ] Yes - this PR contains breaking changes
Details ...
[X] No - this PR is backwards compatible
Reviewer Notes
I am not sure if its only me but the typing given in the AWS SDK for dynamo DB is abit off ._.
I have given a screenshot in the related comment below + added test cases to explicitly codify the expected behaviour that we expect from the dynamoDBDocClient.send(new ScanCommand(params)) call. Open to feedback on this.
Note that the returned object is not of the declared type `Record<string, AttributeValue>[] | undefined`
<img width="509" alt="Screenshot 2023-05-22 at 9 25 28 AM" src="https://github.com/isomerpages/isomercms-backend/assets/42832651/2f06b1c4-9e47-4987-b0bf-cfc1d9e64414">
**New environment variables**:
- `STEP_FUNCTIONS_ARN` : arn for step functions //todo add in 1pw post-approval of this PR
- ARE_QUEUES_DEPRECATED: Whether the queues are deprecated //todo add in 1pw post-approval of this PR
**Tests**
added a file `DynamoDBService.spec.ts` for tests
Problem
This is the first PR in the effort to remove the usage of queues in our backend.
Doesn't fully close IS-186, but am putting a feature flag in the spirit of merging some work into prod first.
Solution
The flag
ARE_QUEUES_DEPRECIATED
inInfraService.ts
will determine whether or not to use the existing queues or use the dynamodbs vs queues for the site launch process. Idea is after the integration work in the infra side + enough testing, we can swap swap the value of the flag for one site launch process, and then if there are no issues for a while in production, we can remove this feature flag + queues related code altogether.Breaking Changes
Reviewer Notes I am not sure if its only me but the typing given in the AWS SDK for dynamo DB is abit off ._. I have given a screenshot in the related comment below + added test cases to explicitly codify the expected behaviour that we expect from the
dynamoDBDocClient.send(new ScanCommand(params))
call. Open to feedback on this.Steps to replicate the error thrown by ts
Add this code in
server.js
:async getAllCompletedLaunches(): Promise<SiteLaunchMessage[]> { const entries = ((await this.dynamoDBClient.getAllItems(this.TABLE_NAME)) .Items as unknown) as SiteLaunchMessage[] const entriesWithSDKTypeCast : Record<string, AttributeValue>[] | undefined= ( await this.dynamoDBClient.getAllItems(this.TABLE_NAME) ).Items