This message was deleted.

I was pondering for some time if I should write an answer to this one. Here goes. When designing a platform, you can think of it like any other large software that you design. It has a frontend (the portal), it has a backend (logic/functionality goes here, hopefully) and all of the other stuff (but let’s not overcomplicate the mental image here). Backstage comes with a software catalog and a plugin mechanism. The reason for that is, that you want to have your backend functionality plugged-in, providing either widgets that display data from the backend or buttons that trigger logic/functionality on the backend. The software catalog captures metadata on your components/apps/thing’a’ma’doodas™️ and also which of your plugins are applicable to this entry. A portal needs both capabilities to make sense and because of that they’re there. What usually comes along as well is scaffolding as a capability - you want to get something into the catalog of the portal and why you’re add it you can actually create the thing. That’s a nice added touch without making the basic model much more complex and can onboard additional functionality to be used in scaffolding via plugins. Anything else - you probably guessed it - needs a plugin and a corresponding backend. What you’re probably looking for as a keyword is

platform orchestration

. You can take a look at the tooling landscape (https://platformengineering.org/platform-tooling) to find actual products filling the gap and also some inspiration on other components your platform might need, which can be in the end also integrated into a portal or offered in a different way to your stakeholders (hint: devs hate portals and love CLIs / APIs / IDE plugins ).

I am well aware of platforms and the full tooling chain. I do see backstage as a SDK that you have to compose. I will disagree with your statement regarding favorite point of entry for developpers as not all devs are alike and some also like using UI in some scenarios (i manage 150 kubernetes clusters and 360 projects on them and as a solution architect am quite close to end-users/developpers). but that wasn't the question, the question is : did someone go further with backstage in working with inputs metadata & input discrepency to manage a full lifecycle when user interracts with UI/CLI or directly the git. Even with custom plugins, how did they manage to syncs schemas propagated with many tools (UI+CL+orchestrator+crossplane+policy engine...), three way merge. In a generic/resusable way. Tools such as kpt etc ... when building your own orchestration layer ... And the final feedback in backstage (argonotif feedback loops or any other composition).

The absence of that part of the answer was in fact the answer. I have not seen this working in any setup, yet. I would be - as you - highly interested if someone has actually completed that kind of setup with full lifecycle management via Backstage. Sorry for being to harsh on my GUI statement! Of course there are usecases where a GUI makes a lot of sense, but in a devs day2day they’re usually the minority.

👋 this is the biggest limitations we heard about from people so we build a Backstage component for Syntasso Kratix Enterprise (kratix.io). It provides full CRUD lifecycle support as a drop in option that works with any custom Promises. It also stays automatically up to date with any API changes chefs kiss Maybe we finally have a fun collaboration @Antoine BERMON 😏 I can show you in Paris if that helps?

Yup, that's the kind of topics we're working on,. This is not a requirement for a TVP but is an issue for larger scale adoption. As i'm trying to coordinate a larger scale initiative (multi french companies), our works will probably be publics (or via contributions to other projets with open governance 😉 #CNCF)

#apache2_ftw!

licences and governance aren't the same thing 😉 but we're getting offtopics

Agreed on both!