develop #6
@@ -5,8 +5,10 @@ status: draft
|
||||
type: task
|
||||
priority: normal
|
||||
created_at: 2026-02-10T14:04:11Z
|
||||
updated_at: 2026-02-10T14:11:06Z
|
||||
updated_at: 2026-02-10T14:31:08Z
|
||||
parent: nuzlocke-tracker-rzu4
|
||||
blocking:
|
||||
- nuzlocke-tracker-spx3
|
||||
---
|
||||
|
||||
Build a Go tool that converts PokeDB.org's JSON data export into our existing seed JSON format. This replaces PokeAPI as the single source of truth for ALL games (Gen 1-9).
|
||||
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
# nuzlocke-tracker-spx3
|
||||
title: Evaluate separate seed/init container after PokeDB import
|
||||
status: draft
|
||||
type: task
|
||||
priority: low
|
||||
created_at: 2026-02-10T14:30:57Z
|
||||
updated_at: 2026-02-10T14:30:57Z
|
||||
---
|
||||
|
||||
After the PokeDB.org data import (beans-bs05) is complete, evaluate whether the seed data has grown enough to justify splitting seeding into a separate init container.
|
||||
|
||||
## Context
|
||||
|
||||
- Backend container is currently 76 MB; seed JSON data is ~5 MB
|
||||
- After PokeDB import, seed data may grow significantly (filling in Gen 8+, Let's Go, etc.)
|
||||
- The seed runner is tightly coupled to backend models/DB — a fully separate container isn't practical
|
||||
- The pragmatic pattern: same backend image, different entrypoint as a one-shot init service in Docker Compose
|
||||
|
||||
## Approach (if we proceed)
|
||||
|
||||
- Add a `seed` service to `docker-compose.prod.yml` using the same API image
|
||||
- Move `alembic upgrade head` + `python -m app.seeds` into the seed service command
|
||||
- Use `restart: "no"` and `service_completed_successfully` dependency
|
||||
- API service depends on seed completing before starting
|
||||
- API command becomes just `uvicorn ...` — no migrations or seeding
|
||||
|
||||
## Decision criteria
|
||||
|
||||
- Measure the final seed data size after PokeDB import
|
||||
- If seed data exceeds ~15-20% of image size, the split is worthwhile
|
||||
- Even below that threshold, the separation of concerns (migrations/seeds vs serving) may justify it
|
||||
|
||||
## Additional benefits
|
||||
|
||||
- Failure isolation: seed failure prevents API startup cleanly
|
||||
- Idempotency: seed runs once per deploy, API can restart freely
|
||||
- Cleaner API startup path
|
||||
Reference in New Issue
Block a user