KodeKloud Notes

In this lesson, we dive into Backstage plugins, the building blocks that let you extend Backstage with new features, customize the UI, and integrate with third-party services.

What Are Backstage Plugins?

Plugins are self-contained npm packages that add or modify functionality in Backstage. Because Backstage is entirely plugin-driven, every core feature—from the software catalog to TechDocs—is implemented as a plugin.

The image is a graphic titled "Plugins" showing four steps: adding new features, modifying existing features, customizing the UI, and integrating with third-party systems.

The image illustrates the concept "Everything Is a Plugin" with a puzzle piece design, showing components like Catalog, Templates, TechDocs, and Search.

Backstage Architecture Refresh

Backstage consists of a React front end and a Node.js back end connected to a database. Each plugin can include both front-end and back-end components. For instance, the Catalog plugin’s front end handles UI events and sends requests to its back end, which then queries the database and returns results.

The image illustrates a "Backstage Architecture Refresh" diagram, showing a user interacting with a system composed of frontend and backend components, using React and Node.js, connected to a database.

Organizing Plugins in Your Monorepo

Each plugin lives under the plugins directory with its own package.json. Your root package.json workspaces might look like:

{
  "workspaces": {
    "packages": [
      "packages/*",
      "plugins/*"
    ]
  }
}

Because they’re independent npm libraries, you can:

Develop and test plugins in isolation.
Publish and share plugins via npm.

Backstage also maintains a rich ecosystem of third-party plugins. Browse them at backstage.io/plugins before building your own.

The image shows a webpage listing various plugins for Backstage, each with a brief description and an "Explore" button. The plugins cover different functionalities like analytics, reporting, and API management.

Plugin Architecture Types

There are three main plugin architecture types in Backstage:

Plugin Type	Description	Use Case
Standalone	Runs entirely in the browser with hard-coded data (no external requests).	Simple UI demos or prototypes
Service-Backed	Combines a frontend plugin with a backend service that fetches data from a database or API.	Catalog, TechDocs, analytics dashboards
Third-Party-Backed (Proxy)	Uses a backend proxy to forward requests to external services, adding credentials securely.	GitHub integration, cloud provider APIs

The image illustrates three types of plugin architecture: standalone, service-backed, and third-party backed, each represented with a simple icon and label.

1. Standalone Plugin

A standalone plugin is a React component with static data and no external HTTP calls.

Note

Standalone plugins are ideal for quick demos or simple data visualizations, but they’re not suitable for dynamic content.

The image illustrates a plugin architecture diagram, showing the interaction between a standalone component, frontend, backend, and a database.

2. Service-Backed Plugin

Service-backed plugins consist of:

Frontend plugin: Makes HTTP requests.
Backend plugin: Retrieves data from databases or external APIs.

The image illustrates a plugin architecture with a flow from a catalog frontend to a catalog backend, which connects to a database. It also includes a section labeled "Service backed" with the number 02.

3. Third-Party-Backed (Proxy) Plugin

When integrating services you don’t control (e.g., GitHub), use a backend proxy:

Frontend sends a request to your backend proxy.
Proxy attaches credentials (API tokens) and forwards the request.
Third-party service responds; proxy returns data to the frontend.

This avoids CORS issues and keeps credentials secure.

Warning

Always secure your proxy endpoints to prevent unauthorized access to third-party credentials.

Plugin Presentation Styles

When you implement the frontend portion of your plugin, choose one of the following styles:

Full-Page Plugin

Gives your plugin a dedicated route (e.g., /my-plugin) and full Backstage page.

Catalog-Based Plugin

Injects custom cards or panels into existing catalog component pages.

The image shows a screenshot of a frontend plugin interface for a company catalog, featuring a sidebar menu and a list of owned components.

For example, add a panel to the About page of the Auth Service:

The image shows a user interface for a frontend plugin, specifically a catalog plugin, with details about an "auth-service" including its description, system, type, lifecycle, and a relations graph.

Tab Plugin

Adds a new tab under an existing component view (e.g., CI/CD, API Docs, Dependencies):

The image shows a frontend plugin interface with a tab labeled "03 Tab Plugin" and a section for "auth-service" indicating no CI/CD is available, with a prompt to add an annotation for enabling it.

You now have a solid understanding of Backstage plugins—how they’re structured, where they live, and how to present them. Happy plugin building!

References

Watch Video

Watch video content