Backend Services

This module builds the whole SKYWATCH backend the same way the original course does: a Fastify API server with a route → repo layering pattern, a background poller pulling live aircraft data from adsb.lol, an edge-triggered detection engine watching for emergency squawks and overflights, and a real-time layer pushing all of it to connected browsers over WebSocket. The difference is that you’re not the one typing most of it. You’re prompting an AI coding assistant through each piece, reading what it hands back, and deciding whether it actually holds up before it becomes part of your server.

Why This Matters

This is the module where “the code runs” and “the code is right” stop meaning the same thing. A Fastify server that starts up and answers /health tells you almost nothing about whether the route handlers actually respect the repo layer underneath them. A poller that logs aircraft counts every fifteen seconds tells you nothing about whether it’s silently racing itself when adsb.lol is slow to respond. A detection engine that produces alerts tells you nothing about whether it produces one alert per incident or twenty. And a WebSocket endpoint that streams positions can look completely healthy while its LISTEN connection is quietly dead, because a pooled connection swallowed the subscription with no error thrown anywhere. None of these failures show up in a terminal that says “server listening on port 4000.” They show up later, under real load, in the specific place you didn’t think to check. This module is about knowing where those places are before you ship an AI assistant’s backend.

What You’ll Learn

• Directing an AI assistant to stand up a Fastify server with env config, CORS, a health check, and graceful shutdown, then reviewing the route → repo layering pattern it builds on top of that shell
• Prompting the first full CRUD resource, watch regions, and catching whether the AI actually wrapped the “clear old default, set new default” write in a transaction instead of two separate statements that can drift apart
• Directing the adsb.lol poller and verifying it has a real re-entrancy guard, not just a setInterval that trusts every cycle to finish in time
• Reviewing an AI’s detection logic for the difference between “fires on state transition” and “fires every poll cycle,” and why that difference is invisible until an aircraft squawks an emergency code for ten minutes straight
• Directing the two-pub/sub-mechanism realtime layer, and catching the one connection-pooling mistake that makes LISTEN/NOTIFY fail silently instead of loudly

Outcome

By the end of this module, you’ll have the same backend as the original course: a Fastify server, a fully working watch-regions CRUD resource, a poller with detection running standalone against Postgres, and a WebSocket endpoint pushing positions and alerts to any connected browser in real time. The difference is that you’ll have built it by directing an AI assistant and checking its work at every step most likely to hide a real bug, not by hoping a green terminal meant it was all correct.

Let’s get started.