API Design in Node.js with TypeScript

What your seat includes

Taught live in a small group, remote over video, inside EkoFlow, our open source development environment.

• Twelve evenings over four weeks, three evenings a week, live in a small group over video
• One booking API, designed and shipped by you in Fastify and TypeScript: slots, conflicts, cancellation windows and the awkward parts nobody writes about
• Every line written test first, with no mock anywhere: the database, the clock and the outside world become Nullables you can command
• Islands of Node theory when the code needs them: the event loop, the module system, streams
• Your code reviewed by a person between sessions, the way a strong team reviews
• An architecture test that keeps the design honest after you stop looking
• The Solo plan on this platform, yours forever

The path

Each stage is built around doing the work, with a facilitator who asks rather than lectures. Read about how we teach

1. 1

   Week 1, Shape: what an API says before it does anything

   Resources rather than verbs, and the representation on the wire: what a booking is, in JSON, with times that carry their zone. Status codes that mean something, 201 with a Location, and validation at the edge with typed schemas. The first endpoint driven test first against the real Fastify application, and the first theory island: what the event loop actually does, and why Node answers many clients with one thread.

2. 2

   Week 2, Seams: the database, the clock and the outside world

   A cancellation window is a rule about time, so time becomes something you command rather than wait for. Build Nullable infrastructure in Shore's sense: create_null with configurable responses and output tracking, for the store, the clock and the notifier. Your tests run in milliseconds against your own code, not against a mock of it. Island: the module system, and where a seam wants to live in it.

3. 3

   Week 3, The hard parts: conflicts, repeats and errors

   Two people booking the last slot, and the same request arriving twice: conflict and idempotency, the two problems every real API meets and most tutorials skip. Errors as a contract rather than a stack trace, in the problem details shape. Authorisation that answers who may read whose booking, and the design decision hidden inside a 404.

4. 4

   Week 4, Keeping it honest: architecture, evolution and shipping

   An architecture test that forbids a route from touching the database, so the layering survives the next hurried change. Narrow integration tests against a real Postgres, pagination and filtering, and adding a field without breaking a client. Island: streams and backpressure, for the day a response stops fitting in memory. Then you ship it, and read your own API back as a stranger would.