This gist is to jump to the DB designing (without explaining the "Why/How DynamoDB" part).
- ERD - Entity Relation Diagram
- Define the Access Patterns
- Design PK/SK
This gist is to jump to the DB designing (without explaining the "Why/How DynamoDB" part).
Pseudo query: (only the "where" part)
Get user profile from email (using OAuth 2 social login, no "user-ID")
PK = USER#<email> AND SK = PROFILE#<email>
Get all sheets for a user
PK = USER#<email> AND
SK "begins-with" SHEET#
Notice that there is no "sheet-id" in the query
Get a sheet by ID for a user
PK = USER#<email> AND SK "begins-with"
SHEET#<sheet-id>
Get all APIs for a sheet for a user
PK = USER#<email> AND SK "begins-with"
#SHEET#<sheet-id>
Notice that there is an additional "#" before "SHEET#"
Get an APIs by sheet ID and API ID for a user
PK = USER#<email> AND SK "begins-with"
#SHEET#<sheet-id>#API#<api-id>
I believe this is where I must stop from DB POV.
Moving on the the UI aspect in another gist (Tailwind + CakePHP).
For UX, Vue will be brought in, soon.
Exported data model (as JSON) from NoSQL Workbench for DynamoDB
Going back to "Entities" (from ERD above) and noting their respective PK/SK value formats
In the "APIs" entity, the SK is having an additional "#" as a prefix, to differentiate when a "Sheet" is being requested vs "APIs for all sheets" are requested.