likwid/WORKFLOW.md
Marco Allegretti 910a6465f2 Initial commit: Likwid governance platform
- Backend: Rust/Axum with PostgreSQL, plugin architecture
- Frontend: Astro with polished UI
- Voting methods: Approval, Ranked Choice, Schulze, STAR, Quadratic
- Features: Liquid delegation, transparent moderation, structured deliberation
- Documentation: User and admin guides in /docs
- Deployment: Docker/Podman compose files for production and demo
- Demo: Seeded data with 3 communities, 13 users, 7 proposals

License: AGPLv3
2026-01-27 17:21:58 +01:00

125 lines
4.3 KiB
Markdown

# 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)
```powershell
# 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)
```powershell
.\scripts\demo-reset.ps1
```
## Deploying for Others
### For testers/curious users (Demo)
```bash
# 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)
```bash
# 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"
```powershell
cd backend
sqlx database drop -y && sqlx database create && sqlx migrate run
```
### "I want to test production-like (no demo data)"
```powershell
# 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"
```powershell
# 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 |