2.4 KiB
2.4 KiB
Solution Strategy
Technology Decisions
| Decision | Choice | Rationale |
|---|---|---|
| Bot runtime | Node.js + TypeScript + discord.js | Strong ecosystem, typed Discord interactions, shared language across backend/dashboard |
| Persistence | PostgreSQL (pg) |
Reliable relational storage for mileage, schedules, and settings |
| Admin API | Express | Lightweight routing and middleware model for operational endpoints |
| Dashboard | React + Vite + TypeScript | Fast iteration and typed API integration |
| Authentication | Bearer token (admin API) + Discord OAuth2 | Secure machine-to-machine admin calls plus user identity bridge |
| Deployment | Coolify + Gitea Actions | Simple CI/CD path with webhook-triggered production rollout |
Architectural Strategy
System uses modular monolith strategy in single backend process:
- Bot core orchestrates Discord gateway and command/event handling.
- Domain services encapsulate call-sheet onboarding, tour queue, mileage, and dailies.
- Operational interfaces exposed through Admin API and OAuth bridge.
- Shared configuration layer centralizes environment parsing and validation.
- Separate dashboard SPA consumes API without direct DB access.
Quality Strategies
- Availability: graceful startup/shutdown, service initialization guards, process-level health endpoint.
- Consistency: transactional mileage writes, strict DB row guards, idempotent schedule updates.
- Security: token-based admin auth, OAuth code exchange on server side, no token logging.
- Extensibility: adapter interface for new dailies sources and isolated service modules.
- Operability: CI checks (lint/build/test) for bot and dashboard before deploy trigger.
Trade-offs
- In-memory OAuth sessions reduce complexity but require re-authentication after process restart.
- Modular monolith minimizes operational overhead now, while preserving service boundaries for future extraction.