Phase 1: chunk store, tile rendering pipeline, and Leaflet viewer
api: WS gateway with token auth (Postgres-backed servers table, seeded via `bun run seed`), column-granularity chunk store (hand-written SQL migrations, no drizzle-kit CLI — its config loader needs esbuild, which doesn't install cleanly here), dirty-chunk Redis stream producer with per-flush dedup, and a tile-serving route. worker: consumes the dirty-chunk stream via a proper consumer group, rasterizes each chunk's columns into a single-resolution top-down PNG (static pre-Flattening block-id palette), uploads to MinIO, and upserts the tile pointer. frontend: barebones Leaflet 2D viewer (CRS.Simple, one native zoom level) wired to /api/servers and /api/tiles. Object storage: tiles live in a dedicated `mcmapper-tiles` bucket on the existing shared MinIO instance (devstack-minio on octo-winsrv) instead of a per-stack container, via a scoped access key limited to that one bucket — see README's "Object storage" section. MINIO_SECRET_KEY is real and is deliberately not committed; docker-compose layers an untracked .env over .env.example for it. Full pipeline verified end-to-end against live containers: WS auth -> Postgres upsert -> deduped Redis dirty-chunk event -> worker rasterize -> MinIO upload -> tile fetch through the api route, including from the actual mod-side WS client (see MCMapper-Mod's matching commit).
This commit is contained in:
+8
-3
@@ -1,8 +1,13 @@
|
||||
DATABASE_URL=postgres://mcmapper:mcmapper@postgres:5432/mcmapper
|
||||
REDIS_URL=redis://redis:6379
|
||||
MINIO_ENDPOINT=minio
|
||||
MINIO_PORT=9000
|
||||
|
||||
# See api/.env.example for what this points at and why — same shared MinIO instance/bucket,
|
||||
# same rule: MINIO_SECRET_KEY is real, set it in an untracked `.env` next to this file, never here.
|
||||
MINIO_ENDPOINT=192.168.0.3
|
||||
MINIO_PORT=28205
|
||||
MINIO_USE_SSL=false
|
||||
MINIO_ACCESS_KEY=mcmapper
|
||||
MINIO_SECRET_KEY=mcmapper-dev-only
|
||||
MINIO_SECRET_KEY=changeme-set-in-untracked-env
|
||||
|
||||
# cpu | gpu | hybrid — see render::backend. Only `cpu` exists so far (Phase 8 adds gpu/hybrid).
|
||||
RENDER_BACKEND=cpu
|
||||
|
||||
Reference in New Issue
Block a user