TriggerMesh Bridge Template for Backstage

Sameer Naik
Sameer Naik
Oct 11, 2022
TriggerMesh Bridge Template for Backstage
TriggerMesh Bridge Template for Backstage

Backstage is an open platform for developer portals. With Backstage all your software components, data, documentation and so on, are made available at a single location. Backstage was first developed by Spotify and has been within the Cloud Native Computing Foundation (CNCF) for almost two years. We often hear from customers and prospects about how they are adopting Backstage or evaluating it to become the main portal for their developers.

At TriggerMesh, we developed an experimental software template for creating a TriggerMesh integration in Backstage. This showcases how a DevOps or platform team can empower developers in their organizations to easily connect event sources with their applications. We decided to experiment by creating an integration that reads messages from an AWS Simple Queue Service (SQS) queue and delivers it to a service after applying a Transformation on the SQS message. Consuming SQS messages and delivering them to microservices is a very common pattern, recently we showcased how ManoMano is using it.

This blog is another step-by-step walkthrough that introduces what can be done with the TriggerMesh Backstage template, we are working on more and would love to hear your feedback.

The software template

The software template is publicly hosted at the triggermesh/backstage-sqs-bridge-template repository on GitHub. To use it, you need to first register the template in your Backstage instance and you will see the SQS to Service Integration card appear in your components catalog.

The form of the template looks like this:

The SQS Source section of the form enables you to configure the SQS queue parameters along with the AWS credentials required to access the queue. In the Transformation section, you could modify the incoming CloudEvent using the Transformation object. By default the template applies a Transformation to only forward the message body to the downstream service sink. In the Service sink section you can configure the service that will receive the message from the Transformation object. By default, the form uses sockeye which is a Websocket based CloudEvents viewer. Finally the Deployment section configures the AWS Elastic Kubernetes Service (EKS) cluster details and the namespace where the bridge will be deploying using GitHub Actions workflows. It's important to note that the cluster configured here needs to have TriggerMesh and its dependencies installed in order for the bridge to deploy correctly.

After creating the component, the GitHub Actions workflow kicks in and deploys the bridge to the cluster at the specified namespace.

The YAML manifests for the bridge are located inside the manifests/ directory of the repository. Any changes to the YAML manifests in this directory are automatically applied by the CI workflow.

The metrics/dashboards directory contains sample dashboards for Grafana that can be used to monitor the various aspects of your bridge. These dashboards contain the tags that let the Grafana plugin know about the dashboards that should be listed in the Backstage UI.

Here’s what the sample dashboards look like:

And finally, the docs/ directory contains sample documentation that is rendered by the Backstage UI.

We hope that you give this template a try and share your feedback and suggestions by filing an issue at the GitHub repository. We look forward to hearing from you.

Related Posts

Join our newsletter

Sign up for our newsletter for the latest news, training, and offers to help you build event-driven systems with TriggerMesh.