- HelloMelon API
- Lambda Perpetual Access Fund
- Authors
- Covered Use Cases
- Technologies
- Setup
- User Model
- Food Model
- Meal Category Model
- Food Entry Model
- Exercise Entry Model
- Weight Entry Model
- Coaches Model
- Messages Model
- Billing Model
- License
This API covers all key use cases related to the HelloMelon. The API uses Graph QL which is a query language for APIs and it gives users the ability to query exactly what is needed and nothing more.
As of now, using HelloMelonr API can only be used in conjunction with Google's Oauth2 API as it is used to check for a verified and active Token upon logging in for the front end.
Whether you use this project, have learned something from it, or just like it, please consider supporting it by donating to Lambda School's Perpetual Access Funds. This fund is used to provide student who have financial needs be able to continue their journey in Lambda School
Every dollar you donate to the Fund will be used to help someone create a new life for themselves. We hope you'll join us in helping students who need it most.
note: click on the image below to donate:
- Creating, Updating, Reading
- users
- Full CRUD functionality for
- foods
- foodEntries
- messages
- exerciseEntries
- weightentries
- Create, Read, and Delete
- coaches
- billing
- Read functionality for
- mealCategories
Using the API for the front end requires a check using Google's Oauth2 Client API. This would check against the user info and would result in an active token to be used in the headers
Project is created with:
- Apollo Server version: 2.5.0
- dotenv version: 8.0.0
- google-auth-library version: 4.0.0
- graphql version: 14.3.0
- graphql-merge-resolvers version: 1.1.10
- knex version: 0.17.6
- pg version: 7.11.0
- sqlite3 version: 4.0.8
- strip version: 7.1.0
To run this project, install it locally using yarn:
$ cd nutrition-tracker-BE/
$ yarn install
$ yarn start
Or to use an already existing API to get started:
The following are the data that can be returned in User Model Queries:
- id
- firstName
- lastName
- userType
- calorieGoal
- weight
- foodEntries - uses foodEntries model
- exerciseEntries - uses exerciseEntries model
- stripe_id
- trainees
Note: There are 3 userType: basic, premium, coach
getCurrentUser: this query requires an object in the HTTP header with the following key value pairs.
{ "authorization": "THE_GOOGLE_TOKEN_GENERATED"}
The following is an example of a getCurrentUser query:
The following is an example of a getUsers query:
getUserBy: this query uses two arguments to check the API for a user that has that specific param - value match.
1) param: a column from the User model
2) value: a String value
The following is an example of a getUserBy query:
The following is an example of a getUserById query:
getFoodEntriesByUserId: this query uses a userId argument to query all the food that belongs to that specific userId.
The following is an example of a getFoodEntriesByUserId query:
Note: This query uses the FoodEntries Model which will be mentioned in a further section
getExerciseEntriesByUserId: this query uses a userId argument to query all the exercise activities that belongs to that specific userId.
The following is an example of a getExerciseEntriesByUserId query:
Note: This query uses the ExerciseEntries Model which will be mentioned in a further section
Note: It uses the following arguments wrapped in an input object with all being mandatory except for the weight
firstName: String!
lastName: String!
email: String!
userType: String!
calorieGoal: Int!
weight: Int
The following is an example of a addUser mutation:
updateUser: this mutation edits an existing user entry in the API. Like the addUser, it requires the same mandatory arguments. Only weight is optional
It differs in that it has two main argument:
1) id
2) input object - The same input from addUser
The following is an example of an updateUser mutation:
It contains only the id argument and requires no output as it returns a 1 for successful deletion and 0 for unsuccessful deletions.
The following is an example of a deleteUser mutation:
The following are the data that can be returned in Food Model Queries:
- id
- foodName
- caloriesPerServ
- fats
- carbs
- proteins
- edamam_id
- foodEntries - uses foodEntries model
The following is an example of a getFoods query:
The following is an example of a getFoodById query:
Note: It uses the following arguments wrapped in an input object with all being mandatory except for edamam_id
foodName: String!
caloriesPerServ: Int!
fats: Float!
carbs: Float!
proteins: Float!
edamam_id: String
The following is an example of an addFood mutation
updateFood: this mutation edits an existing food object entry using two arguments. Like addFood, it uses the same mandatory arguments.
It differs in that it has two main argument:
1) id
2) input object - The same input from addFood
The following is an example of an updateFood mutation
It contains only the id argument and requires no output as it returns a 1 for successful deletion and 0 for unsuccessful deletions.
The following is an example of a deleteFood mutation:
Due to executive decisions, we've decided remove update, edit, and delete of meal categories in order to simplify meals into 4 categories.
1) id: 1, mealCategoryName: Breakfast
2) id: 2, mealCategoryName: Lunch
3) id: 3, mealCategoryName: Snack
4) id: 4, mealCategoryName: Dinner
The following are the data that can be returned in Meal Category Model Queries:
- id
- mealCategoryName
- foodEntries -uses foodEntry Model
The following is an example of a getMealCategories query:
getMealCategoryBy: this query uses two arguments to check the API for a mealCategory that has that specific param - value match.
1) param: a column from the User model
2) value: a String value
The following is an example of a getMealCategoryBy query:
getMealCategoryById: this query uses an meal category's id as an argument to query a meal category with that specific id.
The following is an example of a getMealCategoryById query:
The following are the data that can be returned in FoodEntry Model Queries:
- id
- date
- food_id - can return food model data
- user_id - can return user model data
- servingQty
- meal_category_id - can return meal category model data
The following is an example of a getFoodEntries query:
The following is an example of a getFoodEntriesById query:
Note: It uses the following arguments wrapped in an input object with all being mandatory
date: Date!
food_id: ID!
user_id: ID!
servingQty: Int!
meal_category_id: ID!
The following is an example of an addFoodEntry mutation
updateFoodEntry: this mutation edits an existing food entry object entry using two arguments. Like addFoodEntry, it uses the same mandatory arguments in input.
It differs in that it has two main argument:
1) id
2) input object - The same input from addFoodEntry
The following is an example of an updateFoodEntry mutation
It contains only the id argument and requires no output as it returns a 1 for successful deletion and 0 for unsuccessful deletions.
The following is an example of a deleteFoodEntry mutation:
The following are the data that can be returned in Exercise Model Queries:
- id
- exerciseEntryDate
- exerciseName
- caloriesBurned
- exercise_entry_user_id - uses the User Model
The following is an example of a getExerciseEntries query:
getExerciseEntryBy: this query uses two arguments to check the API for an exercise entry that has that specific param - value match.
1) param: a column from the exercise entry model
2) value: a String value
The following is an example of a getExerciseEntryBy query:
getExerciseEntryById: this query uses an exercise entry id argument to query an exercise entry with that specific id.
The following is an example of a getExerciseEntryById query:
Note: It uses the following arguments wrapped in an input object with all being mandatory
exerciseEntryDate: Date!
exerciseName: String!
caloriesBurned: Int!
exercise_entry_user_id: ID!
The following is an example of an addExerciseEntry mutation
updateExerciseEntry: this mutation edits an existing exercise entry object entry using two arguments. Like addExerciseEntry, it uses the same mandatory arguments in input.
It differs in that it has two main argument:
1) id
2) input object - The same input from addExerciseEntry
The following is an example of an updateExerciseEntry mutation
It contains only the id argument and requires no output as it returns a 1 for successful deletion and 0 for unsuccessful deletions.
The following is an example of a deleteExerciseEntry mutation:
The following are the data that can be returned in weightEntry Model Queries:
- id
- date
- weight
- user_id - This uses the user model data
The following is an example of a getWeightEntries query:
getWeightEntriesByUserId: this query uses a userId as an argument in order to get all the weight entries made by that user.
The following is an example of a getWeightEntriesByUserId query:
Note: It uses the following arguments wrapped in an input object with all being mandatory
date: Date!
weight: Float!
user_id: ID!
The following is an example of an addWeightEntry mutation
updateWeightEntry: this mutation edits an existing weight entry object entry using two arguments. Like addWeightEntry, it uses the same mandatory arguments in input.
It differs in that it has two main argument:
1) id
2) input object - The same input from addWeightEntry
The following is an example of an updateWeightEntry mutation
It contains only the id argument and requires no output as it returns a 1 for successful deletion and 0 for unsuccessful deletions.
The following is an example of a deleteWeightEntry mutation:
The following are the data that can be returned in Exercise Model Queries:
Note: The coaches model uses the User model for both its coach and trainee data. It's a purely relational table.
- id
- foodName
- caloriesPerServ
- fats
- carbs
- proteins
- edamam_id
- foodEntries - uses foodEntries model
getTrainees: this query uses a coach_id as an argument in order to get a list of that coach's trainees.
The following is an example of a getTrainees query:
getCoaches: this query uses a trainee_id as an argument in order to get a list of that trainee's coach(es).
The following is an example of a getCoaches query:
Note: As the coaches table is a relational table, it's arguments are coach_id and trainee_id only. The result of both the addTrainees and deleteTrainees are the same data coming off a user model.
addTrainees: this mutation uses coach_id and trainee_id in that order in order to add a trainee to the coach's list of trainees.
The following is an example of an addTrainees mutation:
deleteTrainees: this mutation uses coach_id and trainee_id in that order in order to delete that trainee from the coach's list of trainees.
The following is an example of an deleteTrainees mutation:
The following are the data that can be returned in Messages Model Queries:
- id: ID!
- created_at: Date!
- type: String!
- text: String!
- read: Boolean!
- sender: User!
- recipient: User!
getMessagesBy: this query uses two arguments to query message(s) based on the param (the table columns), and the value: the value of the column. It returns objects that matches the param: value
The following is an example of an getMessagesBy query:
Note: It uses the following arguments wrapped in an input object with all being mandatory
type: String!
text: String!
read: Boolean!
sender: ID!
recipient: ID!
The following is an example of an addMessage mutation
updateMessage: this mutation edits an existing message entry object entry using two arguments. Like addMessage, it uses the same mandatory arguments in input.
It differs in that it has two main argument:
1) id
2) input object - The same input from addMessage mutation
The following is an example of an updateMessage mutation
It contains only the id argument and requires no output as it returns a 1 for successful deletion and 0 for unsuccessful deletions.
The following is an example of a deleteMessage mutation:
The following are the data that can be returned in a Billing Model Queries:
- id: ID!
- date: Date!
- user_id: User!
- amount_paid: Int!
getBillingHistory: this query uses the user_id as an arguments to query the billing history of a user. It returns an object with all the payments a user has made.
The following is an example of a getBillingHistory query:
getRecentBilling: this query uses the user_id as an argument to query the most recent payment a user has made. It returns an object just the most recent payment. If a user has not upgraded, it returns null.
The following is an example of a getRecentBilling query:
createSubscription: this mutation uses three argument: source, email, and amount. The source is a String that stripe sends back as a temporary made up number for charging a card, the email is a user's email, and the amount is 700 (premium) or 1000 (coach) depending on the user type.
The following is an example of a createSubscription mutation:
updateUserType: This mutation updates a user's userType to a basic user if the date from the last payment is greater than 30 days. It returns a value of 1 as a response.
The following is an example of a updateUserType mutation:
You can check the full license here
This project is licensed under the terms of the MIT license
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent