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

[Music] hello perhaps you are wondering why i'm starting here with the picture of a scooter well let me explain this is the high school i attended back then and when we started high school we were really looking forward to finally become 16 because with 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 scooter and for some reason the mobit people have not been best friends with the scooter people we are discussing really hard about what is better a moped or a scooter 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 scooter was to belong to this or to that group to belong to the mobet group or to belong to this kuta 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 front-end architectures because microphone microfrondants have been heavily discussed in the last month and they come with a lot of consequences not all of them are great they are a huge of disadvantages when it comes to microfluidics well if you are wondering what micro front ends 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 microfront 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 microfronted 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 manfred i am a trainer and consultant for angola i'm focusing on angular for enterprise scale applications i'm 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 microfront 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 deadalus healthcare formerly they have been known as akfa healthcare they sit here in europe and they are implementing a huge hospital information system well honestly i know akfa since i'm a little boy because uh they have produced those audio cassettes and they really had a lot of audio cassettes from the akfa band but nowadays this division is implementing a health care solution a hospital information system and you can imagine if you implement a huge product or even a product suit 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 bigger application and that means all those themes can work somehow in isolation they can work in an antarctic 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 sent out my questionnaire to estadef 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 re-implementing their e-banking system and you know for us customers an e-banking system really looks cute there is one dial that is telling me that i'm broke there is another dial that is telling me that i won't get another credit so it's really cute from ours perspective but from there's perspective it is a huge system each of those styles has some logic into it that comes from individual teams uh individual teams taking care of individual business domains one team is specialized into account management another team is specialized in the loans another d might be specialized into stocks and somehow they need to bring together all the code from these themes in one tiny cute front end that's why they are going with microfrontence by the way they are using microphone dance since quite a long time they started using this architectural approach in times where there was not a term like micros the term microfrondance was only coined a bit later but they started with its 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 the need to bring together several pieces of informations from several domains about one and very one customer 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 an information system for hospitals but there are they are only one hr team they are about ten people give or take and so we figured that splitting one application into several parts would be an overkill here because there is just one hl team it would be an overkill if they needed to deal with several tiny microphones but what they are doing and i think this is very clever they are splitting their source code within a monorepo according to their business domains and this makes sure that the software code of one business domain is not intermingled with the code of another business domain for this they are using an axe by the way an exponent reapers well i have asked them why did you decide for micros and nearly all of them told me first and foremost because we have a huge product or even a product suit and we want to scale our teams we want that one team can work in isolation on one business domain the teams shall not block each other they can work like an agile very flexible team 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 out technologies if some technology becomes a legacy technology and some other people told me they 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 themes that can work in those changing requirements very quickly but there are also some consequences all of the themes i interviewed told me that the biggest consequence the biggest negative consequent was the effort for building a meter framework a meet the framework is a tiny framework that is orchestrating all your micro frontends in your browser window 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 need it because they want to decrease their overall bundle size they do not want to load angular five times just because they have five micro frontends they just want to load angular once and only once 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 feel has to do with a 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 shortly 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 this second part i want to show you how to implement something like a micro front end architecture and obviously there are several options for this here i want to show you the most modern option which is web pack 5 module federation and as you will see it really deals nicely with all those disadvantages we have discussed before basically the idea of module 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 webpack which is also used by the cli all those modern bundling solutions assume that all their source code is known at compildime even the lazy parts need to be known at compile time everything is compiled together everything is optimized together think 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 front end we want to load something at runtime that we didn't know back then at compildon we want to implement the individual micro frontends in isolation we want to deploy them separately and we just want to load the newest version or a configured version at runtime into our and this is now solved by webpack 5 module federation for this module federation introduces two roles the first role is the host in my case it's the micro front and shell that loads all the micro front ends and the second row is the so called remote which is the micro front end in our case you can configure both of them for instance you can say well this shell gets a url that is called mfe1 and when we are importing something from this url we want to point over there to this micro front end a separately compiled and deployed micro front end and by the way over there it's also called mf evo that means here you can define an alias or as i did none allies if you want to put it that way over there in the micro front end you can expose files you can expose a file with an iv component or an a 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 angular's perspective there is nothing special with this from angular's perspective here we are just using lazy loading angular does not even know that that back underneath the covers is doing the heavy lifting that webpack is taking care of loading stuff from over there that means we can use angular as always because angular doesn't know about micro foundants and that means we don't need to go with a meter framework which was one of the biggest disadvantages i have presented before building a meet the framework for orchestrating your micro front ends no forget it with this solution everything you need is lazy loading everything you need is not love but a dynamic input also module federation allows you to share libraries you could say well i'm using angular here i'm 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 then do 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 a new major version you know one can introduce breaking changes but the thing is when it comes to sharing code module federation is very flexible how can we use this together with angular well you need this tiny cli plugin you can enshred 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 you can ensure surf your solution and everything should be fine now let me show you a tiny demonstration for this i'm always saying module 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 here in this example here i have a shell this is my micro front and shell and as you see here it runs on localhost 5000 and here i have my microphone and you can [Music] see it by looking at the dashed lines it has those red dashed lines around it and it runs on low close 3000 and now using different ports different origins is not their prerequisite here but in this case it is proving that i am using separately compiled and deployed microfrontends and the best of this is when clicking here the micro front end 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 angular's perspective this is really just like lazy loading i have a lazy route here and i'm telling angular to load something from that url and angular does not know that this url is mapped using the webpack 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 angular applications plus the backpack configuration i've talked about before okay let me come to a conclusion so we have seen that micro front ends 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 very situation we have also seen that they are first and foremost for scaling teams you want to scale your application across several themes that can work in isolation that can work in an artic way that can deploy separately and we have seen that module federation is a nice new solution that is quite unobtrusive and that really solves the issues we've talked about in a very nice way issues like don'ts needing a meet the framework issues like sharing code at runtime to decrease the amount of bytes that go over the wire and there is one last thing i want you to remember namely please remember the story with the scooters and the mopeds because this story tells you that there is not the best option in general it tells you that you always need to evaluate uh 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 blog articles about all this stuff so if you want to go more into death please find all this material in my blog and if you have any questions reach out on twitter thanks for having me and have a nice day

Channel: ng-conf

Views: 1,747

Rating: 5 out of 5

Keywords: angular, angularjs, javascript, ngconf, ng-conf, programming, angular conference, ng conference, angular javascript, angular tutorial, Javascript Tutorial, Programming Tutorial, Computer Programming, Google Angular, Google Programming

Id: 5QfcT1BZbZA

Length: 21min 25sec (1285 seconds)

Published: Fri Sep 03 2021