Domains, Deployment Monolith, and Micro frontends.

SafeValue must use [property]=binding: So, you are that happy demiurge who has identified the subdomains for his system. You are faced with the question of what to do next. At this fork in the road, you have two paths: either implementing all in a large application or providing a little separate application for each subdomain. In other words, you have to choose the deployment monolith or micro frontend's realization. Each of them has its benefits; let's check them in more detail. (see http://g.co/ng/security#xss)

SafeValue must use [property]=binding: If you are grabbing different domains and putting them into a single integrated solution, you are getting a Deployment Monolith: By choosing this way, you have to create a consistent UI and optimize bundles by compiling everything together. Thus, you'll create a large application with a lot of coupling inside, which can be pretty complex and hard to change. In addition, this approach, obviously, require precise coordination between a specific subdomain team and other subdomains team to prevent mistakes in the overall architecture and policy for dependencies. A lot of smartypants may say this is great - you may reuse parts of other domains - but it's not true. It will lead to higher coupling; that we try to avoid. The higher coupling is the reason for the decrease in maintainability and the system's reliability as a whole. So you would better not give in to this temptation. There are free tools like Nrwl's Nx to avoid situations like this. Nx will show the access restrictions between the parts of your monorepo. It will help you to keep weak coupling in your architecture. (see http://g.co/ng/security#xss)

SafeValue must use [property]=binding: Keeping in mind our main idea to decouple our system as far as possible, we can keep slicing it into smaller applications. It will lead to the creation of more self-sufficient, autarkic teams and bunches of separately deployable applications. Here we come to a paradox at first glance conclusion: the more tiny applications there are, the lower system complexity. But looking closely, you'll find out that's the way it is. When you are seeking the ideal level of isolation between your subdomains and their teams, you may insert each subdomain into an individual mono repository: That's what we call Micro Frontends. Thus, you untied the hands of every individual team to be as autarkic, self-sufficient as possible. Each of them can choose an architectural style, technology stack and decide when rhythm to update to newer framework versions. They are free to choose the best way based on the given requirements of its subdomain. It is a long play. In perspective, it allows for the upcoming frameworks to be much easier to implement in an existing system and create a new domain. Sure, you have to reserve some resources. And here is the catch; you have to resolve the shipping shared libraries issue via npm. The versioning, in this case, maybe the cause of the conflict version. (see http://g.co/ng/security#xss)

SafeValue must use [property]=binding: The best example of the UI conception with hyperlinks is Microsoft Office. Each domain has as much independence as it can. We see the weak coupling realized via hyperlinks. Each domain can be renovated, upgraded, and even deleted from Microsoft Office without any significant consequences for other domains. We expect deep interaction between domains on the one hand and full autonomy on the other, and we get the expected. Excel sheets can be integrated into the Word document and vice versa. The PowerPoint presentation can be incorporated into any of the above domains. Moreover, if the future will require adding additional domains, it can be easily implemented. What is good in this approach?

• It is simple and easy;
• the usage of SPA frameworks as it was conceived;
• each domain gets its optimized bundle.

And what is bad?

• The switching between domains lead to losing state;
• another application must be loaded;
• the universal design system required.

As we noticed before, everything has to be paid for. (see http://g.co/ng/security#xss)

SafeValue must use [property]=binding: You may choose another approach whose essence is to create a shell that will load other single-page applications on-demand: The red border in the screenshot shows micro frontends loaded by the shell into its working area. Actually, the micro frontend bundles are loaded on demand. Then the shell appends an element for the micro frontend’s root element. What is good in this approach?

• isolation - iframes separate micro frontends preventing interaction, which is convenient to integrate third sides applications;
• integration of legacy systems is allowed and simplified;
• an integrated solution is provided immediately with a complete set of various micro frontends;
• the state is not losing when moving between domains.

And what is bad?

• common usage leads to the use of significant resources because each micro frontend gets its own copy of Angular and the other frameworks, which increase bundle size dramatically;
• the implementation of the infrastructure code to load micro frontends is required;
• the universal design system required.

(see http://g.co/ng/security#xss)

SafeValue must use [property]=binding: As usual, the choice is yours. There is no absolute bad or absolute good solution. Good optimization is the only way to create a good working application. It all depends on the circumstances, architectural goals, and requirements of your project. (see http://g.co/ng/security#xss)