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 current setup IS the demo

Your local environment with DEMO_MODE=true and the seeded database is functionally equivalent to the demo deployment.

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

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. Remove demo seed data
rm backend/migrations/20260127150000_demo_seed_data.sql

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

# 3. 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)"

# Temporarily move the demo migration
mv backend/migrations/20260127150000_demo_seed_data.sql backend/migrations/20260127150000_demo_seed_data.sql.bak

# Reset database
sqlx database drop -y && sqlx database create && sqlx migrate run

# Set DEMO_MODE=false in .env

"I want demo data back"

# Restore migration
mv backend/migrations/20260127150000_demo_seed_data.sql.bak backend/migrations/20260127150000_demo_seed_data.sql

# Reset database
sqlx database drop -y && sqlx database create && sqlx migrate run

# Set DEMO_MODE=true in .env

"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 && create && migrate
Test production locally	Remove demo migration, set DEMO_MODE=false
Deploy for others	Use compose files with separate DBs