|
| 1 | +# CHAOS Backend |
| 2 | + |
| 3 | +CHAOS' backend is implemented in Rust and for data persistence, we use PostgreSQL. |
| 4 | + |
| 5 | +## Table of Contents |
| 6 | + |
| 7 | +- [Dev Setup](#dev-setup) |
| 8 | +- [Code Structure](#code-structure) |
| 9 | +- [Tech Stack](#tech-stack) |
| 10 | + |
| 11 | + |
| 12 | +## Dev Setup |
| 13 | + |
| 14 | +### Backend Development |
| 15 | +To run the backend in a dev/testing environment: |
| 16 | +0. Contact your director before you do the set up. |
| 17 | + |
| 18 | +1. Install `docker-compose` (see [official installation guide](https://docs.docker.com/compose/install/)). |
| 19 | + |
| 20 | +2. Navigate to the directory this file is in (`backend`) in your terminal (not `backend/server`). |
| 21 | + |
| 22 | +3. Possibly terminate any running instances of postgres, as the dockerized postgres we will spawn uses the same default port, so the two might interefere with each other. |
| 23 | + |
| 24 | +4. If you are using WSL/Linux, install the OpenSSL development package with `sudo apt install libssl-dev`. |
| 25 | + |
| 26 | +5. Run `./setup-dev-env.sh` (you might have to make it executable before with `chmod +x setup-dev-env.sh`), which should check if you have the correct docker setup and run the db-instance and do db setup and migrations. Then, it will also start your BE and FE container, so you could work on the project ASAP. |
| 27 | + |
| 28 | +6 (DB Seeding IMPORTANT). To set up your first data for development, please get in `./setup-admin-db-dev.sh` and change GMAIL to your personal gmail. What it does is basically setup your personal email as a SUPERUSER ROLE, giving you access to all pages (no restriction). |
| 29 | +After that, run `./setup-admin-db-dev.sh` (you might have to make it executable before with `chmod +x setup-admin-db-dev.sh`). |
| 30 | + |
| 31 | +7. To run the FE and BE, you can either run it locally or using the docker: |
| 32 | + - Local: |
| 33 | + at `backend/server`: do `cargo run build` to run the backend server. |
| 34 | + at `frontend-nextjs`: do `bun run dev` to run the frontend. |
| 35 | + - Docker: |
| 36 | + at the root `chaos/` folder, |
| 37 | + do `docker compose -f docker-compose.local.yml up -d frontend backend` |
| 38 | + do `docker compose -f docker-compose.local.yml up -d` to run all 3 (db, FE and BE) |
| 39 | + or |
| 40 | + If you want to run those seperately: |
| 41 | + do `docker compose -f docker-compose.local.yml up -d backend` |
| 42 | + do `docker compose -f docker-compose.local.yml up -d frontend` |
| 43 | + |
| 44 | +7 (Optional). If you want to clear the database, an empty database to restart maybe, run `./reset-db-dev.sh` (you might have to make it executable before with `chmod +x ./reset-db-dev.sh`). |
| 45 | + |
| 46 | + |
| 47 | +### Authentication |
| 48 | +Some routes are only accessible by Users/Admins/SuperAdmins. To login your browser with a respective User/Admin/SuperAdmin cookie, seed your database as above (step 6), and then call one of the following routes in your browser: |
| 49 | +- **Normal User:** `/api/v1/dev/user_login` |
| 50 | +- **Organisation Admin User:** `/api/v1/dev/org_admin_login` |
| 51 | +- **Super Admin User:** `/api/v1/dev/super_admin_login` |
| 52 | + |
| 53 | +## Code Structure |
| 54 | + |
| 55 | +### Handler |
| 56 | +The handler module takes care of request handling. It implements the framework or library we are using, invokes the |
| 57 | +service functions and responds via HTTP with their return values. |
| 58 | + |
| 59 | +### Middleware |
| 60 | +The middleware module contains middlewares, functions that run before or after the function handlers. A common use case |
| 61 | +is authorization, where middleware is used to find the userId from the user's token. |
| 62 | + |
| 63 | +### Models |
| 64 | +Models are Rust structs that represent the data. There must be a struct for each table in the database, as well as a |
| 65 | +struct to describe the fully joined data. E.g. A campaign struct with a array of questions, even though questions are |
| 66 | +stored as rows in a separate table. These models implement all functions that conduct business logic on the respective |
| 67 | +entity, and also interact with the database. This separation from request handling makes it easy to swap out any new |
| 68 | +form of requests, but reuse the same logic functions. |
| 69 | + |
| 70 | +### Service |
| 71 | +The service module contains all helper functions. For example, functions for determining a user's authorization to |
| 72 | +mutate an object are defined here. |
| 73 | + |
| 74 | +#### Request Path |
| 75 | +Request -> Middleware (optional) -> Handler -> Service -> Middleware (Optional) -> Response |
| 76 | + |
| 77 | + |
| 78 | +## Tech Stack |
| 79 | + |
| 80 | +### Web Server |
| 81 | +- [Axum](https://github.com/tokio-rs/axum) |
| 82 | + |
| 83 | +### Persistence |
| 84 | +- [SQLx](https://github.com/launchbadge/sqlx) - Queries and Migrations |
| 85 | +- PostgreSQL |
| 86 | + |
| 87 | +### AuthN |
| 88 | +- OAuth 2 (Google) |
| 89 | + |
| 90 | +### AuthZ |
| 91 | +- JWT |
| 92 | + |
| 93 | +### Storage |
| 94 | +- Object storage |
0 commit comments