Mastering Seamless Integration: Gloo Portal with Backstage Environment

Check out this informative video where we walk you through the seamless integration of your Gloo Platform, specifically the Gloo Platform Portal, with your Backstage environment.
In this demonstration, we showcase a Gloo Portal environment with multiple API products deployed, including the intriguing catstronauts API within the MusicService, among others. Gloo Platform Portal defines API products as route tables, each of which contains essential metadata describing the API product, its version, and more.
Our Backstage configuration incorporates both the front-end and back-end plugins of the Gloo Platform Portal. The back-end plugin ensures that API products in the Portal stay in sync with the APIs managed in Backstage. As you can see, all four APIs are harmoniously synchronized between the Portal and Backstage.
Beyond this synchronization, we delve into the API definition, available in the form of the OpenAPI specification. This specification mirrors what you would find in the developer portal UI of Gloo Platform Portal.
Gloo defines API products and their underlying servers using Kubernetes Custom Resources (CRs). We highlight the route table CR responsible for defining the API product, and a YAML file that contains both Kubernetes services and deployments, essentially shaping the API's implementation, all deployed on the Platform.
To make this integration even more seamless, we've configured the Backstage Kubernetes plugin, which allows us to synchronize Kubernetes information with the Backstage environment. In our case, it tracks Solo APIs and their route tables.
In our Backstage environment, we initially have no deployed components or registrations. However, we create a Backstage component definition, registering the "track service" for the catstronauts service. The key here is the label we've configured on this CR, which matches the labels used for our route table, service, and deployment. Consistency is key!
Within the Backstage component that defines our track servers, we can specify which API corresponds to a particular service. This is done through a configuration section that matches the synced API from the Gloo Portal API server.
Now, the crucial step is to register these components with our Backstage environment. We've crafted a handy script that interacts with the Backstage RESTful interface to achieve this. When executed, it creates the necessary entries, and you'll see a confirmation with a 201 status code. These entries will instantly appear in Backstage.
Finally, we explore one of these services - the tracks 1.0 service. In the relations table, you can see that the API for this component is provided by the catstronauts 1.0 API, complete with the synced API definition. We also showcase the open API specification for this API.
In the relations overview, you'll notice that this API is precisely what the component we registered in Backstage is built upon. Thanks to the Backstage Kubernetes plugin and our label selectors, we can seamlessly navigate to the Kubernetes view. Here, you can explore the service, the two deployments, and the route table that together define this API product and its implementation.
Feel free to dive into the route table to examine the YAML file and portal metadata, providing a comprehensive view of this API product in Gloo Platform Portal format.
That's a wrap for this quick demo! We hope you found it insightful and enjoyable. Stay tuned for more exciting content, and see you in the next video!