event-kind-backend
The event-kind-backend
plugin is responsible for two pieces of functionality:
- Ingesting Event Entities and validating them.
- Generating custom relations between consumers and producers.
This plugin is imported into The Hub here.
Validating Event Entities
Backstage uses JSONSchema to ensure all Entities pass validation before getting registered in the catalog.
The schema specification for Event Entities can be found here. The EventKindProcessor accepts Entities whose Kind is of Event, validates them against both the base Entity Schema and the Event Entity schema and then registers them with the catalog when they pass validation.
Generating Custom Relations between Consumers and Producers
Backstage has the ability to generate relations between two entities. This may portray the consumption of an API, or the ownership a team has of a component.
In our case, we want to model any relation between Entities where one is subscribing to an event produced by another. To do this, we have an EventRelationProcessor that emits relations between two Entities.
The EventRelationProcessor
relies on an optional subscribesToEvent
property in any consuming Entity's catalog-info.yaml
file to generate a connection to an Event Entity.
Relations in Backstage are directional, always from one Entity to another. The EventRelationProcessor
emits a subscribesToEvent relation from the consuming Entity to to the Event Entity. By the same token, the processor emits a providesEventTo relation from the Event Entity to the consuming Entity. The end result of this generation is a table rendered in the event-details
OverviewComponent, displaying all Entities currently subscribed to an Event.
The subscribesToEvent
property is an array of strings, where each string is the name
found in an Event Entity's catalog-info.yaml
metadata
property. For example:
A consuming Entity might be a Component that is using the subscribesToEvent
property to consume an Event.
# example consuming Entity:
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: event-component
description: Component that consumes events
spec:
type: service
lifecycle: production
owner: team-a
subscribesToEvent:
- event-bus-dev-portal-test
The value event-bus-dev-portal-test
corresponds to metadata.name
in another catalog-info.yaml
file:
# example Event Entity
apiVersion: backstage.io/v1alpha1
kind: Event
metadata:
name: event-bus-dev-portal-test
description: a place for event bus documentation
title: Event Bus Dev Portal Test
# ... catalog file continues...
This plugin was created through the Backstage CLI