Posted on

Make Your Backstage Templates Resilient

I suppose that you are a user of Backstage and have your own templates that automate some repetitive and/or complicated flows of your organization. Some of your templates take a long time to be executed. For example, you provision your infrastructure, and your template guards the process along the way. Now, you are happy that you provided your engineers with these templates to lessen their burden, but you have to be careful with redeploying Backstage because you might fail ongoing tasks and make your engineers angry.

Here, I’ll explain what actions you can follow from release v1.23.0-next.0 to make your templates resilient to redeployment or any accidental server failures.

Posted on

Scale Your Frontend Application

As a continuation to my first article, I prepared an implementation of a simple project to show a workable solution. 

Before going into detail, I’d like to note that I decided to change the name to Scale instead of Pluggable, as it better highlights the potential of this architecture. The idea is not only to create plugins for an application but actually to drive the development of frontend itself from multiple sources. And the core feature of this itself has to be to split the application into pieces and not create monolith. 

Posted on

How to Deal With CSS Issues in IE When You Have No Idea How to Fix Them

I've been working closely with cross-browser compatibility issues for more than 5 years, and during that time, quite a few people changed on the project I'm working on. During this time, I noticed that developers are often only as proficient in CSS as they need to be to get a given job done, even if a person positions themself as a web developer. These issues are most often highlighted when it comes to supporting Internet Explorer.

For those who've never been deeply involved in such issues, I'll explain what makes IE so special and hard to work with. First of all, developers are not often using Windows as their OS on laptops/computers for development. To work with IE, to verify that it works as expected, you have to install VirtualBox with Windows on it.

Posted on

Creating a Frontend Architecture With Dynamic Plugins

The following are some of the most used approaches to handle pluggability on frontend:

  1. The main application works like a layout for all the features it contains, where each feature has switch on/switch off functionality. If a plugin is present, it will be displayed in a certain place. But, if you want to develop a new plugin, you will need to modify the main application, so it will be aware about it.
  2. Load plugins dynamically and add them to the main application as sub-applications in an iframe. That gives certain flexibility, as you can use different versions of the same third-party libraries, but there are also some costs, including:
    • The bundle size blows really fast. All required third-party plugins have to be included inside the plugin again.
    • To reuse already written logic in a core plugin, you either have to copy and paste it or create a shared-module with common functionality and include it in the core and custom plugin. In this latter scenario, when this shared functionality is different from plugin to plugin, it can become a mess really quickly. 
    • It will not allow you to bring smallchanges to an application, like replacing a button with a new one on the fly.

Keeping these limitations in mind, let’s have a look at a new approach. First, I will explain it with a simple example and then on a more advanced level.