In a server-side web framework, what does installing a plugin or module actually do to the application?

## What a plugin or module actually is A **plugin** — different frameworks call it a module, an extension, a feature, or simply an installable unit — is a *bundle of registrations* that the framework knows how to apply to an application under construction. It is not the same thing as a library. A library is code you can call; the plugin is the thin layer that says **how that code attaches to this application**: what it places in the object graph, what it hangs on the request pipeline, what defaults it assumes, and which of those the caller may change. That distinction is the whole point of the question. Adding a package to the build makes code *available*. Installing a plugin makes it *wired*. Some frameworks blur the two by discovering installable units automatically from what is present in the build; others require an explicit install call. Either way, a registration step runs — the only difference is whether you typed it. ## What the install step does 1. The framework hands the plugin a handle on the **application being built** — the registry of components, the pipeline, the route table, the settings already loaded. 2. The plugin **registers components**: the objects its feature needs, usually keyed by the role they fill, so handlers and other components can depend on that role rather than on a concrete class. 3. The plugin **attaches hooks** to the request pipeline if its feature has to see traffic, and may **add routes** of its own (a status or metadata endpoint, for example). 4. The plugin **reads settings and contributes defaults** for anything the caller did not specify. 5. The framework **records that the unit is installed**, which is what lets later code ask whether the feature is present and lets a repeat install be detected. None of this is a per-request activity. What runs per request is whatever the plugin *registered* — the hook, the handler, the component method. Confusing the two is the classic junior mistake. ## Install time versus request time | Moment | What happens | Cost profile | |---|---|---| | Install (startup) | Registration code runs once; components created or their factories recorded; hooks appended; defaults filled in | Paid once; a failure here should stop the boot | | First request after boot | Anything the plugin deferred — a lazily created component, a warm-up — may resolve now | One-off latency on an early request | | Every request | Only the hooks and components the plugin registered | The steady-state cost the feature adds | ## Defaults and the configuration block Most installable units are designed to be useful with no arguments, so they carry defaults: a format, a size limit, a timeout, an encoding. Frameworks expose two seams for changing them: - a **configuration block passed at install time**, which the plugin applies to its own settings object before registering anything; - **externalised settings** the plugin reads, so the same build behaves differently per environment. A well-built unit also **stands aside** when the application has already registered something for a role it would fill, rather than overwriting it. Not every framework does this, and not every plugin inside a framework that does — which is exactly why "where did that default come from" is a real debugging question rather than a rhetorical one. ## Ordering, repeat installs and failure - **Order can decide the outcome.** If two units register for the same single-slot role, the surviving registration usually depends on which install ran last (or first — frameworks differ). If they both append to a pipeline, order decides the sequence rather than the winner. - **Repeat installs are not uniformly safe.** Some frameworks treat a unit as installed-once and ignore the second call; others happily register everything twice, producing a hook that runs twice per request. - **Install failures belong at boot.** A missing required setting or an unreachable resource discovered during installation should fail the startup loudly. Deferring that check to the first request turns a boot failure into a production error on a live user's request. ## What a plugin is not It is not a separate process, not a runtime code-injection mechanism, and not a substitute for understanding the wiring. Everything a plugin does, you could do by hand in the same startup code — which is the right mental model to hold when a plugin surprises you. The install is ordinary code; the reason it feels magical is only that you did not write it.