DynamoDB data modelling for dapier/admino - first time DynamoDB/NoSQL, expect big and stupid mistakes

DynamoDB-dapier-admino.md

The more I watch Rick's sessions from 2017, 2018 and 2019, more confused I get - so I guess I'd write it down.

There are 3 core steps (some have more, I want to stick to 3) to create a decent model that works well:

1. Understand the usecase + create ERD(list entities and relations)
2. Identify the access patterns - R/W workloads, query dimensions and aggregations
3. Data modeling - avoid relational patterns, use 1 table(if there aren't any "documents", 1 should be fine)
4. R.R.R = Review > Repeat > Review (go on till it makes sense)

Continuing from JWT - Yes, it should work!

As a concept (soon to be tried), following is the scenario that I am trying to implement:

1. After social login (via GitHub only, ATM) create a JWT token using the email received from GitHub (using access_token)
2. Send the JWT token (the long string) as a response to the client/browser upon successful logging in
3. Expect a header with JWT token for authorised requests and check for authenticity of the token, and if found authentic, then use the given email as a valid identifier and serve the request

Considering the usage of JWT, the need for any other token for authorisation is deemed unnecessary and hence the following set of entities is reduced from:

Entity 1 = User
Entity 2 = Token
Entity 3 = Connection
Entity 4 = Permission

to

Entity 1 = User
Entity 2 = Token
Entity 3 = Connection
Entity 4 = Permission

New entity set identified

Entity 1 = User
Entity 2 = Connection
Entity 3 = Permission

From a database structure POV, the change now is that the primary key would be the "email" of the logged in user (or rather the "social email")

User will have many connections

User will have many permissions

Connection will have many permissions

From DynamoDB POV, the PK/SK structure would look something like this:

For "users":
PK = USER_{email-goes-here}
SK = TRUE or FALSE (depicting "active" status)
meta = JSON

For "connections"
PK = CONN_{ID-goes-here}
SK = TRUE or FALSE (depicting "active" status)
meta = JSON

For "permissions"
PK = PERM_{email-goes-here}
SK = {connection-ID-goes-here}
meta = JSON