builtbykev/vyndr
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity

feat: Feature 1.2 (NBA stats FastAPI service) + Feature 1.4 (database schema)

Browse Source 
Feature 1.2: Python FastAPI microservice wrapping nba_api
- GET /stats/season-avg, /stats/last-n, /stats/splits, /players/search
- Redis caching (24hr/1hr/6hr/7day), 0.6s rate limiting, PRA derived stat
- 27 Python tests passing

Feature 1.4: Complete Supabase database schema
- 6 tables: users, picks, scan_sessions, bets, outcomes, performance
- RLS enabled on all tables with auth.uid() policies
- 3 triggers: auto-create user, updated_at, scan count reset
- 37 schema validation tests passing
- Migration SQL ready, pending manual apply (WSL2 DNS blocker)

Total: 92 tests (65 Node.js + 27 Python), all passing

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Kev
2026-03-21 10:58:58 -04:00
parent 00409fd6cd
commit 3da1b4242c
27 changed files with 2360 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files
DECISIONS.md
+18
View File
@@ -69,3 +69,21 @@ Outcome level (nested under market.outcomes[]):
- Decision: On-demand fetching only. Never poll. Cache aggressively at 15-min TTL. Batch all markets into one call per event. For a full NBA slate, one refresh = ~10 credits. At 15-min cache, even heavy usage stays under budget.
- Alternatives considered: Background polling every 15 min — rejected, would burn ~480 credits per game day.
- Consequences: First request after cache expires will be slower (live API call). Acceptable tradeoff for free tier.
### DECISION-003: Python Microservice for nba_api (Feature 1.2)
- Date: 2026-03-21
- Context: nba_api is a Python library. Backend is Node.js/Express. Need a bridge.
- Decision: FastAPI microservice. Node calls it via internal HTTP. Python stays idiomatic, caching strategy (24hr season averages, 1hr recent games) lives in the Python service with its own Redis connection.
- Alternatives considered:
- Python child process (Node spawns python3, parses stdout) — rejected: cold start on every call, awkward error handling.
- Pre-fetch cron (Python writes to Redis on schedule, Node reads) — rejected: more moving parts, stale data risk.
- Consequences: Two processes to run (Node + Python). Need a startup script or docker-compose. Internal port convention: Node on 3000, Python on 8000.
### DECISION-004: Supabase Auth + RLS (Feature 1.4)
- Date: 2026-03-21
- Context: Need auth provider for user system. Supabase already in stack.
- Decision: Supabase Auth. RLS enabled at project level. Our `users` table extends `auth.users` via FK on `id`. All tables use RLS policies scoped to `auth.uid()`.
- Alternatives considered:
- Clerk — better DX but adds a vendor, costs more at scale.
- Auth-agnostic (own users table, plug in later) — rejected: delays RLS setup, more migration work later.
- Consequences: All table access goes through RLS. Service role key bypasses RLS for admin/backend operations. Anon key used for client-side auth flows.