At American Airlines, we found making solutions generic enough for others to utilize and easily consume isn't always the easiest thing. We've had a couple instances where what we've developed internally hasn't been as friendly for open source consumption. So I would definitely encourage that. As far as thinking about building your own plugin, there is a UI component. There's the potential back end component, whether that exists in backstage or not.
Karl’s team at American Airlines were early adopters of Backstage, and in this episode he shares their journey of implementing and rolling out a developer portal. He also describes two of the extensions his team has built for their portal.
Discussion points:
- (1:24) Where the idea of building a developer portal came from
- (7:24) What the developer experience looked like before the portal
- (10:41) Initiating the project
- (14:16) The decision to choose Backstage
- (16:28) The V1 scope for the portal
- (19:14) Getting adoption for the portal
- (23:35) Defining success for the portal’s adoption
- (28:04) The ideal state for how developers will use the portal
- (30:56) Who should or shouldn’t invest in building a developer portal
- (33:14) Custom extensions Karl’s team has developed for their portal
- (37:46) What’s difficult about developing a new plugin for the backstage platform
Mentions and links:
Follow Karl on LinkedIn
The Runway platform at American Airlines
Read more on the engineering blog from American Airlines