Plugins and the microkernel pattern

A plugin architecture keeps a small core that knows how to run extensions but not what they do, and puts each optional feature in a plugin that the core finds and loads when it is configured. The microkernel pattern applies that idea to a whole system: the core holds only what every installation needs, a registry and one stable interface, while file formats, payment methods or editor commands live in plugins behind it. Martin Fowler’s catalogue sums up the Plugin pattern as linking classes “during configuration rather than compilation”. Reach for a plugin architecture when other people or other teams must add features without editing or rebuilding the core. Skip it when every feature ships with the core anyway: the interface then only adds a layer, and the plugins are just modules with extra ceremony.

How a core finds its plugins

Every microkernel pattern has three parts: the core, a stable plugin interface the core defines, and a way to discover which plugins exist.

Discovery is where languages differ most. The common ways, each with one sentence on what it does:

• Explicit registration: each plugin calls the core’s register function, or the application lists its plugins in one place.
• Python entry points: an installed package names its plugins in its metadata, and the core asks importlib.metadata for one group.
• Subclass registries: __init_subclass__ adds every subclass of a base class to a registry when its class statement runs.
• Java’s ServiceLoader: it finds the classes that implement an interface, listed in META-INF/services files on the class path.
• Go’s compile-time registration: a plugin package calls Register from init, and a blank import includes it, as database drivers do.
• Go’s plugin package: it loads compiled plugins while the program runs, but only on Linux, FreeBSD and macOS.
• Rust trait objects and Cargo features: they choose plugins when the program is built; loading code at run time needs unsafe code.
• A separate process or a WebAssembly module: it keeps a third-party plugin’s crash or hang away from the core.

Here is the smallest working core, with explicit registration. The core’s run() never names a plugin; three plugins register themselves with a decorator:

"""A tiny microkernel: a core that formats text knows nothing about any formatting rule. Rules are plugins that
register themselves with the core's registry, and the core runs the ones a user asks for, by name."""

import re
import unicodedata

PLUGINS = {}  # the core's registry: name -> function


def plugin(name):
    """Registers the decorated function as the plugin `name` (explicit registration)."""

    def register(fn):
        if name in PLUGINS:
            raise ValueError(f"a plugin named {name!r} is already registered")
        PLUGINS[name] = fn
        return fn

    return register


def run(text, names):
    """The core: apply the named plugins in order. It never mentions a plugin by name itself."""
    for name in names:
        if name not in PLUGINS:
            raise LookupError(f"no plugin named {name!r} (installed: {', '.join(sorted(PLUGINS))})")
        text = PLUGINS[name](text)
    return text


# ---- plugins: each could live in its own module; importing the module registers it ----
@plugin("upper")
def upper(text):
    return text.upper()


@plugin("ascii")
def ascii_letters(text):
    """Transliterates accented Latin letters to plain ones: é -> e."""
    return unicodedata.normalize("NFKD", text).encode("ascii", "ignore").decode()


@plugin("slug")
def slug(text):
    return re.sub(r"[^a-z0-9]+", "-", text.lower()).strip("-")


title = "Crème Brûlée & Café Menu"
print("installed:", ", ".join(sorted(PLUGINS)))
print("ascii, slug:", run(title, ["ascii", "slug"]))
print("ascii, upper:", run(title, ["ascii", "upper"]))
try:
    run(title, ["emoji"])
except LookupError as e:
    print("emoji:", e)

installed: ascii, slug, upper
ascii, slug: creme-brulee-cafe-menu
ascii, upper: CREME BRULEE & CAFE MENU
emoji: no plugin named 'emoji' (installed: ascii, slug, upper)

Asking for ascii then slug turned “Crème Brûlée & Café Menu” into creme-brulee-cafe-menu, ready for a web address, and a plugin nobody installed failed with the list of the ones that exist. More plugins mean more registered functions, never a change to run().

A stable, versioned plugin interface Pro: opens with a Pro, Premium or Ultimate pass