Lasagna-Love-Portal / bechamel-api

Bechamel: a REST API for Lasagna Love request, requester and volunteer management
Eclipse Public License 2.0
5 stars 4 forks source link

Better separation of structs for user for different needs #7

Open mattkuznicki-ll opened 1 year ago

mattkuznicki-ll commented 1 year ago

There should be a few separate structs here that compose LasagnaLoveUser I think. Let's think of it in terms of access patterns.

There are a couple:

  1. I just want basic metadata about a user (user ID, names)
  2. I want basic info for a user including some contact info (PII): (1) + email
  3. I want the user's login info (userID + hashed+salted password + salt) for login purposes
  4. I want deep PII on the user ((1) + phone numbers, addresses, etc.)

I'm not a fan of one struct that contains all this stuff directly inside.

So, we can make two additional structs:

type LasagnaLoveUserLogin struct {
    HashedPassword string `json:"hashed_password,omitempty"`
    PasswordSalt string `json:"password_salt",omitempty"`
    HashedEmail string `json:"email_sha256",omitempty"`
}

and something similar for LasagnaLoveUserContactInfo that contains the plaintext email, addresse(s), phone(s), etc.

Then, in the LasagnaLoveUser struct, you can have fields for LoginDetails, ContactDetails with types *LasagnaLoveUserLogin (notice the *), etc. You can use the omitempty json directive there. That way, if that struct isn't populated at all, it's omitted entirely from the output. And we can still use LasagnaLoveUser across the various APIs... some of the nested structs may just be empty if we don't need that data.

_Originally posted by @iamthebot in https://github.com/Lasagna-Love-Portal/bechamel-api/pull/1#discussion_r1185728788_