This repository contains documentation about the recruitment application project.
The purpose of the project is to develop a secure, robust and scalable recruitment application for an amusement park. The application should be well-architected and documented so that further maintenance by a different team is possible.
The recruitment application allows users to create an account for registering job applications. It allows selecting an area of expertise, years of experience and availability period. For recruiters, it presents an overview of applications that have been submitted. Applications are pending by default and recruiters can choose to either accept or reject them.
The project implements the frontend using a client-side rendering architecture and backend using a REST API. This makes it easy to swap out the frontend (for example, with a mobile app) without modifying the backend.
The REST APIs are documented in api.md. All APIs follow some common rules but information that is specific to each API (such as the path and parameters) is documented in the apis directory.
The frontend browser application is hosted at IV1201-Group-2/client. The repository also contains a Spring Boot server for serving static files.
The backend is implemented as a set of microservices that follow the API specifications. Internally, they're implemented using different languages and frameworks, but they all follow the API rules to provide a consistent experience to frontend developers.
-
Register Service - Microservice for registering users
-
Login Service - Microservice for authenticating users and generating JWT tokens
-
Personal Information Service - Microservice that allows applicants and recruiters to retrieve applicant's personal information
-
Application Form Service - Microservice that is used for generating and submitting application forms
-
Recruiter Service - Microservice that is used by recruiters to retrieve job applications and applicant's personal information
-
Application Status Service - Microservice that handles backend application status updates and validation process
The repository IV1201-Group-2/database contains SQL files for setting up a database compatible with the application.
Every microservice has slightly different instructions and environment variables for deployment, but these are some general instructions for getting the application set up in Heroku.
These applications need to be created on your Heroku account:
- application-form-service
- application-status-service
- client-service
- login-service
- personal-info-service
- recruiter-service
- register-service
To create them from the command line, run heroku create {name} in the repositores for the client and backend microservices. If you already have the applications set up, you can use heroku git:remote -a ${name} to associate the repository with a Heroku application.
Use git push heroku main to push the main branch to Heroku. Every microservice has either a Procfile or Dockerfile so no manual setup locally is necessary. Heroku will build the services on their servers.
Follow the instructions at https://devcenter.heroku.com/articles/heroku-postgresql to set up a Postgres database in Heroku. It will be associated with one microsevice, so you can share it with the other services by using heroku addons:attach.
Heroku should automatically set up the DATABASE_URL environment variable. If you have problems with services using too many connections, you can use the DATABASE_MAX_CONNECTIONS variable to limit the connections that a single microservice is allowed to make.
After the database is set up, use the SQL schema in the database repository to set up empty tables for the application.
The JWT secret is a secret key shared between every microservice to authenticate users without requiring communication with the database or other services. The JWT secret can be any string but to be secure it should be a long and random string that is hard to guess.
You can use the command openssl rand -hex 32 to generate a random 256-bit string. Set the JWT_SECRET variable in every microservice to the resulting string.
Heroku will assign a random URL to every service, so the URLs need to be manually configured in frontend applications. Follow the instructions in the client README once the backend has been set up.