Recipes API with a social graph

The problem

Project 2 layered a real social graph (users → follow → users, users → like → recipes) onto the auth API, and added the kind of search that forces you to think about your schema: 'find recipes that only use ingredients I have.'

On top of that: delete a user, and every recipe, like, and follow they created has to evaporate atomically.

Approach

• Promoted the JWT to live in the HTTP Authorization header instead of a POST parameter, so every endpoint reads identity the way real APIs do.
• Modeled the social graph with a many-to-many follows table and a recipe ↔ ingredient join table, with foreign keys and ON DELETE CASCADE so a user delete unwinds the graph in one transaction (with SQLite foreign_keys = ON set per connection).
• Implemented three search modes in /search: a follow-aware feed (recent recipes from users you follow), a top-N popularity ranking by like count, and an ingredient-subset search (recipes whose ingredients are entirely contained in the user's pantry).
• Wrote a dynamic recipe-view endpoint that returns only the fields the caller asks for, name, description, like count, ingredients, so the API is honest about what it transmits.
• Kept every query parameterized, and put DB access inside try/except/close blocks so a bad request couldn't leave a locked database for the next test case.

Impact

• A non-trivial relational schema with real cascading deletes and three meaningfully different search modes, beyond the usual 'CRUD a single table' assignment.
• Reuses the from-scratch JWT plumbing, now read from the HTTP header instead of a POST parameter.

Stack