closed issue
Initial Design

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_id string (uuidv4)
user_id string (uuidv4)
timestamp timestamp
id string (uuidv4)
user_id string (uuidv4)
type string (enum)

Design Diagrams





Created at 1 month ago
closed issue
Configuration File

Need to add a config file so the stop words, min word length, and connections are configurable.

Created at 1 month ago
closed issue
Code Snippets

I think we can look at what @dhorrigan has with Scrapyrd and get it working within the depot.

Core features I was thinking of would be:

  • Allow users to save the snippets to their account
  • Allow users to "publish" the snippet, with a readme or some instructions attached
  • Allow other users to comment on the snippets
  • Allow other users to save snippets they like onto their account (for editing, etc) might want to retain the parent here to give proper credit to whomever the original author is
Created at 1 month ago