jesseobrien / fake-iot Goto Github PK

I'll be building a front-end client using React js and an http API server using Go. The trade offs and design descriptions are in this header. There are diagrams of the system and each bit below. I'll be following this project standards repo as a standard layout for the project.

User & Password
I'm going to hard code the username & password in the code. The password will be a string hashed using the bcrypt hashing algorithm. In a normal flow you'd create these on user sign up and store these in a table. You'd then look them up when the user sends the username/password login request and validate the password matches hash.

Authentication
When the user sends a login request, I'll send back a JWT for the UI to put in the Authorization header as a Bearer token. I'm not going to implement the entire OAuth2 flow. Normally you'd redirect the user, obtain a grant and exchange the grant for an access token (JWT) that includes claims for the user. Each request will have the JWT validated through middleware.

Account Types
I'll be hardcoding an account in the accounts table. It will contain the type of account. Type will be "basic" by default. It will change to "enterprise" once the user clicks the upgrade button. I'll hard code the login limits (100, 1000) per account type in the code. In a normal system we'd have these values stored in the table so they'd be customizable per account.

Metrics
I'll be storing the login metrics in a table (account_logins). To get the count, I'll be querying with a COUNT(*) on the table. To do it properly, I'd create a materialised view that would reflect those aggregates on a per account basis whenever data is written and query that directly with the account id.

Each metric consumed will write to the database, then emit a login.count.updated event to a go channel where the websocket will be waiting to consume and send it to the UI. Normally we'd use some kind of message bus for this (Kafka, etc) but a channel will do in this instance. I'm going to re-use the same event for all front-end updates. In a nominal situation I'd break events out into stateless actions ( account.login, account.{id}.upgraded, etc) and react to those appropriately with different handlers. When consuming the metrics from the fakeiot http client, I'll be checking the count of current logins against the plan and will not be incrementing the counter if the plan limit has been reached.

Database Tables

account_logins
---
account_id string (uuidv4)
user_id string (uuidv4)
timestamp timestamp

accounts
---
id string (uuidv4)
user_id string (uuidv4)
type string (enum)

Design Diagrams