API

Welcome to the backend. The Naalya API is the server behind the schools platform — every login, student record, grade, and email goes through it. This section is how it's built and how to add to it without surprises.

It's a NestJS monorepo over a single PostgreSQL database. NestJS organizes TypeScript code into modules; the monorepo packs three apps plus a shared library into one repo so they share types and config. Postgres is the single source of truth — no second store to keep in sync.

Two things shape almost everything you touch:

• Multi-tenant — each school is a tenant; data is auto-scoped so one school never sees another's.
• CASL permissions — a rules engine that decides, per user, which actions they may take on which resources.

You don't have to master either on day one — just know they're always running in the background.

System shape

Three deployable apps, each with one job, plus libs/shared (imported everywhere as @app/shared) for common code.

apps/
  server/   — the HTTP API (Express 5) — what the frontend talks to
  worker/   — background job processor (no HTTP)
  audit/    — audit-log microservice (no HTTP)
libs/
  shared/   — code shared across all apps (@app/shared)

You'll live mostly in server — it runs guards, validation, and database access. worker and audit have no web server; they drain queued jobs (emails, audit records) so the API stays responsive. Full tour in Architecture.

Using this section

Read it in two passes:

• First day — walk the first three Cards below in order: get it running, learn the monorepo, learn how one feature module is shaped.
• After that — reference and recipes. Open The Database, Auth & Permissions, or Queues & Messaging when a task takes you there; reach for Add a Resource Module when building something new. Tickets about Rover, live screens, or Hub types that are not REST DTOs start with the architecture page — AI System, How realtime works, How Chowbea works — and the matching how-tos sit under Platform Guides.

Where to go next

The first four Cards are the first-day path. The last three are the systems you will hit once you are adding product behaviour.