Microservices gateway linking mechanism

[mathieusouflis]

Problem statement

When dot add service <name> runs, the new service must be registered in the gateway. We need to decide how this registration works before building the gateway generator and the dot add service command.

Proposed solution

Option A — Static config patch (recommended)
The gateway config file (nginx.conf / Kong declarative YAML / Traefik routes.yml) is patched by dot add service using a new anchor (e.g. AnchorGatewayRoutes). The route for the new service is appended to the upstream/route list.

Pros: Consistent with dot's existing Patch model. No extra infrastructure. The gateway config is readable and reviewable in git.
Cons: Requires adding a new anchor type per gateway (nginx, Kong, Traefik). The patch logic must handle each config format.

Option B — Env-driven
The gateway reads service URLs from environment variables. dot generates .env.example with the service URL variables. No gateway config patching needed.

Pros: Simple. No complex patch logic.
Cons: Not automatic — the developer must wire env vars manually. Doesn't fulfill "automatically linked" promise.

Option C — Service discovery
Gateway uses Consul or etcd. Services self-register at startup.

Pros: Fully dynamic. Production-grade.
Cons: Adds heavy infrastructure. Out of scope for a scaffolding tool.

Alternatives considered

Option C is out of scope for v0.2. Option B is a fallback if Option A proves too complex per gateway type.

Area

Core

Additional context

Depends on: Microservices init flow decision.
Blocks: Microservices gateway generator.
See docs/developer-guide/roadmap/open-decisions.md #6.