RQ6 — How do DI, IoC and Singleton behave across RSC, client bundles and NestJS?

Question (BRIEF.md RQ6, G6.3): how do Dependency Injection, Inversion of Control and the Singleton pattern behave across React Server Component requests, client bundles and the NestJS container? Evidence: per-request vs per-process scope.

Answer: "singleton" means a different lifetime in each runtime. A module-level value on the Next.js server lives for the whole process and is shared by every user. Request data must use React cache() (one value per request). In the browser, a module value lives per tab, and React context lives per tree. NestJS DEFAULT scope is per process, REQUEST scope is per HTTP request. Decisions: ADR 0006, 0007, 0008.

Scope table

Findings

1. RSC module singletons leak. Next.js renders many requests in one Node process. A let currentOrg at module level is written by request A and read by request B. This is the forbidden case of ADR 0008.
2. cache() is the server request scope. cache(() => createServerContainer()) returns the same container for every component of one request, and a new one for the next request. It needs no provider and works in any Server Component, layout or Route Handler.
3. Client scope = React context. The client container is built once per provider mount from serialisable inputs (org slug, locale, settings promise). Two trees (site, portal) get two containers. No window global.
4. IoC without a framework. Components ask for a service by typed key (container.get('entities')) or by hook (useService('entities')). They never import a concrete client or call new. This is the whole IoC gain; decorators and reflect-metadata add nothing in RSC.
5. NestJS: keep services in DEFAULT scope and stateless. Resolve tenant + user once per request in a guard into a CLS/request context (@OrgId() decorator reads it). Use Scope.REQUEST only where a provider must hold request state and CLS is not enough — REQUEST scope bubbles to every dependent and costs one instance per request.
6. Per-process is fine for pure things. Frozen config, the logger factory, the brand token map and pure functions may be module-level (ADR 0008 allow list).

Prototype shape (to build in task 022+, not code here)

• Server: src/lib/di/server-container.ts starts with import 'server-only', exports getServerContainer = cache(() => buildContainer({ side: 'server', ... })).
• Client: src/lib/di/client-container.tsx ('use client') — ServiceProvider builds the container in useState(() => buildContainer({ side: 'client', ... })); useService(key).
• Proof test (when an AC names it): render two requests with two orgs; the container of request 2 must not see the org of request 1.

Sources

• React cache — https://react.dev/reference/react/cache (per server request memoisation).
• NestJS injection scopes — https://docs.nestjs.com/fundamentals/injection-scopes.
• ddx-server-client-boundary skill (import 'server-only', module-scope mutable state rule).
• ddx-nextjs-frontend-layout D3/D6 (cascade, entity-client singletons in the browser).

Note 2026-10-23: ServiceProvider above is now ClientContainerProvider (ddx-web/src/lib/di/client-container.tsx:22).

• ddx-documentation — dudoxx-web-boot

adr/

• ADR 0001 — Scaffold route: dudoxx-sandbox-creator with 163XX overrides
• ADR 0002 — Auth: better-auth 1.7 in ddx-api
• ADR 0003 — Route shape: org slug, role, [entity]/[id], ?view=
• ADR 0004 — Database split: one Postgres 18 instance, six databases
• ADR 0005 — Frameworks and the approved dependency table
• ADR 0006 — API clients come from one factory
• ADR 0007 — Typed service container (DI / IoC)
• ADR 0008 — Singleton scope: what may live at module level
• ADR 0009 — One variant API for every inventory component
• ADR 0010 — Media path: presigned URLs from ddx-api after the org check
• ADR 0011 — Media proxy: MinIO only through ddx-api
• ADR 0012 — Density names: compact | cosy | large
• ADR 0013 — Platform super-admin acts as org-admin of the target org
• ADR 0014 — Unified settings: one registry, three tiers, one resolve in ddx-api
• ADR 0015 — Entity kernel: one descriptor, one access seam, one projection, one proof chain
• ADR 0016 — SSE Bus: Redis Streams log, Redis pub/sub fan-out, BullMQ outbound queue
• ADR 0017 — Layered BFF: one route table, route classes, read models
• ADR 0018 — Cluster node registry, node identity, hot plug
• ADR 0019 — Tenant branding: settings keys, vendored palettes, public platform read
• Debug overlay

deploy/

• Deploy runbook — dudoxx-web-boot
• Entity kernel — guide
• Feature map — what each role can do
• Component inventory
• Naming constitution — dudoxx-web-boot
• Observability — one log layout, one key set
• Pattern reference — P1-P23 and groups A-K
• Port map — dudoxx-web-boot

research/

• RQ1 — Which release is "latest", and does it differ from the canon?
• RQ10 — SSE through the Next.js BFF route handler (desk half)
• RQ11 — Dev latency baseline: cold compile per route + next-server RSS
• RQ2 — Route group or dynamic org slug?
• RQ3 — better-auth 1.7 vs Auth.js v5: feature matrix
• RQ4 — Separate databases or separate schemas?
• RQ5 — Which frameworks beyond shadcn earn a place?
• RQ6 — How do DI, IoC and Singleton behave across RSC, client bundles and NestJS?
• RQ7 — Which data uses the server cache, which uses TanStack Query, how is each invalidated?
• RQ8 — Media path: presigned URLs vs streaming through the BFF
• Template triage — create-nextjs code in ddx-web
• Settings — guide
• Local setup — dudoxx-web-boot
• Shell tree — SiteShell and PortalShell
• SSE event catalog
• Version pins — dudoxx-web-boot