Architecture
Extensibility model
The two ways to extend Golden Reports - custom blocks and custom data connectors - and the trust model that makes both safe to install.
Two parts of Golden Reports are designed to be extended: the block library (what authors can place on a page) and the data connectors (what kinds of systems the platform can read). Both are plugins; both have clean boundaries; both flow through the same install and trust model.
This page is the what of plugins. The build-it pages - Block plugins and Data source connectors - cover the how (including the actual tech stack you'd write code in).
Two extension surfaces
| Surface | Runs in | Adds |
|---|---|---|
| Blocks | The report editor (in the browser) | New placeable elements in the editor's palette. |
| Data connectors | The data provider (server-side) | New kinds of data source you can register. |
Both surfaces share the same philosophy:
- The host knows nothing specific. The editor doesn't know what a "barcode" is; it just renders blocks. The data provider doesn't know what "Postgres" is; it just fetches rows.
- The plugin owns its configuration shape. Blocks declare their properties; connectors declare their config fields. The host renders whatever the plugin asks for.
- The contract is small and stable. Adding a new kind of block doesn't change the editor. Adding a new kind of connector doesn't change the engine.
This is what makes the platform composable without becoming a framework you have to learn.
Blocks
A block plugin adds new blocks to the editor's palette. Authors drag them onto a page, bind them to data, and style them just like the built-in blocks. The blocks shipped out of the box are themselves built on the same plugin shape - there's no privileged "core" code path.
A plugin can ship one block or many. Once installed, its blocks appear in the palette next to the built-ins.
See Block plugins for the development guide.
Data connectors
A data connector teaches the platform how to read from one kind of system. The connector defines its own configuration shape (which the Manager renders as a form when you register a data source) and implements four operations: identity, health check, schema discovery, and fetch.
Connectors run in a sandboxed environment with no filesystem access, no arbitrary network access, and no environment-variable access. The only outbound operations available are the ones the host explicitly exposes - HTTP requests and outbound socket calls.
See Data source connectors for the development guide.
Distribution: the Marketplace
Both plugin types are distributed through the Marketplace in the Manager.
- Workspace admins browse the Marketplace, install a plugin, and the Manager pulls the signed bundle into the organization's plugin registry.
- Updates flow the same way - the Marketplace surfaces newer versions, and admins choose when to upgrade.
- Private plugins can be side-loaded directly (for organizations with custom connectors that don't belong in the public catalog).
Trust model
A few invariants worth knowing:
- Block plugins run with editor privileges. Install only block plugins from sources you trust. The platform sanitizes block output and routes data access through the host's query layer, so a block can't reach arbitrary URLs.
- Connector plugins run in a server-side sandbox with a small set of host-exposed capabilities. Install only connectors from sources you trust.
- Versioning is enforced. Each plugin declares its version; the platform checks compatibility before loading. Incompatible plugins are rejected before running.
- Signing is enforced for production installs. Marketplace bundles are signed; the host verifies the signature before loading.
What the platform refuses to extend
Some pieces are intentionally not pluggable:
- The data flow model. Parameters, variables, queries are part of the platform's contract; you can't replace it with a different binding model.
- The export pipeline. The PDF renderer is part of the platform; you can't substitute your own.
- The authentication model. Identity is configured through the platform's settings, not a plugin.
These constraints exist because cross-extension correctness gets exponentially harder when every layer is pluggable. Two extension points (blocks and data connectors) is enough composability for most real-world needs.
Themes as a "lite" extension
A workspace's theme is a data record (no code), but it's distributed through the same Marketplace plumbing as plugins. A vendor can publish a theme bundle that a customer installs into their workspace; the Manager imports the tokens and registers the theme. See Themes & styling for the runtime model.
Next
- Build a custom block: Block plugins.
- Build a connector: Data source connectors.
- Understand the surface that hosts blocks: The report editor.
- Understand the surface that hosts connectors: Connectors.