# IPW Backend Server

This is the backend/server for the IPW system. The frontend is a separate system and is not included here.

## Prerequisites
- Node.js (v18+ recommended)
- npm (v9+ recommended)
- MySQL database

## Setup Instructions

1. **Clone the repository**
   ```sh
   git clone <repo-url>
   cd ipw_backend
   ```

2. **Install dependencies**
   ```sh
   npm install
   ```

3. **Configure environment variables**
   - Copy your environment file to the project root. The app loads `.env.<NODE_ENV>` (e.g., `.env.development`, `.env.staging`, `.env.production`).
   - Required variables (see `src/main.ts`):
     - `NODE_ENV` (e.g., development, staging, production)
     - `DOMAIN`
     - `ADAPTER_IP` (e.g., 0.0.0.0)
     - `PORT` (e.g., 3000)
     - `DATABASE_URL` (MySQL connection string)
     - `SESSION_SECRET`
     - `CSRF_SECRET`
     - `COOKIE_SECRET`
     - `JWT_ACCESS_TOKEN_SECRET`
     - `JWT_REFRESH_TOKEN_SECRET`
     - `HASHID_SALT`
     - `CLIENT_ORIGIN` (JSON array of allowed origins)
     - `SMTP_FROM`, `SMTP_HOST`, `SMTP_PORT`, `SMTP_USER`, `SMTP_PASS`
     - `UPLOAD_DIRECTORY`
     - `NUXT_API_LOCATION`, `NUXT_CLIENT_LOCATION`

4. **Set up the database**
   - Ensure your MySQL server is running and accessible.
   - Update `DATABASE_URL` in your environment file.
   - Pull the schema and generate the Prisma client:
     ```sh
     npm run prisma
     ```

5. **Build the project**
   ```sh
   npm run build
   ```

6. **Start the server**
   - For development:
     ```sh
     npm run start:dev
     ```
   - For production (using PM2):
     ```sh
     npm run start:production
     ```

## Notes
- The backend uses NestJS and Prisma ORM.
- Email templates must be copied to the `dist` directory after build (see nestcli.json for configuration).
- The server expects the frontend to be running separately.

## Useful Commands
- `npm run test` - Run tests
- `npm run lint` - Lint code
- `npm run format` - Format code

---

For more details, see comments in the code and configuration files.

# Changelog

## [Unreleased]
- Updated README with setup and running instructions for the backend/server, including environment variables, database setup, and server start commands. Clarified that this is the backend for the IPW system and the frontend is separate.

for email template copy to dist:


    // https://stackoverflow.com/a/68457373/2110294
    see addition to the nestcli.json file

# Deployment Automation System

## Overview
This project includes an automated deployment system that:
- Checks Supabase `public.code_deploy` for deployment triggers
- Stops the current server on port 9000
- Pulls the latest code from git
- Backs up the MySQL database to `/backup/timestamp.sql`
- Runs new SQL migrations from `/migration` (tracked in `public.migrations`)
- Installs dependencies with `npm install`
- Restarts the server and checks health
- Updates deployment status and errors in Supabase
- Self-heals if the server fails to start

## Directory Structure
- `/deploy/deploy.sh` — Main deployment script (run every 15 min)
- `/deploy/code_deploy_table.sql` — SQL to create `public.code_deploy`
- `/deploy/migrations_table.sql` — SQL to create `public.migrations`
- `/migration/` — Place migration SQL files here
- `/backup/` — Database backups stored here

## Setup
1. **Create Supabase Tables**
   - Run `/deploy/code_deploy_table.sql` and `/deploy/migrations_table.sql` in your Supabase SQL editor.
2. **Configure Environment**
   - Ensure `.env` exists in the project root with `DATABASE_URL` for MySQL.
3. **Configure Script**
   - Edit `/deploy/deploy.sh` and set `REPO_NAME`, `SUPABASE_URL`, and `SUPABASE_KEY`.
4. **Schedule Script**
   - Use cron or a process manager to run `/deploy/deploy.sh` every 15 minutes.

## Migration Process
- Place new SQL files in `/migration/`.
- The script will apply any not yet recorded in `public.migrations` for this `repo_name`.

## Migration Table
- The `public.migrations` table now includes a `repo_name` column, so migrations are tracked per repository.

## Status Tracking
- The script updates `status`, `processed`, and `error` fields in `public.code_deploy` for each step.

## Security
- Ensure Supabase API keys are secure.
- Use RLS on Supabase tables.
- No sensitive info is logged.

## Self-Healing
- If the server fails to start, the script will attempt to restart up to 3 times.

---
See `NewKnowledgeBase.md` for technical notes and learnings.