yhtminceraft1010x / cs3219-old-project Goto Github PK

Prerequisites for PeerPrep Monorepo:

1. Yarn: Ensure you have the latest version of Yarn installed. Yarn Workspaces is available in Yarn v1.0 and later.

2. Installation (if not already installed):

   npm install -g yarn

3. Node.js: Check each application's documentation for the recommended Node.js version.

4. Git

5. Docker (If deploying with Docker):

6. Kubernetes Tools (If deploying with Kubernetes):

Adjust these prerequisites based on the specific requirements of your services / frontend.

/peerprep
├── /services
│   ├── /admin-service (express application)
│   ├── /user-service (express application)
│   ├── /matching-service (express application)
│   ├── /question-service (express application)
│   ├── /collaboration-service (express application)
│   └── /gateway (express application)
├── /frontend
│   └── /pages for peerprep (NextJs application)
├── /deployment
│   ├── /gke-prod-manifests
│   ├── /prod-dockerfiles
│   └── build-export-prod-images.sh
├── /prisma
├── /utils
├── .env (not in git)
├── .env.firebase_emulators_test (not in git)
└── README.md (and other root-level files & docs)

1. Ensure that you have an .env file at the root directory with the following variables:

   PRISMA_DATABASE_URL=<redacted>
   MONGO_ATLAS_URL=<redacted>
   FIREBASE_SERVICE_ACCOUNT=<redacted>
   NEXT_PUBLIC_FRONTEND_FIREBASE_CONFIG={"apiKey": <redacted>,"authDomain": <redacted>,"projectId": <redacted>,"storageBucket": <redacted>,"messagingSenderId": <redacted>,"appId": <redacted>}
   TWILIO_ACCOUNT_SID=<redacted>
   TWILIO_API_KEY=<redacted>
   TWILIO_API_SECRET=<redacted>

Note: For NEXT_PUBLIC_FRONTEND_FIREBASE_CONFIG, the JSON should not have newlines since Next.js may not process it correctly. The difference between it and FIREBASE_SERVICE_ACCOUNT are shown below:

2. Installing secret detection hooks: From the root directory, run:

   pip install pre-commit
   pre-commit install

This step requires Git to be installed.

Disclaimer: There is no guarantee that all secrets will be detected. As a tip, if you think a file will eventually store secrets, immediately add it to .gitignore upon creating it in case you forget later on when you have a lot more files to commit.

3. Installing Dependencies: From the root directory (/peerprep), run:

   yarn install

   or

   yarnpkg install

   (if you have hadoop yarn installed)

   If you want to use the exact yarn.lock versions without any modification, add a --frozen-lockfile flag to the command.

   This command will install dependencies for all services and the frontend in a centralized node_modules directory at the root as well as within the respective directories.

4. Adding Dependencies: To add a dependency to a specific workspace (e.g., user-service), use:

   yarn workspace user-service add [dependency-name]

5. Initializing Prisma: In the root file, run the following:

   yarn prisma generate ## Do this whenever we change the models in schema.prisma

6. Running Backend Scripts: To run a script specific to a workspace (e.g., the start script for user-service), use:

   yarn workspace user-service start

7. Running Frontend Scripts: To run the frontend cod, use:

   yarn workspace frontend dev ## For development
   
   # or
   
   yarn workspace frontend build ## For first time setup run the build command
   yarn workspace frontend start ## For subsequent runs

8. Running everything at once: To run everything at once and still maintain the ability to hot-reload your changes, use:

   ./start-app-no-docker.sh # on mac /linus
   
   # You can also use the above command on Windows with Git Bash
   

Docker and Docker Compose are used to set up a simulated production build (meaning that the Docker images and containers that will be spun up locally are almost identical to those in the production environment, with the exception of some environment variables).

NOTE: Do not run both Docker and No Docker at the same time. This will cause port conflicts.

1. Run yarn docker:build: From the root repo, run

yarn docker:build 

This will create new Docker images.

2. Run yarn docker:devup: From the root repo, run

yarn docker:devup 

This will start all the containers.

Run the start-app-with-docker.sh script: From the root repo, run

./start-app-with-docker.sh # on mac / linus

# You can also use the above command on Windows with Git Bash

This will create new Docker images everytime it is run. Be careful of how much disk space you have left.

3. Once done, run yarn docker:devdown: From the root repo, run

yarn docker:devdown 

This will stop and delete all the containers. You must run this to delete containers regardless of whether you used ./start-app-with-docker.sh or yarn docker:devup.

Any edits you make to the source code will not be automatically reflected on the site. We recommend using Docker Compose to check if your changes are likely to work on the production environment once they have been proven to work in your local development environment.

• To test all features of the application, you will need 2 GitHub accounts.
• You must login on both accounts on the same computer, since the setup assumes that services are centralised services just like in the production environment.
• You can do the login for your second account by opening a new browser tab in incognito mode.

Access to remote databases may be blocked when using NUS WiFi. You will need a VPN to overcome this limitation if you are running the local app on campus.

• Always ensure thorough testing after adding or updating dependencies to ensure all parts of the system function as expected.

Next steps:

1. Set the PRISMA_DATABASE_URL in the .env file to point to your existing database. If your database has no tables yet, read https://pris.ly/d/getting-started
2. Set the provider of the datasource block in schema.prisma to match your database: postgresql, mysql, sqlite, sqlserver, mongodb or cockroachdb.
3. Run prisma db pull to turn your database schema into a Prisma schema.
4. Run prisma generate to generate the Prisma Client. You can then start querying your database.

The Firebase Local Emulator Suite is used to support automated testing of any Firebase-related functionality.

The following files at the project root define the Firebase project as well as the emulators used:

• .firebaserc - The Firebase project definitions
• firebase.json - The emulators that are used

For local testing, the file used for passing in environment variables has to be named:

.env.firebase_emulators_test

This file should contain the following environment variables:

FIREBASE_AUTH_EMULATOR_HOST="127.0.0.1:9099"
FIREBASE_SERVICE_ACCOUNT={insert secret JSON value here}

In the CI environment, the environment variables have to be defined separately. For example, FIREBASE_SERVICE_ACCOUNT will be passed in as a secret on GitHub Actions.