Files
SluijsensandClaude Sonnet 5 274946dbff Adds SlpModularCms.Api.Slave for local master/slave dev testing (Unit 1)
Relocates ModuleOrchestrator, ServiceCollectionExtensions, and
ApiPrefixConvention from SlpModularCms.Api into SlpModularCms.Core.Hosting
so a new Master-less SlpModularCms.Api.Slave host project (ports 5285/7222)
can share the same bootstrap code without duplicating it. This lets a
developer run a master instance and a slave instance side by side locally
to test the master/slave connection, without touching the existing
master/slave protocol itself.

Relocates the two orchestrator/convention test files from
Modules.Identity.Tests to Core.Tests, dropping an incidental
ProjectReference to SlpModularCms.Api that existed only for those tests.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-04 02:07:35 +02:00

3.4 KiB

Unit of Work — Local Dev Master/Slave Setup

Unit 1 — Backend Dual-Instance Hosting

Responsibility: Make it possible to run a Master-less slave backend locally alongside the existing master backend, on separate ports and databases, without duplicating bootstrap code.

Scope:

  • Relocate ModuleOrchestrator, ServiceCollectionExtensions, ApiPrefixConvention from SlpModularCms.Api into SlpModularCms.Core (new SlpModularCms.Core.Hosting namespace); add Asp.Versioning.Mvc and Microsoft.AspNetCore.OpenApi package references to Core.
  • Update SlpModularCms.Api/Program.cs to use the relocated classes (no behavior change); delete the old files from SlpModularCms.Api.
  • Add new SlpModularCms.Api.Slave project: references Core, Modules.Availability, Modules.Identity (no Modules.Master); own Program.cs mirroring SlpModularCms.Api's bootstrap.
  • Add SlpModularCms.Api.Slave's appsettings.json / appsettings.Development.json / appsettings.local.json (gitignored) with its own ConnectionStrings:DefaultConnection (separate database) and Cors:AllowedOrigins.
  • Add SlpModularCms.Api.Slave/Properties/launchSettings.json with profiles on port 5285 (HTTP) / 7222 (HTTPS).
  • Add SlpModularCms.Api.Slave.csproj to the solution file.
  • No dedicated test project (Q3 = A) — mirrors SlpModularCms.Api's current pattern.

Depends On: Application Design decisions (already approved).

Completion Criteria: Both SlpModularCms.Api (master) and SlpModularCms.Api.Slave build and start successfully via dotnet run --launch-profile <name>; existing test suites (Modules.Master.Tests, Modules.Availability.Tests, Modules.Identity.Tests, Core.Tests) still pass unchanged; the slave instance's Scalar/OpenAPI page loads and shows no Master-related endpoints.

Unit 2 — Frontend Dual-Instance Tooling & Runbook

Responsibility: Let the existing frontend point at either the master or slave backend, and document the manual workflow for connecting them.

Scope:

  • Add .env.slave.local (gitignored, mirrors .env.local) with VITE_API_BASE_URL=https://localhost:7222.
  • Update .env.example to document both .env.local (master) and .env.slave.local (slave) modes.
  • Add an npm script dev:slave (e.g. vite --mode slave --port 5174) to frontend/package.json; introduce a .env.slave (non-local, checked-in) mode file if needed for Vite's mode-based env loading, or rely on --mode slave reading .env.slave.local.
  • Add a runbook section (in frontend/README.md and/or a new docs/local-master-slave-setup.md referenced from the root README) with step-by-step instructions: start master backend, start slave backend, start master frontend, (optionally) start slave frontend, use the existing "Add CMS Instance" dialog to register the local slave, confirm connected status.

Depends On: Unit 1 must be complete and verified working (Q2 = A) — the runbook's steps assume a working slave backend to point at and to actually exercise end-to-end.

Completion Criteria: Frontend can be started against either instance via the documented commands; the runbook has been manually followed once to confirm the "Add CMS Instance" flow successfully connects the local master to the local slave.

Sequencing

Unit 1 → Unit 2 (strictly sequential; Unit 2's runbook and manual verification require Unit 1's working slave backend).