HSK WEBKDAccess-control modernization with a safer domain core

WebKD sits in the operational layer of a facility. Operators work with RCP servers, TKD controllers and readers, PKD cardholders, KAD access cards, schedules, sequences, events, attendance reports, announcements, wanted-person workflows, DOD views, and remote-work modules.

Modernization therefore starts with the domain map, not a UI skin. The system has to preserve how access decisions are made, how permissions are recalculated, how readers receive updates, and how operators diagnose events when something does not behave as expected.

CloudFloo treats the project as enterprise software: many modules, legacy constraints, real physical devices, protected operational data, and release paths that need rollback and migration discipline.

The NestJS backend is organized around explicit WebKD modules: RCP, TKD, PKD, KAD, Uprawnienia, Zdarzenia, Harmonogram, Sekwencja, Grupa, GLC, Kontrola, Komunikat, reports, access control, license checks, monitoring, job status, queues, and administration.

Access control is modeled as both functionality permissions and data permissions. That matters because an operator may be allowed to use a feature but still be limited to specific groups, cardholders, readers, or organizational scopes.

OpenAPI specs, controllers, DTOs, frontend API clients, and domain documentation give the team a shared contract. The goal is to let critical behavior change through deliberate slices rather than hidden coupling.

The runtime is more than one web process. React frontends and API ingress talk to NestJS backend pods; the backend uses TypeORM/Postgres, Redis query cache, Bull queues, Socket.IO Redis adapter, logging, throttling, guards, interceptors, and health endpoints.

RCP communication can run in the backend path or through a dedicated rcp-worker path behind a feature flag. That gives the modernization work a practical route to separate device communication from the API surface without forcing a risky big-bang rewrite.

Local development uses Docker, Kubernetes manifests, Skaffold, mock/API-site images, Postgres, Redis, and E2E fixtures so engineers can work against something closer to the real operational topology.

The delivery path is built around Nx affected builds, GitHub Actions, container images, Helm, and environment-specific values. Staging and production flows can build only what changed, run tests, publish images, and deploy through the chart.

Database migrations are treated as rollout gates. The Helm chart runs a migration Job, backend pods wait in an init container until the migration succeeds, and robust deployment scripts clean stuck migration jobs before retrying. That is the kind of operational detail that prevents a broken schema rollout from becoming a silent production failure.

A system like WebKD accumulates risk when knowledge lives only in people, old assumptions, or scattered code paths. The modernization work turns that knowledge into modules, contracts, tests, deployment gates, and diagrams that a team can reason about.

The practical value is not a vanity rewrite. It is fewer unknowns before each change, safer permission behavior, more reproducible environments, clearer release ownership, and a better path for future modules such as DOD, remote work, reporting, monitoring, and RCP microservice separation.