 Hello. I'm Tom Zufal. I'm with Red Hat. I'm a principal software engineer there. And I think we're running about seven minutes before the schedule, which I think I can abuse a bit and make my talk a tiny bit longer. So here's plugins made simple. No rebuild needed. I know this is a very hot topic, so let me share a bit of a personal story here first. When I first came to backstage, it was about a year and a half ago, or about two years. As a good cloud native kid, I've tried to deploy it on a Kubernetes. I took a container from Docker Hub, deployed it, figured out that there's some configuration needed. So I did the configuration, redeployed again, and I had the backstage running so far so good. And then I thought, how do I make it do anything useful for me? Backstage is all about plugins, all about integrations with third party systems. How do I get those plugins in? And that's when I hit the wall. So the conversation was as follows, and I think many of us experience the same. How do I install a plugin into backstage? Oh, you do your install. Well, that means I have to maintain a code base, right? I don't want to maintain a code base. Well, yeah, you do. What's the problem? Well, it was a problem for me because I went from this simple workflow to this complex workflow. Now I need to maintain an inner loop. I need to have folks inside my company taking care of backstage code base, maintaining it, updating it, building containers. I need to have CI. I need to have all these things. So all of this has consequences. Each plugin install triggers an MPM dependency tree which means I can get my dependencies updated. I need to do a security audit. I need to do a container rebuild. I need to maintain a base image with node.js runtime. So I need to have a security audit for that as well. And I need to have CI enabled. I need to have a Docker registry somewhere for my private image and whatnot. So all of this is extra work that I need to put in into personalizing backstage. And that's a consequence for end user, right? For backstage adopter. As for Adhatar, we are a backstage vendor. We have additional consequences of this. Each customer has their own specific needs. So we would, in this scenario, need to maintain a diverging code base per each customer. We would need to have a container image per customer. Customers have their own custom plugins that they internally wrote. We need to integrate their source code into our product, which is just complexity growing. So it doesn't scale. This doesn't scale at all. So to solve this problem, we need to make plugins to behave like true extensions. If you think of VS Code extensions, if you think of Grafana plugins, all of these things are pluggable separately from the core instance. So my plugin code base or my plugin itself is packaged separately from the core runtime, from the core instance. It's completely self-contained and it can be installed through configuration only. Via its, through UI, via its through config file, doesn't matter at this point. I need to have it self-contained. I need to have it done through configuration. So this, let's assume it's all done. I can make this workflow a bit simpler again, right? Instead of having this complex two loop system with maintaining backstage code base and maintaining backstage instance, I can basically simplify into this. Get rid of the inner loop and through updating configuration, I can side load plugins when deploying backstage only. So how do we achieve that? In backstage over the last year, there was a great work done through new backend system and new front-end system coming fairly soon. I think it's in alpha stages at this moment and it will be probably at some point stable. Those things allow you to configure plugins through configuration actually, not through code, right? But that's not everything. That's not what I'm talking about. That's not dynamic plugins. We need a mechanism that allows you to side load those plugins. You don't need to bake them into the container. And for that, we have two RFCs or one RFC and one web. The first one for the backend side is already implemented. There's already a package available in the upstream community to be used to provide you with a dynamic side loading of backend plugins. And for the front-end, we are getting there through the back process, through the back number two. So just a quick comparison here. When I compared the new system, new declarative integration, new front-end backend system and the new system plus dynamic plugins. So instead of me doing yarn install, I can just write an entry into a config file instead of configuring the plugin through TypeScript or in the new declarative integration through config, I can do the same. I can just leverage the config. And the most important change here is, for me to actually deploy this change, the new plugin into a running backstage instance, I don't need to rebuild my code base and package it inside a container image and then redeploy, I just redeploy. Which is just a container restart. I don't need to do anything special, anything else. So what do I need to do to support this on the container side? We don't want to impose new changes on you if you're developing plugins. We don't want you to rewrite a plugin from scratch again. There's been mandatory changes for the new front-end backend system. So we leverage those and all the changes that need to happen to support the dynamic plugin mechanisms is just metadata, just configuration on the plugin side and using additional tooling to build those assets that are directly consumable by the core instance. So the only prerequisite there is that you support the new front-end and new backend system. And to wrap this up, there are two QR codes here. One for the dynamic feature backend service, which is already a package that's ready to use and one for the web number two that is currently being contributed to and is open for suggestions. So I thank you very much for your attention here and see you around in those GitHub issues there. Thank you very much. Thank you, Tom. All right, next up, Emma from Spotify. Over to you. Any questions for Tom while Emma's setting up? Yes, oh, you're on. I can feel the energy. Let's hear it. Sorry, it's me again. So the question is because you've said that the only thing right now with this new system in place is to change a config and redeploy. That's not enough for me. So what I would love to see is actually not having to run the deployment pipeline to create a new YAML configuration file and put it on the server. What I would like to see is actually being able to do that from the UI to select the version of the plugin I want to use and keep that information in database. Then I can restart the container. That's not a problem. I wouldn't like to run the deployment pipeline to put the new config file in place. Definitely. We want to get there at some point. This will require introducing concepts like operators into Backstage or concepts like administrative UI into your Backstage instance. And we already have some of these parts in developer hub that ProHead provides as an opinionated Backstage offering. But we're trying to get those things into the upstream community as well. So we'll get there at some point. Now the challenge is to properly implement those dynamic loadings of those individual plugins into the runtime that is sufficient for Backstage and scalable for Backstage internally. So yeah, we'll hopefully get there at some point. Okay, yeah, thanks. Thank you. Any other questions? Questions on that side? Maybe a stupid one, but the new front end plugin system will it enable to use other front end technologies but react going forward as well? So is that something for adoption that you're looking for? I don't know. I don't answer to that. I think that's a question to maintainers. What we do with dynamic plugins as dynamic plugins, we basically allow you to load any module, any JavaScript code into the system. So whatever you do with it, whatever you do internally in your plugin, that's completely transparent to us. We don't care. Last question. Hello, one quick question. Is the new plugin system that you talk about is gonna be open source or is it only available a part of Word that had Backstage? Totally open source. And we have the backend side already in the upstream community released and we are going through a review process for the front end side on the Backstage enhancement proposals. We don't want to shield anything from the community. So everything's going upstream.