reyesml / rmt Goto Github PK

• make it pretty
• build dedicated "searchable" back-end api with dedicated "searchable" object(?)

I'm thinking something like this:

Users should be able to CRUD against an "Associates" table.

Users can have multiple associates.

Associates will have:

• FirstName
• LastName
• *baseModel

Pretty basic. New fields will be added as features demand.

• table
• repo
• interactor
• tests
• controller
• controller tests

https://gorm.io/docs/transactions.html

Possibly get rid of "repos" pattern and lift db interactions into the interactors? 🤔

Another option is to have each repo method accept db as a param. Not sure how much I like this though. Originally, I wanted the interactors to be largely unaware of the underlying database mechanism. Keeping db queries isolated to Repos limits the blast radius if I decide to swap out the ORM for something else in the future. I'd like to maintain this isolation if possible.

Basically, I need a mechanism for hot-swapping the Repos' db attribute once a transaction has begun.

Users should be able to search by:

• people's names
• quality names
• notes?

Something like this:

• create person
• create/assign quality
• create person note
• create quality note
• get person w/ notes
• get person w/ qualities and notes
• list people w/ qualities
• list qualities

The interactor tests are nice because they're simple to spin up, but I find more runtime errors slipping through that relate to config/dependency setup. It would be nice to have some end-to-end tests that run server.main and actually poke the server.

This looks promising:
https://dev.to/rafaelgfirmino/pagination-using-gorm-scopes-3k5f

• General login form layout
• Redirect from "/home" to "/login" if user is lot logged in
• Load user information when "/" is visited and user is already logged in
• Redirect from "/login" to "/home" is user is already logged in

If login successful:

• set session cookie
• persist currentUser information in store
• redirect to "/home"

If login not successful:

• display error message

I'm debating whether I want to explicitly pass the segment UUID to every repo method, or find a way to control this at a lower level with scopes...

One one hand, explicitly passing the segment UUID to the repos makes it very clear that the queries are scoped by segment. On the other hand, a dev (me) may forget to add UUID filtering to a repository.

I think it would be safer to set the Segment UUID on the DB context at the start of a request, and use this to automatically scope all queries that occur during the request. If someone forgets to set the Segment UUID on the DB context, the query should fail/error.

And clear the session from sessionstorage

Initiative:

• Title
• Body
• Participants:
  • Person
  • <some info that i don't know what to name> standing? status? thoughts? idk.
• Notes

Titles should have the same weight as People's names.

• journal list
• note list
• quality list

• A user can have multiple people.
• A person can have qualities.
• Qualities can have Notes.
• People can have Notes.
• If a Person's Quality has a note, so does that person.
  All data is segmented.

The data should look something like this(?):

My tests are basically big blobs of multiple test cases/scenarios. I should convert these to be table-driven tests.

It should behave similar to the home-page search, but if the query string is empty then the person list should display all people.

The home-page search will eventually search across multiple datatypes (people, initiatives, notes, etc), so I want to keep the "people" specific search on the people page.

Right now our session tokens are just randomly generated values. This puts us at risk because we are forced to query the database in order to validate the token.

If we switch to JWT's, we can leverage their built-in signature validation to avoid db queries that are guaranteed to fail. Also, we can store the token expiration time in the jwt to avoid another scenario where we know we don't have to query the database.

Ideally, we only query the database when we know there is a good chance of a token being valid. We could also store additional user information in the jwt to avoid having to query for this on each request, but I actually like the idea of requiring a db query to complete token verification. This gives us the ability to revoke sessions before their expiration, and ensures that we don't operate on potentially stale user information.

The UI is very empty once the app starts for the first time. I should fill this empty space with something. Maybe a call to action?

ex:

This issue can be closed when we've configured a basic database to hold user identities and an API for authenticating users.

Non-goals:

• Creating a secure store for personal user data.
• Creating a front-end for users to log in