As a Frontend Developer

I want to be able to perform CRUD operations against a centralized database

So that I can change the common state of the RMS system across devices.

Put this as documentation on top of the class

Right now, there are a bunch of APIs that have been created for the router implementation to call. For the App, we want to directly invoke the API to perform CRUD operations. We want to expose the existing APIs as Lambda functions, so that the Frontend team can call the APIs.

We should prioritize creating Lambda Handlers for CUD operations, since we want to try to perform read operations against the on device datastore. In Particular, here are the APIs that we want to create Lambda Handlers for:

• High Priority

  • BorrowItem

  • ReturnItem

  • BorrowBatch

  • ReturnBatch

  • AddItem

  • DeleteItem

  • CreateBatch

  • DeleteBatch

• Medium Priority (Update Operations)

  • UpdateDescription

  • UpdateTags

  • UpdateItemNotes

  • UpdateItemOwner

• Low Priority (Read Operations)

  • GetItem

  • ReturnItem

  • SearchItems

  • GetBatch

  • ReturnBatch

  • internal/PrintTable

For each API, we need to:

1. Change ScratchInterface name to be <APIName>Input and export the interface

   • This is so that the Frontend team can know what to pick up.

2. Implement field validation

   • Context: ScratchInterface was created as a way to store user inputs for the router implementation. Thus, all fields are optional, so that you can store an incomplete object into the transactions database. We need validation that all fields have been given before we proceed with performing the API call.

   1. Create new performAllFVAs(input: <APIName>Input>): Promise<Void> function

   2. Add all validation that is needed. At the baseline, we want to validate that all the inputs are given.

   3. Insert performAllFVAs at the beginning of the promise chain of the execute function.

   4. Add tests in the existing test class for performAllFVAs

3. Create new handler for the API in the handler folder.

   1. [Not Ready] Create tests for the create handler, overriding the database type and metric type.

4. Run amplify function add

   1. Call amplify function api-name

5. Change the amplify directory name to be APIName

   • This is for scripts to work properly

6. Delete event.json and index.js from the src directory of the amplify function.

   • Optionally create a test-json folder and configure different json files that you can test the Lambda function with.

7. Change the "main" field in package.json to equal ./ts-output/handers/api/<APIName>.js

8. Modify CloudFormation template

   1. Change the "handler" field from index.handler to ./ts-output/handlers/api/<APIName>.handler

   2. Add the following to the PolicyDocument of AmplifyResourcesPolicy:

            {
                "Effect": "Allow",
                "Action": [
                  "cloudwatch:PutMetricData"
                ],
                "Resource": "*"
            },

9. Add APIName to the list in amplify/backend/resources/scripts/compile-ts.sh

10. Add test for handler

    • Can copy logic in __tests__/handlers/api/BorrowBatch.test.ts

These scenarios should be written up as tests, using the following naming convention:

'will <have expected response> when <a certain input is given>'