Schema/API Design Comments (Sam Todd)

[SamuelTodd]

1. Duplicate function names across different endpoints – Currently, both GET /workouts/{customer_id}/day and GET /workouts/muscle_groups/{type} refer to functions named getWorkoutsByDay. The name of the second occurrence of getWorkoutsByDay should be changed to something like getWorkoutsByMuscleGroup for clarity.
2. Add API key on Render for security – In order to prevent unauthorized users from accessing and modifying your production database or using your application, you should add an API key to your production site. To do this, go to Render and add an API key secret variable. In your repository, create an auth.py follow similar to (or the same as) the one from the initial Potion Shop code.
3. Separate endpoints of similar types into different files – Instead of storing all the endpoints for the entire application in one file, it would be better for readability to break this file up into different ones for each of the main components of the application. Additionally, when you use separate files, endpoints on the Render docs are put into separate buckets. Overall, separating these endpoints would help both readability of the code and make testing more straightforward.
4. Remove /day from the GET /meal/{customer_id}/day endpoint – If the endpoint is meant to return all meals eaten in a specific day, then there should be some additional argument or explanation for the purpose of the endpoint. Otherwise, if the endpoint is just meant to return all meals for a specific customer, then it does need the /day.
5. Standardize workout endpoints into either /workout/ or /workouts/ - There are currently two endpoints that start with /workout/ and two that start with /workouts/. If they are meant to be different, they should have more distinct names than the one letter difference. Otherwise, they should all be standardized to /workout/ as specified in the APISpec.md file.
6. Create exercises_muscle_groups join table – This table will allow you to associate each exercise with multiple muscle groups instead of limiting each workout to referencing a single muscle group.
7. Create meal_ingredient join table – Similarly to the previous recommendation, there should be an additional join table between meals and ingredients. With the current schema design, each meal can only have one ingredient associated with it. Since meals generally are made up of a variety of ingredients, a join table would be useful in this context.
8. Replace “character varying” types with “text” – Instead of using character types of varying length, it would be best to just use the text data type in Supabase as was generally used throughout the potion shop projects.
9. Rename and restructure the GET /workouts/muscle_groups/{type} and GET /workout/{workout_id}/muscle_groups endpoints – As mentioned in the previous code review section, the /workout/ and /workouts/ should be standardized to one of the two. Additionally, the overall endpoint signatures of these functions are too similar. For example, it may be helpful to rename one to GET /muscle_groups/{workout_id} so that it is clear that you are retrieving the muscle groups, not the workout.
10. Modify POST /meal/{customer_id} to include the ingredients for a meal – It may be useful to allow the user to specify a list of ingredients that belongs to a meal in this endpoint so that all the information needed to classify the meal is recorded at one time. The alternative would be to add a POST /ingredient endpoint, but I think this is less intuitive. Depending on the way meals are implemented. It may also help to allow users to modify the meal and its ingredients with a PUT /meal/{customer_id} endpoint.
11. Create a PUT /user endpoint - Since users will be using this application for years to come, there should be a way for users to update their personal information, specifically their height and weight. A PUT /user/ endpoint would allow users to update their personal information such as name, height, and weight.
12. Add created_at variables to all tables – While these variables do not provide much additional functionality, they will be helpful throughout testing. Add automatically generated created_at times using now() on Supabase.