New technology is adopted less because it is advanced than because it solves pain points.
In the past, I’ve always wondered if people really need microservices, if they really need a micro front end. After all, there is no silver bullet. When people consider whether to adopt a new architecture, in addition to its benefits, they also consider the numerous risks and technical challenges that exist.
Front-end legacy system migration
In the two months since the release of the Mooa microfront-end framework and its counterpart microfront-end Stuff, I’ve been receiving inquiries about microfront-end architecture on and off. One of the interesting things I discovered in the process is that addressing legacy systems is the most important reason people adopt microfrontend solutions.
In these consultations, developers are faced with a situation similar to the one I encountered before: designing a new front-end architecture. They started thinking about front-end microservitization because of legacy systems.
In the past, single-page applications using backbone. js, angular. js, Vue. Js 1, etc., have been running stably online with no new features. For such applications, there is no reason to waste time and energy rewriting old ones. The applications here, written using an old, no longer used technology stack, can be called legacy systems. These applications, in turn, need to be combined into new applications. More often than not, I see old apps written in Angular.js and new apps starting with Angular 2+. This is a very common technology stack for business stable teams.
Without rewriting the original system, manpower can be freed up to develop new business. This is not just an attractive feature for business people; It can be quite challenging for technical people not to rewrite old businesses while still doing some technical challenges.
The back end is decoupled and the front end is converged
One of the selling points of front-end microservices is that they are compatible with different types of front-end frameworks. This reminds me of the benefits of micro-services and the reasons why many projects are implemented micro-services:
In the early days, a big selling point for backend microservices was the ability to develop backend applications using different technology stacks. However, the reality is that organizations and organizations that adopt microservices architectures are generally medium to large scale. Compared with the medium and small size, the selection of framework and language is more strict, such as the internal framework, limited language. As a result, it is rare to see the full use of different technology stacks to take advantage of microservices. In these large organizations, the main reason for adopting microservices is to use microservices architecture to decouple dependencies between services.
In terms of front-end microservitization, on the other hand, aggregation is more desirable, especially for applications that are To B (To Bussiness).
In the last two or three years, there has been a trend in mobile apps where users don’t want to install as many apps. Often a large commercial company will offer a range of applications. These apps also reflect, to some extent, the organization of the company. However, in the eyes of users they are a company and they should only have one product. Similarly, this trend is happening on the desktop Web. Aggregation has become a technology trend, and the aggregation embodied in the front end is microservitization architecture.
Compatible legacy systems
So, at this point, we need to use new technology, new architecture, to accommodate and accommodate these old applications. And front-end micro service, just fit people want this selling point bai.
What do you say?