1) The entirety of the end-points shouldn’t be all in 1 file, it makes it difficult to parse through.
2) The code and endpoint uses “User” to refer to the person using the app, while the database uses “Customer” to refer to the same thing. The code would be a lot more readable if they were the same word.
3) getDailyCarlories returns an Internet Server Error should the user attempt to call it without posting a goal. This is caused by fetchone on a select statement that didn’t return anything.
4) postWorkout should give the user an error if they don’t input an actual workout
5) postGoals shouldn’t allow the user to input a negative calorie count, nor should the database accept that.
6) postWorkout should not allow the user to input a negative sets, reps, or length, nor should the database accept that
7) postUsers shouldn’t allow the user to input a negative weight or height, nor should the database accept that
8) postMeal shouldn’t allow the user to input a negative calorie count, nor should the database accept that
9) You have 2 endpoints with the same function def name, “getWorkOutsByDay”, which only refers to one of them. This def referring to the /workouts/musclegroup/{type} endpoint should have a different name for clarity.
10) getAllMeals returns type, despite that not being a field postMeal could have filled in.
11) getDailyCalories has a select statement that returns one daily_calories value from the goals table based on user_id. Considering that a user may call the postGoals endpoint multiple times, thus creating multiple entries, this return statement may not consistently return the same value as more goals are added (And thus the order by which the goals table is retrieved will change). Currently it returns the first value the user placed in, which may not be true as the goals table grows. (Note: If users are not meant to post more than 1 goal per user, then its still an issue that postGoals allows such a thing).
12) getDailyCalories could have been combined into 1 SQL statement, using a WITH statement to create the subquery
1) The entirety of the end-points shouldn’t be all in 1 file, it makes it difficult to parse through. 2) The code and endpoint uses “User” to refer to the person using the app, while the database uses “Customer” to refer to the same thing. The code would be a lot more readable if they were the same word. 3) getDailyCarlories returns an Internet Server Error should the user attempt to call it without posting a goal. This is caused by fetchone on a select statement that didn’t return anything. 4) postWorkout should give the user an error if they don’t input an actual workout 5) postGoals shouldn’t allow the user to input a negative calorie count, nor should the database accept that. 6) postWorkout should not allow the user to input a negative sets, reps, or length, nor should the database accept that 7) postUsers shouldn’t allow the user to input a negative weight or height, nor should the database accept that 8) postMeal shouldn’t allow the user to input a negative calorie count, nor should the database accept that 9) You have 2 endpoints with the same function def name, “getWorkOutsByDay”, which only refers to one of them. This def referring to the /workouts/musclegroup/{type} endpoint should have a different name for clarity. 10) getAllMeals returns type, despite that not being a field postMeal could have filled in. 11) getDailyCalories has a select statement that returns one daily_calories value from the goals table based on user_id. Considering that a user may call the postGoals endpoint multiple times, thus creating multiple entries, this return statement may not consistently return the same value as more goals are added (And thus the order by which the goals table is retrieved will change). Currently it returns the first value the user placed in, which may not be true as the goals table grows. (Note: If users are not meant to post more than 1 goal per user, then its still an issue that postGoals allows such a thing). 12) getDailyCalories could have been combined into 1 SQL statement, using a WITH statement to create the subquery