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>
63 lines
4.6 KiB
Markdown
63 lines
4.6 KiB
Markdown
# 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)
|
|
|
|
[Answer]: A
|
|
|
|
## 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)
|
|
|
|
[Answer]: A
|
|
|
|
## 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)
|
|
|
|
[Answer]: A
|
|
|
|
## 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)
|
|
|
|
[Answer]: B
|
|
|
|
## 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.
|