Perhaps I was unclear. What I meant to say is that, whenever possible, we shouldn’t have multiple versions of a field, especially when there is no corresponding plaintext password field in the database, as is the case here.

I appreciate the security concerns, but I wouldn’t consider overriding the password property with the hashed password to be wrong. Raw passwords are typically only needed in three places: user creation, login, and password reset. I’d argue that having both password and hashedPassword properties in the user object may actually lead to confusion, since user objects are normally used in hundreds of places throughout the codebase. I think, when applicable, we should consider balancing security with code maintainability by avoiding redundancy and potential confusion.

Thanks for the tip. password.trim() can indeed be problematic. I just removed that line.

That idea crossed my mind too, but you can’t really use the full capabilities of SQL in graph databases, and that’s a deal breaker for me.

There’s certainly the danger of creating too many ad-hoc or sparse relationships, which can cause issues. That said, when used for supplementing foreign keys, Tie-in can be a useful tool in a production system as well.

Yes, that’s correct. Here’s how an entry in the join table looks like:

{
  "id": 6,
  "sourceComp": "user",
  "sourceId": 2,
  "targetComp": "post",
  "targetId": 3,
  "type": "author",
  "createdAt": "2024-03-28T13:28:59.175Z",
  "updatedAt": "2024-03-28T13:28:59.175Z"
}

AFAIK, no NoSQL database fully supports SQL, and only some offer support for transactions and joins. The idea here is to augment a relational database by adding capabilities for dynamic relationships.