Team Swee (Group 2) Deployed Website
This repository contains both the backend and frontend portions of the project.
Schema defined in api/model/user.js
User role
is used in authorization
Defined in api/controllers/userController.js
- GET
/api/users
Reads the current logged in user, returns 403 if not logged in. - GET
/api/users/roles/:role
Returns a list of users at the role, omitting sensitive data. - DELETE
/api/users/:id
Removes the user with given id:id
(requires authorization) - PUT
/api/users/:id
Updates the user with given id:id:
(requires authorization) - POST
/api/users
Creates a new user, requires captcha token - POST
/api/login/reset
Generates a forget password token for a provided email - POST
/api/users/password/:token
will update the password of the user tied to the token.
- POST
/api/users/card/:id
creates a new card object for user:id
(requires authorization) - POST
/api/card
generates a new card (for use with guest customers) - GET
/api/card/:cardID
returns a card with id:cardID
(requires authorization) - GET
/api/users/card/:userID
returns all cards on user:userID
(requires authorization) - DELETE
/api/users/card/:userID
removes a card from user:userID
(requires authorization) - PUT
/api/users/card/:userID/:cardID
updates the card:cardID
on user:userID
(requires authorization)
- POST
/api/login
creates a new login session for a given user - DELETE
/api/logout
destroys the current login session
Role-based Authorization Scheme defined in api/helpers/ability.js
userAbilities(user)
will deterministically return the permissions of a given user.
The default module export will return currentUserAbilities()
, which uses the session to determine the logged in (or guest) session's permissions.
Schema defined in api/model/appointment.js
Defined in api/controllers/appointmentController.js
- GET
/api/appointments/:id
will return the information for a given appointment (requires authorization) - GET
/api/appointments/users/:email
returns the appointments for a user given by:email
(requires authorization) - GET
/api/appointments
returns all appointments (requires authorization) - GET
/api/appointments/status/:confirmed
Get all appointments given their confirmation status (requires authorization) - DELETE
/api/appointments/:id
Deletes an appointment with id:id
(requires authorization) - PUT
/api/appointments/:id
Updates a given appointment with id:id
. If confirmed is set totrue
, this route will send confirmation emails. (requires authorization) - POST
/api/appointments
Creates a new appointment and sends request pending email.
Schema defined in api/model/service.js
Controller defined in api/controllers/serviceController.js
- POST
/api/services
creates a new Service (requires authorization) - GET
/api/services
returns all services - GET
/api/services/types/:type[/:subtype]
returns all services given type (and optional subtype). - GET
/api/services/types
returns all used types and their respective subtypes. - PUT
/api/services/:id
updates a service given the id:id
(requires authorization) - DELETE
/api/services/:id
removes a service with id:id
(requires authorization)
Schema defined in api/model/review.js
Controller defined in api/controller/reviewController.js
- POST
/api/reviews
creates a new review (requires authorization) - PUT
/api/reviews/:id
updates the review with id:id
(requires authorization) - GET
/api/reviews/:id
returns the review with id:id
- GET
/api/reviews
returns all reviews - DELETE
/api/reviews/:id
deletes the review with id:id
(requires authorization)
The backend uses a modular initialization function in order to load the server based upon the value of NODE_ENV
(see "Environment Variables"). See api/config/initializers
for the initialization function per environment state.
The backend uses Express to serve the frontend in development and production. In development
, the backend will proxy a connection to the react development server. In production
, the backend will serve the built version of the app located in build/client/
This project requires NodeJS and uses Yarn as a package manager. After cloning,
# Move from master to the develop branch
git checkout develop
git pull
# Installs required packages
yarn install
# Starts both the backend and the frontend
yarn start
In development, environment variables may be loaded using a .env
file. See dotenv for more information.
NODE_ENV
: The NodeJS environment vairable for determining runtime environment. Use this to differentiate running locally for in production.PORT
: WhenNODE_ENV
is set toproduction
,PORT
is used for what port the backend will listen on. Defaults to 8080 in other environments.STORE_KEY
: WhenNODE_ENV
is set toproduction
,STORE_KEY
is used to define the salt for hashing session keys.DB_URL
: The url of the MongoDB database to be used whenNODE_ENV
is set toproduction
DB_URL_DEV
: The url of the MongoDB database to be used whenNODE_ENV
is set todevelopment
DB_URL_TEST
: The url of the MongoDB database to be used whenNODE_ENV
is set totest
LOGGING
: The logging level to be displayed, the following are valid values:emerg
,alert
,crit
,error
,warning
,notice
,info
,debug
SENDGRID_API_KEY
: The api key used to connect to the Sendgrid API (email)STRIPE_API_KEY
: The api key used to connect to Stripe for billing.RECAPTCHA_SITE_KEY
: The reCaptcha site key (public key)RECAPTCHA_SECRET_KEY
: The reCaptcha secret key (private key)
To keep things clean for the production environment, we will be using Git Flow. In summary, the master branch represents production ready versions, while the develop branch and feature branches represent in development work.
One of the hardest parts of this project is going to be the fact that many of us are new to this, but still wanting to make something quality. Therefore, here are some things to have laid out now to keep in mind as you work.
This project environment is equipped with a style checker called ESLint. The point of a style checker is to have defined rules laid out about the style of code, and having a way to check if you are breaking any of these rules, with the goal of making everything look homogeneous.
If you are using VS Code, I recommend installing the eslint extension.
Regardless of using the extension or not, at anytime use yarn front-lint
or yarn back-lint
to run the style checking on either portion of the project.
Both the frontend and backend are equipped with Jest for unit tests. Unit tests are very important on the backend, but due to the nature of the frontend I would recommend only unit testing certain complex components.
There is only a single testing command, yarn test
, which will bring up a menu as described in the Project Commands section. The reasoning behind a single testing commands is because tests are important enough that is one team is failing their tests for any reason, everyone should be aware of it.
Contains the backend, including all controllers, models, start up files, and tests.
Contains the frontend, including all assets, pages, and tests.
The destination folder of any built versions of the project. When running the backend, the version of the server present in /build/api
will be run.
Scripts generated by create react app. These get called when handling the frontend running, building, and project tests.
Starts a local development instance of the project.
(Runs front-run
and back-run
)
Builds a production ready version of the frontend and backend
Starts the React dev server locally on port 3000
Runs style checking on the frontend
Builds a production ready version of the frontend
Enters the Jest test framework. This is a framework provided by Create React App.
Runs builds a runnable version of the backend
Runs task back-build
and runs the built version
Runs style check on the backend