Video details

Federated Angular: Why and How?| Manfred Steyer | ng-conf 2021

Angular
09.02.2021
English

The much-discussed Micro-Frontends have challenges and trade-offs. Many wonder whether their benefits would pay off for their projects and how to implement them. This session sheds some light on the matter.
We start by exploring several real-world use cases I have helped plan and implement in recent years. They are from different industries: Finance and accounting, banking, and insurance. We also discuss projects where we deliberately decided against Micro-Frontends. With this background, we set out reasons to use, or not use, this new architectural style.
In the second part we look at implementation strategies such as Module Federation, a game-changer for Micro-Frontends even beyond SPA. After seeing how to integrate it with Angular and the CLI, we discuss consequences, trade-offs, and alternatives.
By the end, it will be clear whether Micro-Frontends are a good choice for your project and how to implement them. ng-conf is a multi-day Angular conference focused on delivering the highest quality training in the Angular JavaScript framework. 1000's of developers from across the globe join together to attend talks and workshops by the Angular team and other community experts.
Follow us on twitter https://twitter.com/ngconf​
Official Website: https://www.ng-conf.org/

Transcript

Hello. Perhaps you're wondering why I'm starting here with the picture of a scooter. Then let me explain. This is the high school I attended back then, and when we started high school, we were really looking for about to finally become 16 because we've 16. Back then we have been allowed to drive a tiny motorcycle. We are only allowed to drive a car with 18 here in Europe, but with 16, we are allowed to drive a tiny motorcycle. And when it comes to this, there are two huge options. One option is to go with a more traditional Moped, and another option is to go with a cute and for some reason, the Moped people have not been best friends with the Scooter people. We are discussing really hard about what is Beta, a Moped or Escuda. And then looking back to this somehow this discussion was ridiculous because at the end of the day, there is not a thing like the best option. Everything comes with advantages and with disadvantages. And you need to evaluate in the context of your current situation. Well, honestly, the biggest advantage of having a motorcycle or a Scot was to belong to peace or to that group, to belong to the Moped group or to belong to this creative group. But in general, I would say this is always the case when we are talking about doing a decision, it's always about consequences in your very situation. And this really reminds me to software architecture and especially to micro Runden architectures, because micro Fronan have been heavily discussed in the last month, and they come with a lot of consequences. Not all of them are great. There are a huge of disadvantages when it comes to micro. Well, if you are wondering what micro frontends are about, basically, they are about not writing a huge application. Instead of this, you write several tiny, less complex applications you need to integrate into each other. And this is what this talk is about. In this talk, I will show you why some of my customers decided for micro round and architectures. This is also where I will point out some of the disadvantages, some of the consequences. And then I want to show you how to implement a micro rounded architecture with angle. Of course, there are several options. I will focus on a very modern option, which is called Module Federation. But first of all, let me introduce myself. I am on Red. I am a train and consultant for Angular and focusing on Angular for enterprise scale applications. I am quite connected to the Angular community and I live in Austria. Besides this, I do a lot of stuff in Germany and sometimes I'm working together with people in other countries. Okay, let's get started with the first topic I have prepared for you. It's about the why why have my customers used micro front and architectures in the past? Well, to answer this question, I gave them some questionnaires and they filled it out and here is the conclusion of it. One of my customers is Dedalus Healthcare. Formally, they have been known as AXA Healthcare. They sit here in Europe and they are implementing a huge hospital information system. Well, honestly, I am no Agfa since I am a little boy because they have produced those audio cossets and they really had a lot of audio cassettes from the ACA band. But nowadays this division is implementing a healthcare solution, a hospital information system. And you can imagine if you implement a huge product or even a product suite for a hospital. You have a lot of business domains, business domains. For that, you need several themes where each team is specialized in at least one of those domains. That's why they decided for Micro Frontends. Each team is producing code for one of those specialist domains and then everything is integrated into a big application and that means all those teams can work somehow in isolation. They can work in an AR Darci way without the need to wait for other teams before they can deploy. For instance, this brings back a lot of activity. Another customer I send out my questionnaire do is Start Dev is also an European company. As you see here, they are quite huge and they are specialized in the software for lawyers and for accountants. And one of their biggest products is their payroll account and solution for their payroll accounting solution. They have about 80 people and somehow you need to organize such a huge system. And that's why they decided for Micro Frontends when they started with the new version of their product. The new version that is using angle. Of course, another customer I've interviewed is a huge bank. I'm not allowed to tell the name or to show a screenshot, but what they are doing, basically is they are currently reimplementing their banking system and for us customers, an e banking system really looks cute. There is one tile that is telling me that I broke. There is another dial that is telling me that I won't get another credit. So it's really cute from our perspective, but from their perspective, it is a huge system. Each of those tiles has some logic into it that comes from individual themes. Individual teams taking care of individual business domains. One team is specialized into account management and other teams is specialized into loans. Another team might be specialized into stocks and somehow they need to bring together all the code from the teams in one tiny huge frontend. That's why they are going with microphones. By the way, they are using Micro Frontend since quite a long time they started using this architectural approach in times where there was not a term like microphone. The turn micro frontends was only coined a bit later, but they started with it before. It was a thing out of their business needs. How cool is that? Another huge bank is doing similar things for their customer relationship management system. Also here they need to bring together several pieces of information from several domains about one and varied one custom and last, but not least, there is another customer of mine that is called Quality Bytes. They are located in Germany and they are a small business. They are also implementing information system for hospitals, but they are only one HLD. They are about ten people give or take. And so we figured that splitting one application into several bots would be an overkill here because there is just one HLD. It would be an overkill if they needed to deal with several tiny microphone. But what they are doing. And I think this is very clear that they are splitting their source code within a monorepo according to their business domains and just make sure that the software code of one business domain is not in Deming with the code of another business domain. For this, they are using an X, by the way, an Expo repos. Well, I've asked them, why did you decide for micro randoms? And nearly all of them told me first and foremost, because we have a huge product or even a products out, and we want to scale our teams. We want that one team can work in isolation on one business domain. The team shall not block each other. They can work like an a child. Very flexibility. And at the end of the day, this is all about themes and business domains, as you see here. Well, some of them also told me they want to be capable of switching our technologies if some technology becomes a legacy technology. And some other people told me to have a lot of changes regarding their requirements because of the law, in the case of hospitals and payroll accounting, for instance. And so they need to have tiny, flexible teams that can work in those changing requirements very quickly. But there are also some consequences. All of the teams I interviewed told me that the biggest consequence, the biggest negative consequence was the effort for building a meter framework. A meta framework is a tiny framework that is all has trading all your micro front ends in your Prosoviet for this. They needed to implement custom code, and somehow that was difficult for them. Also, they told me that sharing source code at runtime is quite difficult, but they needed because they want to decrease their overall bundle size. They do not want to load angle or five times just because they have five microphones. They just want to load angular one and only ones, and this means they need to share the code of Angular at Runtime, which was not easy until some months ago. Also, some companies told me that achieving a common look and feel was difficult. Well, while this common look and field has to do their design systems, the former two options have to do with technical aspects. And for the rest of this presentation. I want to stick with those two technical aspects. Please keep those two things in mind. I will come back to them very, Sally, very shortly, because I only have 20 minutes in general. Okay, this was the first part. Now let's proceed with the second part. In the second part, I want to show you how to implement something like a micro run an architecture. And obviously there are several options for this here. I want to show you the most modern option, which is backpack five module Federation. And as you will see, it really deals nicely with all those disadvantages we have discussed before. Basically, the idea of mutual Federation is being capable of Loading something from another domain. And perhaps you were saying now, well, that cannot be that difficult because we have dynamic imports. So why not use and dynamic import to load something from over there? Well, the thing is, in theory, this really works perfectly in theory. In practice, this does not work at all because of how all the current Bundling solutions work. Bundling solutions like that back, which is also used by the CLI. All those modern Bundling solutions, assume that all the source code is known as compile time. Even the lazy parts need to be known at compile time. Everything is compiled together, everything is optimized together thing on tree shaking, for instance, and then everything is cut into chunks for lazy Loading. But this is too late because when it comes to micro frontend, we want to load something at runtime that we didn't know back then at compile on. We want to implement the individual micro front ends in isolation. We want to deploy them separately. And we just want to load the newest version or configured version at runtime into Asian. And this is now solved by that back five Marshal Federation for this Marshal Federation introduces two roles. The first row is the host. In my case, it's the microphone, then shell that loads all the microphones. And the second role is the Socalled remote, which is the micro from an in Haiti. You can configure both of them. For instance, you can say, well, this shell gets a URL that is called MF one, and then we are importing something from this URL. We want the point over there to this micro front, a separately compiled and deployed micro Romans. And by the way, over there, it's also called Ms Eva. That means here you can define an alias or as I did non allow us. If you want to put it that way over there in the micro round, then you can expose files. You can expose a file with an IB component or an angular module or even a function. And now something beautiful happens. I guarantee you you will love it. Now you can use just a dynamic import to point over there. That means from Angelos perspective, there is nothing special about this from angular perspective. Here we are just using lazy Loading. Angular does not even know that bat back underneath the covers is doing the heavy lifting that backpack is taking care of Loading stuff from over there. That means we can use Angular as always, because Angela doesn't know about micro randoms, and that means we don't need to go with a meat of framework, which was one of the biggest disadvantages I have presented before building a meat of framework for orchestrating your microphone and snow. Forget it with this solution. Everything you need is lazy. Loading. Everything you need is not laugh, but as dynamic Ember. Also, Marshall Federation allows you to share libraries. You could say no, I'm using Angular here and using Angular there. Let's don't load it twice. Just load it once and let's share it. This was the second disadvantage I have presented before. Sharing code was really difficult in the past. Nowadays. Is it's as easy as configuring such an array? You can even configure them to share source code. You can say share it always or just share it. If both of them are using the same major version or don't look at the major version at all. Just go with the highest version, which might be an issue because with the new major version, you know, one can introduce breaking changes, but the thing is, when it comes to sharing code, Marshall Federation is very flexible. How can we use this together with Angular? Well, you need this tiny CLI plug in. You can need it. Then you need to adjust a generated configuration. That means you don't need to learn this configuration by heart. This plugin is generating it for you. You just need to fill in placeholders and then we can and serve your solution and everything should be fine. Now let me show you a tiny demonstration for this. I'm always saying Marshal Federation is a bit like the 1980s. You need to experience them in order to know what they are about. So let's have a look at that tiny example in this example here I have a shell. This is my micro front and shell. And as you see here, it runs on Loki Host 5000. And here I have my micro round. You can see it by looking at the dashed lines. It has those red dashed lines around it and it runs on local three dozen and no. Using different poets, different or chains is not the prerequisite, but in this case it is proving that I'm using separately compiled and deployed microphone. And the best of this is when clicking here. The micro front ends from over there from the different origin is directly loaded into my application. And if we look into the source code of this, we will see from Angela perspective, it is really just like lazy Loading. I have a lazy route here and I'm telling Angola to load something from that. Url and Angular does not know that this URL is mapped using the backpack configuration mapped to point over there to a child module of a separately compiled application. It's really as easy as that. At the end of the day, you have traditional angle applications, plus the backpack configuration I've talked about before. Okay, let me come to a conclusion. So we have seen that micro round ants are not the free lunch. They come with consequences, and you really have to evaluate if the disadvantages are smaller than the advantages in your various situations. They have also seen that they are first and foremost for scathing teams. You want to scale your application across several teams that can work in isolation, that can work in a dark way, that can deploy separately. And we have seen that mutual Federation is a nice new solution that is quite unobstrusive, and that really solves the issues we've talked about in a very nice way. Issues like don't needing a mite framework, issues like sharing code at runtime to decrease the amount of bytes that go over double. And there is one last thing I want you to remember. Namely, please remember the story with the Scooters and the moments, because this story tells you that there is not the best option in general, it tells you that you always need to evaluate in the context of your very situation. Please keep this in mind. This is what software architecture is about, and perhaps this is even what whole life is about. Okay, so thanks for having me here. You find my contact data. Perhaps I have several block Adickes about all this stuff. So if you want to go more into depth, please find all this material in my block. And if you have any questions, reach out on Twitter. Thanks for having me and has a nice day.