The rise of microapplications

‍

When microservices entered mainstream development, they changed the way we built complex enterprise backends. At the same time, complex enterprise frontends suffer from similar problems as their backend counterparts. Aside from these frontends being very challenging to develop and maintain, the biggest problem lies in constantly changing technologies. Backend technological stacks change every 3 to 5 years. Frontend technologies, on the other hand, require major upgrades every 6 to 12 months.

Just imagine, you spent hundreds of thousands of dollars on the development of a Web application, and almost immediately it becomes obsolete. Technically speaking, you can continue the development for some time without doing any upgrades. But this deprives you of the latest versions of controls, and you’ll stop receiving support and bug fixes as well, which are so critical in the ever-changing world of the Web.

This poses a question: if we solved similar problems on the backend with microservices, it is possible to use a similar approach on the frontend? Can we build a complex frontend as a collection of independent pieces and deliver them incrementally, so we never have to deal with them “en masse”? The answer to this question is “yes”. This is made possible by “microapplications” - independently delivered pieces of frontend applications.

Let’s give microapplications a formal definition.

“A microapplication is a software development technique that structures an application frontend as a collection of loosely coupled applications. In microapplications architecture, applications are fine-grained, and their look & feel is consistent to create a seamless user experience.”

As we decompose a monolithic application into microapplications, the result may look similar to the picture below.

‍

One microapplication can be responsible for user signin and signup. After a user is successfully authenticated, a session object is created and passed into other microapplications through a shared persistent storage. Another common microapplication is a homepage or dashboard, to which users are redirected right after entry. From here, users are free to navigate to specific areas of the application, which are also implemented as independent microapplications. The key is to ensure consistent Look & Feel, share user sessions and settings, and allow for free navigation, which creates the perception that the user is working with a single application.

When compared to traditional monolithic frontends, this approach stands out due to its numerous benefits:

• Lower complexity. Obviously, learning and maintaining an application with 10 screens is much easier than one that contains more than 100 screens. Now, new developers can be brought up to speed and become productive much faster. It also makes it easier to outsource UI development and maintenance to subcontractors.
• Incremental delivery. Microapplications can be developed, released, and deployed by different teams at different times, completely independent of each other. This results in higher development productivity and shorter Time-To-Market.
• Mixed technologies. Each microapplication can be built using its own technology stack. This minimizes the number of problems caused by constantly changing web technologies. Now, teams can work on upgrades one microapplication at a time. Other applications can stay on older technologies, until a need arises to do something with them.

As you may expect, microapplications are not “a free lunch”. However, the drawbacks are significantly fewer, than in the case of microservices:

• Lack of technology support. When building microapplications, capabilities such as sharing sessions, caching data, and managing states between application reloads need to be added. At the moment of writing, popular UI technology stacks do not offer such capabilities, so you have to build them yourself. However, it’s not rocket science and can be done in a matter of days.
• Deployment complexity. Deploying a single application is easier, than deploying a bunch of them. But with the help of a little automation, you won’t even notice the difference.
• Slower load time. This is definitely a serious issue for web applications. Every time users navigate between microapplications, it takes a few seconds to reload binaries, resources, and data from the server. Fortunately, browsers are able to cache static content, and server data can be cached in persistent storage. It’s always a good idea to load large datasets asynchronously, to avoid screen freezing.
• Complex state management. Imagine the following scenario: a user opens a microapplication that contains a map. They position the map, selects certain layers, and then realize that they need to switch to another microapplication. When they return to the microapplication with the map, the state that was stored in memory is gone and they are forced to start all over again. Very annoying… To improve user experience, states must be preserved between application reloads either by saving them in the persistent storage, or, as in the case of web applications, by reflecting it in pages’ URLs.
• Inconsistencies in Look & Feel. The Look & Feel between all applications must be identical, which is not easy to achieve. Controls in different stacks may behave differently. Teams may have their own way of doing certain things. Over time, the Look & Feel may evolve and even break old microapplications in the process. Well-defined UI guidelines and careful reviews are necessary to maintain a consistent Look & Feel over time.

Microapplications have been around for a while. One example is Amazon Web Services (AWS) console: http://aws.amazon.com. AWS cloud platform is massive and contains many complex services. The tools for managing those services were created at various times, by different teams, and, possibly, using different technologies. But, to the end user, the only difference is that a blank screen might be noticed for a second, when navigating between pages. Other than that, there’s a solid perception that the AWS console is a single application. Great job, Amazon!

Another good example is one that I personally experienced. In 2017 my team developed an industrial IoT system called iQuipsys Positron: http://www.iquipsys.com. Originally, it was built as a monolithic application using Angular 1.6. By the time the 1st version was complete, Angular had already evolved to version 4.0, and maintaining the complex app with over 100 pages became quite a tedious task for the web developer to whom it was assigned. The development essentially bogged down. After we split that monolith to microapplications, the light returned and we quickly started moving forward again.

Happy microapplicationing,

Sergey Seroukhov, Enterprise Innovation Consulting

‍