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:
As you may expect, microapplications are not “a free lunch”. However, the drawbacks are significantly fewer, than in the case of microservices:
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.
Sergey Seroukhov, Enterprise Innovation Consulting