SluijsensandClaude Sonnet 5
274946dbff
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>
4.6 KiB
Requirements Clarification Questions — Local Dev Master/Slave Setup
Context found while investigating the codebase: SlpModularCms.Api discovers modules by scanning its own build output folder for SlpModularCms.Modules.*.dll (ModuleOrchestrator.DiscoverModules) and loads every module DLL it finds — there is currently no config-driven way to load the API without SlpModularCms.Modules.Master. To run a "slave-only" instance locally, ModuleOrchestrator needs a small change: skip registering/activating a module if it's named in a new config setting (e.g. Modules:Disabled), so the same build output can serve both an instance with the Master module active and one without.
Please answer each question below by filling in your choice after the [Answer]: tag.
Question 1
How should the "master" vs "slave" instance be toggled?
A) Config-driven module disable list read from appsettings/appsettings.local.json (e.g. "Modules": { "Disabled": ["Master"] }), checked by ModuleOrchestrator before registering/activating a module. One shared build; two different config files/launch profiles select the mode.
B) Separate ASP.NET Core launch profiles only, no code change — accepting that both profiles will always load the Master module since it's a project reference (this would NOT actually give you a Master-less slave).
C) A separate host project (SlpModularCms.Api.Slave) with its own .csproj that simply omits the SlpModularCms.Modules.Master project reference.
X) Other (please describe after Answer: tag below)
Answer: X, For testing purposes a separate project will suffice, but when building the production builds later I want to be able to build the base version of the API and add the modules as DLL-files. Can we make that happen here as well?
Question 2
Should the master and slave instance use separate local databases (so slave-side data like registrations/users doesn't collide with master-side data)?
A) Yes — separate connection strings/database names (e.g. SlpModularCmsLocal_Master and SlpModularCmsLocal_Slave), same SQL Server instance, via appsettings.local.json per profile.
B) No — both instances share the exact same local database.
C) Use SQLite per instance instead of SQL Server, to make the setup fully self-contained without a shared SQL Server.
X) Other (please describe after Answer: tag below)
Question 3
Which ports should the two instances use?
A) Master keeps the existing ports (http://localhost:5284, https://localhost:7221); slave gets a new pair (http://localhost:5285, https://localhost:7222).
B) Let me specify custom ports (describe after Answer: tag below).
X) Other (please describe after Answer: tag below)
Question 4
How do you want to start both instances locally?
A) Two named dotnet run --launch-profile <name> invocations (one per terminal) — profiles added to the existing SlpModularCms.Api/Properties/launchSettings.json.
B) A helper script (e.g. PowerShell) that launches both in the background with one command.
C) Both A and B — launch profiles for IDE debugging (e.g. Rider/VS "Multiple startup projects" or dotnet run), plus a convenience script for quick CLI use.
X) Other (please describe after Answer: tag below)
Question 5
Should the frontend (React app) also be runnable against the slave instance, or is the slave purely a backend API target (no need to browse it via the CMS frontend)?
A) Backend-only — slave just needs to be reachable over HTTP for the master-to-slave connection (registration + polling/push); Scalar/OpenAPI at the slave's own URL is enough to poke it manually if needed.
B) The frontend should also be runnable against the slave (e.g. via a .env.slave or a second Vite dev server config), so its admin UI is separately reachable too.
X) Other (please describe after Answer: tag below)
Question 6
Once both instances are running, do you want a documented/scripted way to actually register the slave under the master (so the "connection" is set up end-to-end), or is wiring that up manually through the existing "Add CMS Instance" UI flow sufficient?
A) Manual is fine — document the steps (start both, open master frontend, use the existing Add CMS Instance dialog with the slave's local URL) in a short README/runbook. B) Provide a scripted/seeded way (e.g. a dev-only endpoint or seed data) to pre-register the slave automatically on startup, skipping the manual UI step. X) Other (please describe after Answer: tag below)
Answer: A, because I want to test the functionality of the "Add CMS Instance" UI flow.