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

2.6 KiB

Services — Local Dev Master/Slave Setup

No new domain services

This feature introduces no new business/domain service. All existing services are reused unchanged:

  • Master-side (only present in SlpModularCms.Api, because only it references Modules.Master): CmsInstanceService, SlaveApiClient, ApiKeyProtector — manage registered CMS instances and communicate with them.
  • Slave-side (present in both SlpModularCms.Api and SlpModularCms.Api.Slave, since both reference Modules.Availability): MasterAvailabilityService, MasterApiKeyProtector — accept and validate a master's per-instance API key.
  • Shared cross-cutting: IAuthService, IInvitationService, ISetupService (from Core.Identity via AddCoreInfrastructure) — identical in both hosts.

Orchestration Service

ModuleOrchestrator (relocated to SlpModularCms.Core.Hosting, see components.md) is the only "orchestration" element in this feature, and its role is unchanged: at startup, discover whichever module DLLs are present next to the host executable and wire them into DI + the request pipeline. Its behavior naturally differs between the two hosts only because of what's present in each host's build output — not because of any new conditional logic.

Interaction Sequence — Local Master/Slave Connection Test

sequenceDiagram
    box rgba(246,224,94,0.4) Developer
      participant Dev as Developer
    end
    box rgba(99,179,237,0.4) Master Instance (5284/7221)
      participant MasterApi as SlpModularCms.Api
      participant CmsInstanceSvc as CmsInstanceService
    end
    box rgba(154,230,180,0.4) Slave Instance (5285/7222)
      participant SlaveApi as SlpModularCms.Api.Slave
      participant MasterCtrl as MasterController
    end

    Dev->>MasterApi: dotnet run --launch-profile master
    Dev->>SlaveApi: dotnet run --launch-profile slave
    Dev->>MasterApi: Open frontend, use Add CMS Instance dialog with slave URL
    MasterApi->>CmsInstanceSvc: Register CMS instance (slave URL + generated API key)
    CmsInstanceSvc->>MasterCtrl: Push registration / poll status using API key
    MasterCtrl-->>CmsInstanceSvc: Accepted, status healthy
    CmsInstanceSvc-->>MasterApi: Instance connected
    MasterApi-->>Dev: CMS Instance shows as Connected

Text alternative: The developer starts the master and slave backends on their respective ports, then uses the master frontend's existing Add CMS Instance dialog. The master's CmsInstanceService registers and communicates with the slave's MasterController using a per-instance API key, and the frontend reflects the resulting connected status.