likwid/WORKFLOW.md

Likwid Development Workflow

Understanding the Architecture

┌─────────────────────────────────────────────────────────────┐
│                     SHARED CODEBASE                         │
│  backend/src/*    frontend/src/*    migrations/*            │
└─────────────────────────────────────────────────────────────┘
                            │
            ┌───────────────┴───────────────┐
            ▼                               ▼
┌─────────────────────┐         ┌─────────────────────┐
│   PRODUCTION DB     │         │     DEMO DB         │
│   (likwid_prod)     │         │   (likwid_demo)     │
│                     │         │                     │
│ - No demo users     │         │ - Demo users seeded │
│ - No seed data      │         │ - Full sample data  │
│ - DEMO_MODE=false   │         │ - DEMO_MODE=true    │
│ - Real user data    │         │ - Resettable        │
└─────────────────────┘         └─────────────────────┘

Key insight: Code changes affect both. Data is separate.

Daily Development Workflow

Your local setup can behave like the demo

Your local environment is functionally equivalent to the demo deployment when DEMO_MODE=true and demo seed migrations have been applied (from backend/migrations_demo).

Making code changes

1. Edit code normally
2. Backend auto-reloads (or cargo run)
3. Frontend hot-reloads (npm run dev)
4. Test with demo accounts

Testing as different users

contributor / demo123  → Standard member experience
moderator / demo123    → Moderation features
observer / demo123     → Read-only experience

When You Want a Fresh Demo

Option 1: Reset database (quick)

# Drop and recreate database
cd backend
sqlx database drop -y
sqlx database create
sqlx migrate run

# If you want demo seed data, also run:
sqlx migrate run --source migrations_demo

Option 2: Use the reset script (when using containers)

.\scripts\demo-reset.ps1

Deploying for Others

For testers/curious users (Demo)

# Uses separate database on port 5433, backend on 3001, frontend on 4322
cp compose/.env.demo.example compose/.env.demo
podman-compose --env-file compose/.env.demo -f compose/demo.yml up -d

For real users (Production)

# 1. Configure production
cp compose/.env.production.example compose/.env.production
# Edit with secure passwords and your domain

# 2. Deploy
podman-compose --env-file compose/.env.production -f compose/production.yml up -d

Common Tasks

"I broke the demo data"

cd backend
sqlx database drop -y
sqlx database create
sqlx migrate run

"I want to test production-like (no demo data)"

# Set DEMO_MODE=false in .env

# Reset database (core migrations only)
cd backend
sqlx database drop -y
sqlx database create
sqlx migrate run

"I want demo data back"

# Set DEMO_MODE=true in .env

# Reset database + re-seed demo
cd backend
sqlx database drop -y
sqlx database create
sqlx migrate run
sqlx migrate run --source migrations_demo

"I want to run both demo and production locally"

Use the container deployments - they use different ports:

• Demo: localhost:4322 (frontend), localhost:3001 (backend)
• Prod: localhost:4321 (frontend), localhost:3000 (backend)

Summary

Concern	Solution
Code changes affect demo?	Yes, same codebase. That's expected.
Data separation	Different databases (demo vs prod)
Reset demo	sqlx database drop; sqlx database create; sqlx migrate run; sqlx migrate run --source migrations_demo
Test production locally	Set DEMO_MODE=false and run only core migrations (skip migrations_demo)
Deploy for others	Use compose files with separate DBs