40 lines
885 B
Markdown
40 lines
885 B
Markdown
|
# Platform Architecture
|
||
|
|
|
||
|
|
## Goal
|
||
|
|
|
||
|
|
One frontend product with two sections:
|
||
|
|
|
||
|
|
- `/trips`
|
||
|
|
- `/fitness`
|
||
|
|
|
||
|
|
Separate backend services remain in place:
|
||
|
|
|
||
|
|
- `services/trips`
|
||
|
|
- `services/fitness`
|
||
|
|
|
||
|
|
The legacy frontends stay runnable during migration for fallback and comparison.
|
||
|
|
|
||
|
|
## Service Boundaries
|
||
|
|
|
||
|
|
- Trips backend remains independent.
|
||
|
|
- Fitness backend remains independent.
|
||
|
|
- Trips and Fitness keep separate SQLite databases.
|
||
|
|
- Platform frontend owns the shared shell and explicit API proxy layer.
|
||
|
|
|
||
|
|
## Proxy Contract
|
||
|
|
|
||
|
|
- `/api/trips/*` -> Trips backend
|
||
|
|
- `/api/fitness/*` -> Fitness backend
|
||
|
|
|
||
|
|
Frontend code should call these proxy paths, not raw backend URLs.
|
||
|
|
|
||
|
|
## Migration Order
|
||
|
|
|
||
|
|
1. Keep both legacy frontends alive.
|
||
|
|
2. Build platform shell.
|
||
|
|
3. Add explicit proxy/API clients.
|
||
|
|
4. Migrate one product area first.
|
||
|
|
5. Migrate the second area.
|
||
|
|
6. Retire legacy frontends only after full coverage.
|
||
|
|
|