Architecture
One deployable application with strong internal boundaries. Module ownership, pragmatic DDD, and why Ninaku is not a set of microservices.
Read the baseline
A modular monolith on NestJS and PostgreSQL. Every contract here is enforced by CI, and the API reference is generated from the running service — not written by hand.
| If you are | Start with | Then read |
|---|---|---|
| New to the codebase | Architecture | Domain map |
| Building or changing an endpoint | Foundation HTTP contract | API and schema discipline |
| Integrating against the API | API reference | Module contracts |
| Looking for a past decision | Decisions | Roadmap |
Application Foundation is in progress, tracked in issue #13. This site documents the target contracts and the code that is actually running — it does not claim the two are already the same thing.
Today the service exposes exactly two routes:
GET /health/live
GET /health/readyBoth stay unversioned and unprefixed on purpose, because Railway's healthcheck depends on that exact path. They are also deliberately outside the data envelope: a probe is infrastructure, not business API surface. Business routes will be served under /api/v1/… as they land.
docs/generated/openapi.json is produced by npm run openapi:generate from the running application and its Zod schemas, then verified byte for byte by npm run openapi:check. It is never edited by hand.