CLN-08 + INT-01: Documents the rationale for multi-language architecture and the decision to rewrite chat server from Rust to Go in v0.501.
2.2 KiB
2.2 KiB
ADR-001: Go + Rust + React Architecture (Rust Services)
Reference: CLN-08
Date: 2026-02-22
Status: Accepted
Context
Veza is a music collaboration platform with a polyglot architecture:
- Go: Backend API (REST, business logic, authentication)
- Rust: Chat server and stream server (real-time, audio processing)
- React: Frontend application
The platform requires different capabilities across services: high-throughput REST APIs, real-time WebSocket communication, and performance-critical audio transcoding. Each language was chosen for its strengths in specific domains.
Decision
The Go + Rust + React architecture is adopted with clear boundaries:
When to Use Rust
- Audio transcoding: FFmpeg integration, format conversion, streaming pipelines
- Real-time stream processing: Low-latency audio/video handling
- Performance-critical paths: Where predictable latency and memory safety matter
When to Use Go
- REST API: HTTP endpoints, request handling, routing
- CRUD operations: Database access, business logic
- Authentication: Session management, token validation, authorization
- General backend services: Where developer productivity and ecosystem matter more than raw performance
When to Use React
- Frontend: User interface, state management, client-side interactions
Consequences
Positive
- Each service uses the most appropriate language for its domain
- Rust provides safety and performance for stream server (FFmpeg, transcoding)
- Go enables rapid development for API and business logic
- React ecosystem supports rich frontend development
Negative
- Operational complexity: Three languages increase deployment, monitoring, and debugging overhead
- Harder onboarding: New developers must learn multiple stacks
- Maintenance cost: Tooling, dependencies, and expertise required for each language
Future Direction
The chat server will be rewritten in Go in v0.501. Rust adds complexity for chat without proportional benefit; Go's goroutines and channels are well-suited for WebSocket handling, and the team is already proficient in Go. See ADR-002 for details.