Residency Journal: 2026-08-16

Summary

A comprehensive summary of all progress and work completed in the backend residency and the BiteTrack flagship API since the last journal entry on August 10, 2026.

🧠 Practice Mode: DSA & Python Fluency

We completed a significant amount of algorithmic and language fluency practice inside the residency sandbox:
* LeetCode Exercises Solved & Documented:
* Length of Last Word(#58) — Binary search implementations.
* Knowledge Base Expansion:
* Added guide for Python string methods
* Practice Environment:
- Refined AGENTS rules for linking documents pointing to remote repositories rather than file system static links.

🛠️ Build Mode: BiteTrack API

Continue progress on Milestone 1 ; now we're focused on a UserUpdate (general purpose) and UserPasswordUpdate Pydantic schemas.

1. The Request Body Security Issue (target_user and performed_by)

When designing the first contract for UserUpdate, I introduced two fields: target_user and performed_by. The reasoning behind is that on an update operation we always need to know which user is updated, and we would prefer to know who has triggered the change (self-update, admin-assisted update). However, this was immediately corrected by the coach.

In REST API design, we should not pass target_user or performed_by inside the request body model (UserUpdate): target_user belongs in the URL path:

The target user is identified by the endpoint URL (e.g., PATCH /users/me
implicitly targets the logged-in user, and PATCH /users/{id} targets a specific user via the path parameter). Putting it in the body creates redundancy and the risk of conflict (e.g., a path pointing to User A but the body containing the ID of User B).
performed_by belongs in the Auth Header (JWT): The identity of the person making the change must be verified securely on the server using their authentication token. If we let the client pass performed_by in the request body, a malicious user could easily spoof their identity by sending another user's UUID.

2. Missing Validator Inheritance

The new user UserUpdate inherits from BaseModel and not UserBase, this allows the same fields to be defined as optional fields. As a result, they do not inherit the date of birth or password strength validation.

To avoid repeated logic across these two (and potential future) schemas, the validation was externalized to the global helpers validate_password_strength and validate_dob_value. On UserPasswordUpdate, the original password is assumed to be validated. This also allow me to extend further the password strength validation rules in one place later when necessary.

3. User Response Timestamp

UserResponse initially supported the fields id, and created_at.