Plugins
Plugin vs Service
Understand when to write a plugin, when to write a service, and how the two can work together
Plugin vs Service
This is one of the easiest conceptual boundaries to blur.
One-sentence version
- a plugin is closer to an extension layer
- a service is closer to a long-lived runtime instance
Better fits for a plugin
- you want to add explicit actions
- you want to insert hooks
- you want a resolve point
- you want to inject system text
- you want setup or usage protocols for Console
- you want plugin-owned runtime HTTP routes
Better fits for a service
- you need long-lived state
- you need a worker
- you need a session or connection pool
- you need a background runtime object
- many sessions should share the same instance
How they often work together
A very common pattern is:
- the plugin owns the extension surface and capability declaration
- the service owns the long-lived runtime state
For example:
- a plugin may hook into chat extension points
- while the actual long-lived chat runtime state belongs to
ChatService
A useful decision rule
If your main question is:
- "do I need to extend an existing runtime chain or capability surface?"
then the answer is often plugin.
If your main question is:
- "do I need an object that stays alive and owns state?"
then the answer is often service.
Recommended design order
- decide whether this is fundamentally a plugin extension-point problem
- decide whether it is fundamentally a service lifetime-and-state problem
- if both matter, split it into plugin plus service collaboration