Dependency Injection & Configuration

A dependency-injection container is a registry of construction recipes: you register how each service is built, then ask for one and it builds the whole graph behind it. Handlers declare collaborators as constructor parameters and the container supplies them.

Installing a plugin runs its registration code against the application at startup: it adds components to the object graph, attaches request-pipeline hooks, and contributes overridable defaults. It is wiring executed once, not a per-request call.

Settings are read and validated first, then the object graph is built, then routes and middleware are registered, and only then is the listening socket bound. Binding last keeps traffic out until the application can serve it.

The singleton is built once and keeps whatever it was given, so a per-request dependency is captured from the first request and reused forever. Later requests then read the first request's state, which only shows up when requests overlap.

Because it moves wiring failures from run time to boot time. A missing, ambiguous or cyclic binding then stops the process while no traffic depends on it, instead of breaking whichever request first walks that branch of the graph.

Auto-configuration evaluates conditions while the application boots: is the feature's library present, is a setting switched on, and is the role still unregistered? When the conditions hold and your own registration is absent, the default is wired.

Frameworks merge configuration from ordered layers - built-in defaults, packaged files, environment-specific files, environment variables, command-line arguments - and the more deployment-specific layer overrides the earlier one key by key, so the most specific source supplying a key wins.

Binding converts merged configuration text into a typed settings object at boot - numbers, durations, enums, nested groups - and checks presence, parseability, ranges and cross-field rules there, so a bad value stops startup rather than a later request.

A startup hook is a callback the framework runs after wiring and before it accepts traffic. Eager checks belong there - validate settings, resolve critical components, verify required resources - so a broken process fails at boot, not at the first request.

Flip readiness to false first and keep serving for a moment so routers stop sending work; then stop accepting new connections; then let in-flight requests finish under a deadline; then release resources in reverse startup order and exit.

A profile is a named set of configuration overrides, one per environment, selected at startup by an environment variable or launch argument; activating it layers that profile's values over the base settings without changing the build.

Register by type when one implementation satisfies an abstraction, so the parameter type is the request. Add a name when several instances of one type mean different things. Use a factory when construction needs non-service values or a wiring-time choice.

Not ready. An open port only means the process is listening. Readiness should flip true at the very end of startup, once warm-up and eager checks have finished, so nothing routes traffic to an instance that cannot serve it well.

Close the scope: run each created instance's release hook, normally in reverse construction order, hand pooled resources back, and drop the scope's instance map. Skipping it leaks connections, which surfaces as pool exhaustion under load rather than as an error.

Resolve late instead of capturing: the handler passes the value in as a method parameter, or the singleton holds a factory it calls per use, or a scope proxy that forwards every call to the active request's instance.

Each component demands the other fully built, so no construction order exists. The fixes change the graph: extract the shared responsibility into a third component, reverse the edge that is only a notification, or merge two classes that are one.

Decide the winner explicitly instead of inheriting it from discovery order: declare precedence or a relative order, or register the intended component yourself and exclude the other. Then assert the resolved component in a startup test so an upgrade cannot reshuffle it.

Find the source first: read the startup report of which units matched and why, and list the effective registration for that role. Then override at the narrowest seam, and pin it with a test asserting the winning component.

Stop guessing and enumerate: get the service to print its effective configuration with the origin of each key, then reconstruct the source order, inspect the running process's environment, confirm which profile resolved, and check the key name survived namespace translation.

Default to process-wide components holding no caller state, and move one to the request scope only when it carries a single request's state or owns a resource released with that request. Enforce it with lifetime validation at startup.

A container pays off when the graph is large and churns, or the framework already resolves handlers through one; a small stable graph rarely repays it. Readability rests on one composition root, injected not fetched dependencies, and automated graph checks.

Split by consequence: let conventions own the boring, uniform wiring every service wants, and declare explicitly anything user-visible or security-relevant. Conventions buy consistency and a single upgrade point; they cost traceability and make the dependency graph part of your behaviour contract.

Classify each setting by how it varies - never, per environment, per instance, per run - and by sensitivity, then place it in the lowest layer that can express that variation. Cap layer count and share one source order across services.

Design the boot path to complete without its dependencies: verify settings and wiring eagerly, but retry reachability in the background while reporting not-ready. A service that exits when a dependency is down cannot rejoin on its own.