Skip to main content

The Frontend's Backend

The Next.js frontend never talks to Azure directly. It talks to this — a .NET 10 ASP.NET Core Web API that is the frontend's dedicated backend (a "backend-for-frontend"). Every camera list, every PTZ move, every login, every real-time update the operator sees passes through here, which is why understanding this API is really understanding how the whole frontend experience is wired.

The one idea to hold on to​

The Frontend API is a thin CQRS layer: controllers translate HTTP into MediatR commands and queries, handlers do the work against shared Infrastructure, and almost nothing happens in the controller itself. The same split you saw in the Admin API:

The frontend reaches it through its own server-side proxy, which injects the bearer token (the Authorization lesson is where that token comes from). So requests arrive already authenticated, and controllers focus on shape, not plumbing.

What flows through it​

The controllers group into a few jobs, and the rest of this section takes them in order of interest:

  • Camera movement & leasing — the one with real concurrency: granting exclusive PTZ control, arbitrating between operators, expiring it. This is the authoritative backend of the frontend's lease behavior.
  • Authorization — the CIAM OAuth login/callback that mints the tokens the proxy injects.
  • Real-time & engine callbacks — SignalR broadcasts to per-camera groups, and the API-key-gated endpoints the ImageAcquisition engine calls back into.
  • The query surface — cameras, images, video, alerts, notifications, activity log, filters, and shared views: the read-heavy majority, all CQRS queries.

Wrapping up​

The Frontend API is a .NET 10 CQRS backend-for-frontend: thin controllers, MediatR handlers, shared Infrastructure, reached through the Next.js proxy that injects the bearer token. It queues camera work to the engine and serves everything the operator sees. Start with the part that has genuine concurrency: Camera Movement & Leasing.