Agenda for Backstage Community Session (October 20 & 21, 2021) about community HOT 17 CLOSED

[Contributors] Moved to [Adopters]

👋 Frontside team would like to demo simulation tooling that we created for Backstage. We need this to create reliable integration testing. We'd love to show what we created and get some ideas from the community on the highest priority simulators that they'd like to see.

What is a good medium for this?

For those interested in the simulation that we demoed here are the slides and link to the repository for the demo.

• Demo Repository - https://github.com/thefrontside/backstage-simulacrum-demo
• Slides

from community.

[Contributors]

I would like to discuss the use of API Refs which sits in the core of Backstage frontend plugins to manage dependency injection. Would also like to pick @backstage/maintainers's brain on the philosophy behind it. 🙂

from community.

[Contributors]

Would love to quickly talk about building out a homepage template with contributors! No more than 5 minutes needed, preferably on Thursday's session! Specifically around > Issue 7249

from community.

[Adopters]

Would love to hear experiences with technical writers (rather than engineers) using Backstage's techdocs functionality. In particular, about them working with Markdown and GitHub.

from community.

[Contributors] I could go through Tech Insights backend and how the implementation looks on that one

backstage/backstage#7679

from community.

[Adopters]

Would love to learn more about the challenges conducting product adoption for backstage within the organizations :)

from community.

[Adopters]

We have recently released 2 new OSS Backstage plugins. Prometheus and Bugsnag.

Could be worth mentioning to keep the community updated.

from community.

[Adopters]

Best practices around incorporating aws resource (api gateway, ec2, rds, s3, cloudfront, etc) as well as where to put generalized docs around incorporating these (cloud front lints, cdk constructs, parameters to set) (maybe templates for these?)

from community.

[Adopters]

I would really like to hear what the plans are with regards to observability. The Prometheus metrics included in the catalog have been very useful for us internally, and I wonder what the plans are to "productionize" them, and possibly allow adopters to define their own metrics within the prometheus server (for example, instrument backend plugins to expose metrics as well).

from community.

[Adopters] & [Contributors]

Hi,

we are looking into adopting Backstage. If we do it, we anna go all in and be part of the community.

from community.

[Adopters]

We (Engineering Experience team at Wise) are right at the start of our backstage journey, having committed to trying to get it up and running with MVP configuration this quarter.

Some of the questions we're asking ourselves right now will presumably have been tackled by every adopter before us, and I wonder if there's anywhere for adopters to share learnings from this early stage process?

For example:

• How to convince key stakeholders of the value of a developer portal in the first place?
• How to get all engineers to view it positively and start using it without it feeling like yet another tool?
• How to measure success / value being added once we've managed to get it off the ground?
• How to know which core features / plugins to prioritise configuring for an MVP deployment?

Essentially, while the backstage docs are pretty great, I feel it might be useful for us to try and share learnings about adoption strategy amongst adopters.

If there's already some ideas around these things documented or adoption tips shared, I'd certainly appreciate any pointers! :)

Cheers,
Andrew

from community.

[Adopters]

Best practices around incorporating aws resource (api gateway, ec2, rds, s3, cloudfront, etc) as well as where to put generalized docs around incorporating these (cloud front lints, cdk constructs, parameters to set) (maybe templates for these?)

Hi @webark, I spent a little time yesterday creating 2 templates for building aws serverless services. https://github.com/RoadieHQ/software-templates

from community.

@punkle nice!! I'll have to check that out. Are you able to add techdocs to it too?

from community.

@punkle nice!! I'll have to check that out. Are you able to add techdocs to it too?

There is no reason why it couldn't be added. What had you in mind that might be added to the techdocs?

from community.

@punkle So let's say you start with your server less template. A dev create that, and you can put some stuff in the readme. But let's say they want to add an sns queue to talk with another service. Or they want to upload some files onto an s3 bucket. Or store some information in a dynamo DB. These are somethings where we want to have a little bit of documentation around, things like which constructs to use, best ways to configure.

Right now the are in a wiki. Some areas we've discussed is putting them in readmes for different CDK constructs, and we could make "CDK Construct" a type of component. We could have the different packages of several be libraries (which we will probably do). But we tossed around the idea of using a template, where you would go to choose "Datastore", and then it would ask a series of questions based on your use case, and then at the end, provide you with a construct and config that beat matches what you were wanting. (like RDS, Dynomo, Elasticsearh, Couchbase, etc with this configs)

from community.

@punkle So let's say you start with your server less template. A dev create that, and you can put some stuff in the readme. But let's say they want to add an sns queue to talk with another service. Or they want to upload some files onto an s3 bucket. Or store some information in a dynamo DB. These are somethings where we want to have a little bit of documentation around, things like which constructs to use, best ways to configure.

Right now the are in a wiki. Some areas we've discussed is putting them in readmes for different CDK constructs, and we could make "CDK Construct" a type of component. We could have the different packages of several be libraries (which we will probably do). But we tossed around the idea of using a template, where you would go to choose "Datastore", and then it would ask a series of questions based on your use case, and then at the end, provide you with a construct and config that beat matches what you were wanting. (like RDS, Dynomo, Elasticsearh, Couchbase, etc with this configs)

@webark that sounds interesting. Id love to see what you do come up with.

from community.

If you missed the sessions, the recordings are available

Adopters https://www.youtube.com/watch?v=Ja6z9AVGAPM
Contributors https://www.youtube.com/watch?v=aGwOohwIAGk

from community.