You don’t need frontend developers for Backstage integration. But you do need adopters.

For more content like this subscribe to the ShiftMag newsletter.

Last year, I took the initiative to build a new internal developer portal with several other great engineers. We were all very enthusiastic, but there was one fundamental thing missing. Altogether,  we had 0 to no experience  with TypeScript and MERN stack, on top of which Spotify’s Backstage platform was built.

All of us were passionate backend engineers with a few years of experience working in the infrastructure department. Our tech stack consisted of more traditional technologies like Java’s Spring and SQL databases. Naturally, the biggest concern was how we would handle technologies we weren’t familiar with and build user-friendly and intuitive interfaces. After all, we were backend developers who preferred writing command-line instructions, deprived of a sense of good user experience.

 On the other hand, we had an ace up our sleeves – a deep understanding of how our platform works.

 Contrary to popular belief, we pulled off deploying Backstage in our platform and integrating it with the existing tools without any major challenges. The biggest issue was (and still is) its adoption.

So, where is the catch?

Backstage has its set of core features, but it is also possible to extend it with your own or 3rd party plugins.  Core features or 3rd party plugins usually work without much hassle – *your custom configuration gets injected in premade modules through YAML files.  *

You can build interactive forms with multiple steps without writing any React code. This core feature is called Software Templates. We wanted to facilitate the bootstrapping of the Redis cluster. We had the define form which accepts configuration and actions that will be invoked on submission. The form was again defined through YAML. We had to write those simple actions in TypeScript, but after all,  which developer doesn’t know how to write a function in any language?

  When we decided to improve Search, another core feature, the biggest effort was to optimize the PostgreSQL search engine and decide if it was worth going a step further and experimenting with Elasticsearch – in the end, it was.  

While setting up authentication and SSO , the challenge was to explore all existing methods used throughout our company and unify them under one. Again, a task better suited for a platform engineer.

With custom-made plugins, there was a little bit more React / TypeScript work. You have to figure out React fundamentals and start writing code. Backstage already provides out-of-the-box React components that follow their design principles, so you won’t have to think about colors and paddings. If those components are not enough, you can use MUI components from which the Backstage components are derived. Don’t worry, the internet is brimming with code examples.

In the end,  our knowledge of the platform and underlying infrastructure played a major role  in our experience with developer portal integration. Lack of experience with frontend frameworks surely slowed us down a bit, but we learned along the way.

The struggle

The biggest challenge, however, was yet ahead of us. It was (and still is) transitioning users from the old toolset they’ve been accustomed to. Despite the significant improvements in user experience and the addition of new functionalities, most users remain hesitant.

To illustrate, we have a 10-year-old application management dashboard that is extensively used, but also notorious for its bad user experience. We modeled the new one after it, with a better user experience in place, but our developers still prefer the old one. When we asked them why they were not switching to the new one, their answer was simply – we don’t trust it.

We also developed several nice and shiny plugins, a few features based on user requests, and resolved bugs we introduced on the way. Despite these efforts, *our Backstage has yet to catch momentum. *

We acquired most users when we organized a two-day hackathon, where each of the 9 teams built a plugin they needed. Only one plugin is extensively used , but it brought around 40 daily active users, which is only 5% of our engineering organization.

Despite the struggle, I believe that with good marketing, workshops, and constant improvements, we will bring most of the engineers to use and contribute to Backstage. When that happens, I’ll make sure to let you know how we managed to do it.

The post You don’t need frontend developers for Backstage integration. But you do need adopters. appeared first on ShiftMag.