Skip to main content

⚛️ Reactor

Application builders hit a wall when a feature spans the browser and the server: frontend and backend plugin systems usually disagree about discovery, dependencies, lifecycle, compatibility, and enablement. Teams duplicate those contracts, hard-wire optional features into the host, and must coordinate rebuilds and deployments just to add, remove, or replace one capability.

Reactor gives JavaScript frontends and Python backends one extensibility model, inspired by VS Code, Eclipse (OSGi), and other proven plugin systems.

Reactor Example Music

Reactor ships two sibling packages:

PackageLanguageWhat it is
@datalayer/reactorTypeScriptA plugin runtime with a framework-agnostic core and a separate React integration.
datalayer_reactor (imported as reactor)PythonA FastAPI + pluggy plugin platform for modular extensibility.

Both tiers implement the same architecture, and that is the point of writing it down once: a host that lists, describes, groups or draws plugins should never have to ask which side of the wire a plugin came from.

Start here

The shape of it, in one diagram

Reactor provides the contribution point; a plugin targets it. Nothing on the Reactor side names the plugin, which is what lets a plugin be added, removed or replaced without the host knowing.

Everything in this documentation