AWS Amplify Project: Datastore

Field	Value
Milestone:	Milestone
Owner:	Johnny Chen
Contributors:
Reviewer:	Jeremy Yau
Status:	Approved

Why?

As a Frontend Developer

I want to be able to read the database

So that I can reflect the current condition of the system to the user.

Put this as documentation on top of the class

Right now, the current setup is that there’s a bunch of DynamoDB tables that were created for v1 of the product. Because DynamoDB is a NoSQL Database, it is often more efficient just to have a single main table, so that we only require a single call to get a object by it’s key. Now we want some way to be able to see the Database on the device.

What?

Amplify Datastore

Amplify DataStore provides a programming model for leveraging shared and distributed data without writing additional code for offline and online scenarios, which makes working with distributed, cross-user data just as simple as working with local-only data.

The nitty gritty of it is that Amplify Datastore is backed by AppSync, which creates GraphQL infrastructure on top of DynamoDB tables. What Amplify Datastore adds is in built ability for offline database storage. GraphQL also essentially makes the database a conventional SQL database with a schema again.

See website for more details.

Sandbox might be useful for creating the schema.

How?

Task Breakdown

1. Amplify Initialize a new GraphQL API.

   • Try to build it on top of the old databases. Otherwise, create a new one.

2. Create new GraphQL schema that matches the existing database schema structure.

   • This might be as simple as copy and pasting the existing schema definitions and adding a couple tags.

   • This should exist in the src/db folder.

   • Should only give users read access, as write access operations should still be done through APIs for now

3. Create a new DB type for Amplify operations.

   • This allows for the Frontend team to directly call backend read APIs.

   • Amplify doesn’t support transactional writes, so we want to keep write operations to directly call DynamoDB APIs, via Lambda (because of permissions)

     • For less important operations, such as update description, might be ok to directly change on device and not keep transactional properties. But once you give write access, you’re playing a dangerous game, in that the Frontend might accidentally change stuff that they shouldn’t change really.

4. Support Frontend team for write operations.

5. [Low Priority & Might not be necessary] Change the database structure to have the item details in the item table, instead of embedded object in the main table.

   • Might not increase efficiency by all that much, in comparison to the effort that it takes to change underlying logic to account for this change.

Acceptance Criteria

Scenario	Expected Response
When a Amplify query is performed	Will return the result of the database 'correctly'. (It’s essentially weak committed transactions, so we don’t have full correctness. Eventual Consistency.)
When APIs are called backed by a AmplifyDB	Will return result correctly. (Can maybe use the existing unit tests to verify
When a write operation is performed through Lambda	Will display the result of the write operation when reading using Amplify Datastore APIs (Manually Test)
When device is offline	Will still be able to perform read operations (Manually Tested)

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

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