ramadhan sjamsani
a7a2a32d27
- Backend: Fastify with two listeners (public + internal), routes, services, DB migration + seed - client_app: Flutter with BLoC, all auth screens (welcome, display name, register, OTP, force-register) - mitra_app: Flutter with BLoC, OTP-only login - control_center: React + Vite, email/password login, mitra/user management, anonymity settings - Docs: phase1 plan, API contract, client app mockup - CLAUDE.md and shared memory for all subprojects Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
1.1 KiB
1.1 KiB
name, description, type
| name | description | type |
|---|---|---|
| Backend Context | Stack, two-listener architecture, route conventions, and auth flow for the Halo Bestie backend | project |
Fastify.js REST API — single process, two HTTP listeners.
Listeners:
- Public
0.0.0.0:3000→ servesclient_app+mitra_app - Internal
private-ip:3001→ servescontrol_centeronly (never expose publicly)
Route namespacing:
/api/client/— client app routes/api/mitra/— mitra app routes/api/shared/— shared routes (auth, lookup, etc.)/internal/— control center routes (internal listener only)
Auth flow:
- Firebase Auth issues JWT on mobile/web
- Client sends
Authorization: Bearer <token> - Fastify verifies via Firebase Admin SDK
- User fetched from PostgreSQL by Firebase UID
Stack: Fastify.js, PostgreSQL (GCP Cloud SQL), Firebase Admin SDK, Xendit, GCP Cloud Run
Conventions:
- Business logic in
services/— never directly in route handlers - All routes authenticated unless explicitly marked public
- Internal routes require additional
role: admincheck - Do not mix public and internal listener route registrations