Schema/API Design Comments (Rhoyalinn Cereno)

[rcereno]

Great work on the API Design & Schema. Here are a few suggestions:

1. First thing I noticed is that there is no API key needed when opening up Render to test. For security purposes, I would recommend implementing and adding an API key to the Render production docs website page to ensure safety and security.

2. There should be a user endpoint, to be able to return the user and/or also to update like a profile of personal information and stats, as well as being able to update their weight and height, as that can change over the years. Adding PUT /user.

3. Tables do not have a created_at timestamptz column. It would be helpful to add when coming to testing and tracking, especially when dealing with a lot of data and information later on or as workouts and information continuously updates.

4. When testing out POST/workout, I am getting an internal service error and not sure if I am inputting incorrect values? I wrote this: { "name": "push-up", "sets": 3, "reps": 7, "length": 30 } I am thinking it may have to do with my input for length or name, as there was a note mentioned how there may be restricted workout with specific options, in relation to the name.

5. Similar to as mentioned in code review, make several tables' values unsigned to ensure that it is a positive number, such as with weight, height, reps, sets, etc.

6. ^ In addition to referring to something mentioned in my code review, tables should also set/assign some variables with their respective measurement units.

7. In the APISpec, the API is stated as /goal/ but in main.py, it is used plurally as /goals/. Same as with /workout/, Unless they are meant to be different endpoints of no relation, then the names should be more distinct and specific as one is singular and the other is plural.

8. Function getWorkoutsByDay is used by different endpoints with GET /workouts/{customer_id}/day and GET /workouts/muscle_groups/{type}. For each respective endpoint, they should be pointed to one function name and not the same, even if split into two functions but of the same name, to which I recommended during code review to rename to a different one.

9. Similar to breaking up the main.py into different files and categories, for better readability, placing similar and related endpoints into separate files of similar areas would be helpful for readability and testing with Render.

10. In the API Spec, GET /workout/personal/muscle_groups/{type}(1.9), GET /meal/day(1.5), and GET /workout/day (1.6), do not have a GET call function in main.py or not defined yet.

11. In terms of inconsistency with the API call names, GET /workout/{workout_id}/muscle_groups isn't the same as stated in API Spec which has /workout/{id}/muscle_groups - although the id will be replaced with the id, it should be consistent and specific as it could be uncertain with what id as there could be userid and such.

12. For muscle group types, will it also account for those type of exercises that target multiple groups and also multiple types, such as some that target both glutes and hamstrings, etc. or for kettlebell swings, which target diverse muscle groups {types and groups in this case} at once.

13. For POST /meal/{customer_id}, whenever I input calories, when it comes to what returns in GET /daily_calories/{customer_id}, it returns a negative value but adds the amount of calories, such as when inputting a meal with 500 calories and then 80 calories, in the GET call, it will return as "calories_left": -580. Is it being a negative value intended or since we don't have a set amount of calories of the user yet so it will just subtract from the later information of total calories to be consumed a day, later on?

14. There are places throughout the code I would recommend being more specific or just being able to add more information, since there could be errors or confusion that pops up. Some examples is being consistent with the input types when it comes to using integers or decimals with the height and weight, etc., as well as the types of workouts, whether it is based on muscle group and/or type and also to what kind of goals (unless it doesn't matter or affect it too much), since there are different types of goals, whether it's physical, mental, etc. such as a reach a specific PR or drinking more water, or even diet wise.

I could also be misunderstanding or misinterpreting some of the schema and calls as well, so if my comments do not make sense, please disregard.

[rcereno]

Comment about POST /workout/{customer_id} realized that there are only a few accepted name types so no internal service error but pops up when name is not recognized.

[rcereno]

GET /meal/{customer_id}/day also has a type that returns as null. Is that necessary?