How shcoide/arl-trays-api works
ARL Trays API tracks trays and batches from seeding through growth stages to harvest. The main workflow is an HTTP client request entering Fastify, passing route validation, invoking a domain service, and reading or writing PostgreSQL; batch progression is enforced one step at a time, with harvest as a transactional final operation. The README documents filtering, concurrency protections, and error behavior. Some wiring is based on the README because the full database schema and tray service implementation were not sampled.
Main entry points: app.ts Fastify app · trays.ts Tray routes · routes/batches.ts Batch routes · services/batches.ts Batch service
Components 13
HTTP API
- API server
src/index.ts - Fastify app
src/app.ts - Request schemas
src/schemas.ts - HTTP errors
src/errors.ts
Tray Management
- Tray routes
src/routes/trays.ts - Tray service
src/services/trays.ts
Batch Lifecycle
- Batch routes
src/routes/batches.ts - Batch service
src/services/batches.ts - Stage ordering
src/stages.ts
Persistence
- Postgres pool
src/db.ts - PostgreSQL
- Data schema
db/schema.sql
Other components
- HTTP client
Connections 14
- HTTP client → API server: sends requests
- API server → Fastify app: builds and listens
- Fastify app → Tray routes: registers routes
- Fastify app → Batch routes: registers routes
- Tray routes → Request schemas: validates input
- Batch routes → Request schemas: validates input
- Tray routes → Tray service: dispatches
- Batch routes → Batch service: dispatches
- Batch service → Stage ordering: computes next stage
- Tray service → Postgres pool: queries
- Batch service → Postgres pool: queries
- Postgres pool → PostgreSQL: connects
- Data schema → PostgreSQL: defines tables and constraints
- Fastify app → HTTP errors: maps HTTP errors