You must have NodeJS and Docker (or Docker Desktop) installed.
npm i to install all packages
There are two ways to run this API
The preferred way to develop since it spins up all components for you in one command and follows your code changes automatically.
- All code must work in the Docker container since our work deploys with Docker containers.
- Ensure no other programs are using ports 8000. If you run into issues, try closing containers first.
- Create a
.env.developmentfile as specified in.env.example- For help with Google Auth, refer to the Google Cloud App Setup section
- If you changed schemas in
prisma/schema.prisma, follow instructions here for more info on how to properly change schemas and run migrations.- You might need to change your
.env.developmentfile to use db@localhostsince the build command uses the same.envfile as the Docker container.
- You might need to change your
- Run
npm run docker:devto start the docker containernpm run exitdocker:devto exit containersnpm run cleandocker:devto exit containers and remove created volumes- Sometimes you might have to docker compose down (exitdocker) to start again.
- Run tests with
npm run docker:test- This uses the
docker-compose.test.ymlfile.
- This uses the
Warning: This was not tested extensively unlike using Docker for development
Optional: Docker (for using SQL Container)
- Look at
.env.exampleto create your own.env.developmentfile - Run
npm run sql:devto start a local db with Docker.- You can also choose to spin up your own Postgres instance and change the .env file to reflect that endpoint.
- Run
npm run build:devto run SQL migrations and build the Prisma Client- This should not ask you to create a new migration, just to migrate changes to your blank database.
npm run devto run the server locallynpm run test:devto run local tests (must close dev server first)- Run
npm run exitsql:devto exit Docker SQL container. Your data will persist even after closing the container.- Optionally run
npm run cleansql:devto exit the SQL container and delete persistent storage warning: this deletes all your persistent db data stored locally.
- Optionally run
Before you push any changes, please make sure to check if your changes work by running them in the Docker containers in (2). Then add your changes to a branch, push to the GitHub repo and create a pull request. You might have to run npm run build:dev if you updated /prisma/schema.prisma
Do not push directly into main
You can look at ./package.json to view the npm scripts used in these steps.
Documentation is automated with Swagger-JSDoc and Swagger-UI and availble at {base_url}/docs. Please refer to:
- OpenAPI Docs for OpenAPI documentation spec
- How to Document an Express API with Swagger UI and JSDoc for a tutorial on using JSDoc with Swagger.
./app/config/swaggerconfig.jsand./app/routes/User.routes.jsfor some examples on reusable OpenAPI schemas and JSDoc documentation respectively
Logging is done with winston. Ensure that there is an environment variable with LOG_LEVEL set so that the logger logs at the correct level.
Linting is done with eslint. Please run npx eslint . or npx eslint yourfile.js to check for linting errors. This is also done on pull request
Testing is done with Supertest and Jest. Run tests locally with npm run test:dev
Zod is used for input validation. Some controllers require more control over validation, so Zod does not handle some fields in those cases.
Deployment can be done either direct code deploy or Dockerized. The Dockerfile along with the root directory is all you need to give a hosting service to start the server. Currently, the server is running as a Docker container in a cloud hosting provider.
On a commit to main, the code is automatically uploaded via Docker containers to a cloud hosting provider such as Azure, AWS, or Render.
- If
prisma/migrationsis changed (meaning you should have run the migrate dev command), then the migrations are automatically deployed withprisma migrate deployto the cloud database provider via a GitHub action.
Tests are done on Pull requests which require the use of multiple secrets. Please check the repository's environment->secrets settings to see these if you are an admin. You might need to change/add to this list, along with the associated workflow files, if environment variables get added or changed.
Deployment database is a PostgreSQL instance hosted on Supabase. Although Supabase has an API, we don't use this as Supabase might not be the best option in the future, so the only code to change if a migration occurs is the database URI.
Azure Blob Storage is used for file storage and the .env.example file should have the required environment variables to connect to the Azure Blob Storage account. If you change the file storage provider, you can change the Application controller and env files in CI/CD to match.
- Change the
priisma/schema.prismafile to reflect your changes- New fields to existing models need either a default value or nullable. Once a default value is populated for every existing entry, you can remove the default value.
- Go to prisma.md and follow the instructions to create a migration and update your local database
- Update
app/database/Prisma.jsby adding your fields to the zod validations- There is a main schema for each model and then a "user" and "admin" role that will remove/add in fields based on the role
- Add to the Prisma extensions on the bottom similar to this existing snippet:
- Add your schema changes to
app/config/swaggerconfig.jsto update the documentation.
async create({ args, query }) {
// upon a creation, check the userRole (which needs to be passed in as userRole when performing a query)
const role = args.userRole || Role.USER;
delete args.userRole;
if (role === Role.ADMIN) {
args.data = adminUserCreateSchema.parse(args.data);
} else {
// Validate the data against the schema
args.data = userCreateSchema.parse(args.data);
}
return query(args);
},