Remember to subscribe to our channel! https://ng-poland.pl https://js-poland.pl https://workshopfest.dev
Shai Reznik (TestAngular.com) - Isolated vs integrated testing
Manfred Steyer (SoftwareArchitekt.at) - The Microfrontend Revolution: Using Webpack 5 Module Federation with Angular
We're kind of starting life here. Got to make sure to meet this. This site. And we're alive. I love my life. We go, Okay. Hello. Hello, everybody. Hello, everybody. We can start so ski. Are you ready to rock and roll? Of course. So hairy. Aloha. I see it. Uphill battle, Brusca Terminator. I don't look like a Terminator right now, but you know, positively, I have the same amount of energy. So, you know, just a, as usual, different place. I think this is an ongoing theme right now to just give you some sunshine from Hawaii and a little bit of spirit of aloha. Rafael, what are you playing? Alex is here. Hey, Alex. Hey, Alex. Fayre. Oh, hey, Lars. We have 20 people. No. Yes, sir. Oh, are you? Oh, it's awful. It's awesome to see everyone as like. Yeah. Raffo just hit me up. Let's let's alert and play and have fun with you. Together. I love it. So everyone's still alive. I'm excited. Welcome, everyone. Welcome. Welcome, welcome. And I love her like they do in Hawaii, I guess. So hopefully you guys are excited as I am to start and learn from. As usual, we have great speakers. They're passionate, as you guys are. And they are the experts in their fields. And it's just fun to hang out. I think that's the most important thing. Having fun with it. Learn and just have a good time while, you know, hanging out in this channel and. Yeah. So, again, welcome. And get excited because we have two speakers. It's a shy and month. And then you all know them. And you know, without chatting too much anymore, I'm giving up too shy I think. Shy. Are you ready? Yes. All right. Ben Walker and started up. Let's, uh, let's get this show on the road. Look. Wow, nice. I didn't bring. I have also Sandefer. And stuff like that. And we'll we'd say, well, see our way if we need to use them. Let me share my screen with a quick and let's say let's say. Yes. This one, I believe, the. Cool. Right. This one. Yeah. No. Yes, no. Yes, OK. All right. Can you can you see my screen? Yeah. OK. So this lecture is about isolated, ever integrated versus isolated testing, I always mess up like they're integrate. OK. Doesn't it doesn't matter. Their material does. So let's start. Let's see if everything OK. If I can move it. No. Yes. OK, also, OK. So first of all, my name is Chai Reznik, and this is a picture actually of my daughter and she she was photographed with her favorite, like Ki Cho. But actually, I wanted to be instead of her. So I Photoshopped myself there because I really loved them as well. So, yeah, this is a this is me. I have a website called Hirers I. Oh, and recently we focused everything on testing. So f test angular dot com and we're the best play a place in the entire universe to learn about angular testing. OK. I am by the way and like it happens to be that in these these days we are running a free workshop. You can go to the workshop on hirers dot link slash road map and it ends next week. So if you sign up now, you will get all the lessons and stuff while it's online. So make sure you do that and I will share more details about it later. Cool. So let's start. Let me drink first. Mm hmm. OK. So why this stock? Why did I create this stock? I thought it's money will be beneficial to know the context. OK. So integrate. So the reason I did it is because in recent years I've read a lot about the fact that, you know, I read a lot blog posts, a lot of Bulc blog posts and a lot of intensive lectures that says that integration tester is everything you'll ever need. And we don't need isolation and more. And you know, Mark Sara, terrible. And you should avoid them at all costs. And, you know, these type of things. And actually, when I looked at it, I was like, really? Because I actually have a different experience with. With MOCs. I actually love them. And this talk was originally, I wanted to call it standing up for testing in isolation, but I decided to expand its context and to learn more or to teach more about an isolated versus integrating stuff like that. OK, so disclaimer upfront, I will tell you, you need both. Okay. It's not just about isolated testing or in just about integrated testing. You actually need both. But the amount matters. OK. So we need to figure out which test. Right. In which scenario or which can be, you know, a bit confusing sometimes. OK. So I aim to provide in this doc, you know, the map of the different terms and in the end I will share more stuff. So let's talk about the agenda. OK. We'll talk about the terms and the pros and cons to isolated versus integrated for both types of tasks. And also when to use what and water go. OK, well. Sorry, I forgot to rush. I forgot to. OK, I forgot to stop the notification, so we just ignore them. OK, cool. So unit and unit and integration, are these the right terms? I think they are overloaded terms because they actually mean different things, because I do like to ask, what are your tests? If you're Testico use, you need or integration is like asking if you check your bank balance balance by using a hamster or communism. No, there are two different nonrelated stuff. Okay. And let's see, because, you know, when I look at test, when I first started learning about us, these were the terms that I that got me confused. And I learned through the years about like more dimensions to test our testing and more aspects. So I decided to teach about testing and divided into three aspects or dimensions. OK. So let's let's show them. So the first one is scope. OK. Or how many actions. Am I testing at once. Is it like one action like method call or click of about 10 or several. And the second one is boundaries. Where to draw the line. Like how many things to actually test in one go in one test and. Thank you. OK. I guess so admit. OK, so call another notification. Hello, Manfred. I know they away is shot out for a video. We don't look at you now. You're it. Yeah. You're ruining the show. I love man. OK. And the third one, a subject. Why do I need to create like. Is it a class? Is it like. Don't I need to like a dom. Do I need to like. Just import the functions or this the subject under test. And this is the third dimension. So when we talk about like like let's stake unit for example. OK. We talk about Unit Watari. Like which dimension are we talking about. Actually unit holds inside of it like two dimensions. First of all, like, why do I need to create. Usually we refer to unit as like the class or the function or something like that. So this is the subject dimension. And also like how many actions at once? Usually people talk about like a testing function. They test it like. Once, you know. So this like also refers to the scope or relates to the scope. And integration is all about the boundaries. OK. So like, where do you draw the line? So you can see that these terms are not really, you know, are in the same dimensions when we talk about tests. And that's why. And by the way, of something about integration test. OK, integration. Does that like the right object oriented software guided by test book? The Goose book talks about the integration test as a test. That test that your code works better. It walks like walks in combination with the code that you cannot change that code that like some other team world or some other external library road. So this is like the integration test definition by this book. And that's why a better term. OK. Because, you know, usually integration. You know, it's something, general. People use it to describe these type of things. But also like testing your code with your code. So that's why a better or like more accurate definition is like maybe an integrated test. That's why it's integrated versus isolated. So just to differentiate the goose definition from, like the more general use case. And what, as you can see, integrated talks about the boundaries and because destock is more about the boundaries. OK. We're focused on that. We also unique is not relevant to this stuff. That's why I were blessed with isolated. And this is the isolated versus integrated. Right. So, by the way, if you want one to learn more about, like the dimensioned the watcher that I mentioned before, I go more deep into the different dimensions. Or a microphone so you can go there and, you know, it's it's up for this weekend. As I said before. OK. OK. Sorry, I don't have time for that. OK, so there's definitions. Let's talk about. Let's talk about like what is integrated versus isolate, like the terms themselves. OK, so integrated, we said we're testing multiple parts together. OK. And isolated. We focus on only one part. It can be a class. It can be a function. But usually in angular. We focus on classes. Right. Component or a service or something like that. And we make sure when we write isolated tests, we fake all of the dependencies that we inject into this class. So that way we can focus on one thing. This is isolated in isolated tests. And now let's talk about the benefit. So let's talk about the benefits of integrated tests. So the first benefit is connectivity. We can actually test the different parts. Works good together. Because with it, does the connectivity points between them. That's actually the method that we call the other dependency. Actually, you know, don't. It doesn't break and stuff like that. So this is this is the connectivity. The second thing is configuration. So imagine like you import, you forgot to import like an energy module or, you know, you change the base. Eurail of your HTP calls this new one catch in and integrate. And this you will catch in an integrated test. Most of the time. OK. So these are the benefits that I see to integrate a test. But now let's talk about the issues. And the issues are usually issues that you won't see in like wrote post or no talks and stuff like that when they prey's integrated tests. But I wanted to stay, you know, stand up for isolation test and to show you all the issues. And later, we'll talk about the issues of isolators as well. OK, so sorry about that. So now let's talk about the issues. OK. So the first issue is unclear boundaries, as we say. As we said, you know, we test the content. We test multiple parts together. Hey, there is. Know we test multiple parts together and it's unclear where the boundary is. You know, where we draw the boundaries. So let's say we have a component and service in which depends on another service, which depends on the server, you know, where where you draw the line when you say to someone else. Okay, I'm gonna write an integrated test. Should I, like, mock everything from the service and beyond or just the server or, you know, not mock, not fake every anything. And this will be like an end to end test. Okay. Where to draw the line? And usually when you talk about real applications, we don't have we don't have that like this simple, you know, three classes, no app. We usually have more dependencies which has Morde, which have more dependencies and cross dependencies. And usually it's more like this. And this is like, you know, a small app compared to like real a real app. But for the sake of this dog will focus on like this scenario. OK. So you have unclear boundaries. We'll do a test here. No, Dwight. This combination or this combination or you know, this is like a problem. OK. Why do we want. OK. I will do that later. Sorry. Cool. So this is the first problem. The second problem is it takes longer to run. Right. Because usually, you know, it depends on the dance. If you have a server in it to, you know, load the surge does with a browser and to load the browser. And also you have much more code to run. So it takes longer, especially if you test everything. Also, you have longer test setup. You need to write more setup code for a test because usually we don't deal only with, you know, when you integrate it as well. That's like a component, for example. It does other subcomponents and they have services do. And, you know, we need to now, maybe even if you fake those services, you need to set it up, you know, in your like before you before each or before the actual test run, before you run the action. This leads to a much bigger test here. OK, cool. So this is. Yeah, this is another problem. OK? And also it breaks more often. OK. Because, you know, we now have more stuff that can fail and can break your test, which leads to another problem, which is which is the you know, if if you have won the multi sorry, the multi coverage problem, I see notification ever. So I lose my focus. Sorry. So the multi coverage problem. What is the mood? The multi coverage problem. This is the problem when you have an integrated test. You know, our multiple tests that both rely on the same dependency and and this defensive like has an error or a bug. Now, both tasks or multiple tests are failing and it's hard to know the root cause and it takes more time to do. But. OK. I didn't forget. Sorry. OK. So this is the multi coverage problem, and our problem or issue is it's hard to trace down bugs. So if this test, again, this test fail, which one of these dependencies caused it, it will take us more time to figure this out. Also, it's harder to cover edge cases, meaning you have multiple path that your app can go through. Right. When you test it. So we need to set up something. So what do you use? You know what you set up to set up all the possible use cases? No. If this has an error or what if, you know, it goes to there else, you know, clause. And what if these returns and error, you know, you have all these like multiples code path that your test can go through. And it's hard to. Harder to cover those because it, you know, exponentially grows your testing code if you want to actually cover all these test cases. And yeah, so. And as we said, usually we have we're dealt with. We're dealing with more like, you know, much bigger apps than that. So. And that causes us to. So. So. Yeah. So usually we focus on integrate. That's on their happy path. OK, what, what like makes their component render or to show the list of items and stuff like that. And we really ignore all the possible use cases that could cause this list not render. OK. And this gives us a false sense of coverage. OK. No. To people who say OK. Only Right. Integrated it as it will give you the confidence that you need to know. And they are also promote the only happy, you know, happy path tests. You don't have really like don't have true confidence because you don. You're not covering probably all the possible combinations, so it's not that that integrated is give you actually the coverage that you need. So this is one myth that I want to expose, Moak, and our issue is Luser Ecodesign. So when I write a test for this likes structure of dependencies, I can actually have like not five services. I can actually have like one like two large services instead. And the test will still pass. So nothing really puts pressure on my code design to, you know, separate things into smaller parts with singer responsibilities and such and such. And that leads to Jane files. This, ladies and gentlemen, is called job security. OK. This is a real file screenshot from a project that I did consulting to. And yeah. So and I need to fix stuff there. So, yeah, this what happens when you either don't have that. So you have only integrated and this leads to a more messy code as you can see. OK, cool. So. This loser code, as I know, but the test doesn't like show shouted you that need to break your subject on the test into more units. It's actually on mute. OK. So nobody actually shows you the signals. Cool. Now, let's talk about isolated this benefits. As a comparison, so we'll go through it quickly because they are the opposite of the, you know, limitation, but will just to show show it in a different way. What da. Sorry. Okay, isolate as benefits. Cool. So the first benefits. The benefit, thorium districted is clear boundaries. OK. Now we know that we fake everything. So we are focusing only on one subject under a test. And it's easy to see. Also, it's faster, much faster rounds. Really, really quick. Less setup goes. Because again, we only have one thing to setup. No more the coverage problem. If one thing fail the test fail. If another thing fail, its test will fail. So we don't have the multi coverage problem. Also, it's easier to trace bugs. Okay. Because you can see clearly where the bug is. And it's easier to cover edge cases because we only deal with the dependencies that the first level dependencies of our subject under test. So if we want to simulate what happens if an error comes back, we can do it easily. OK. So, you know, you're doing great. Love you. And yes, you know, we're in a talk and it's not like, uh. So why'd you send me an OK, so not now. OK, well. We'll talk about it later. OK, cool. Thanks. And so I'm married. OK. Sorry about the threshold. I should put a reminder to close the notification next time. OK. Cool, easier to cover edge cases. OK. We saw how it's easier. And also add recommendation. OK. So we have sort of of life documentation for our units under desks when we write. Isolated as it's much clear to see what this particular subject under desk is doing. OK. And also it leads to better Ecodesign because now if our service grow bigger or subject grows bigger. Now the test will, you know, scream at us, hey, we have too much setup code. You have two months things you need to separate eight and you know, which will lead you to break things into smaller because it will be painful to write this test. And also, it leads to more like files and methods of like that has single responsibility, which is great and much more clean. Now let's talk about its issues. So, again, you know, you it's harder to catch config bugs. OK. So you want catch like if you change a base, you're or you know, we did an import and more a module or stuff like that. So it 's. And it's not isolette that you won't catch it with an isolated test. And also you have to write more tests. Right. For each thing. But I argue that you don't really if if you needed to write the same test or to cover the same path in an integrated in integrate this, you'd have to write much more like a test in order to cover that. So you actually write let right less test and get more coverage of the different path. But some say some see say it as a problem as well. So I just want to argue against it. And U. U. S cannot catch collaboration bugs. So, for example, if you fake everything. You won't catch it. You know, you're one if if you will change the real service behind like the fake one that you like to mock, you probably won't catch it. So if no, this changes and this changes, you won't catch it. And you could have a bug in your collaboration. So if you call something weird, like a configuration object and you'd expect it true instead of false, you won't see it in an isolated way. There is a way to to, you know, to cover that without creating an integrated test, which is like covered with collaboration and contract tests, which I call symmetric testing. And I teach about that as well. But. This is also hard to, you know, to do for some use cases manually, so I'm working on an open source library behind the scenes that might do it automatically. But we'll see about that in the future. Sorry. Go. So which one do you choose when to use what? You know what? I promise you in the agenda. Let's talk about that. So for small apps, I say just right. Integrated. Just integrated. This are fine because, you know, it's small, you know. You don't have a lot of code best to cover. So we could get all the benefits you need. So it's good for like micro services or maybe microphone front ends, although you will need the connectivity between those small apps. You need to cover them as well. So you will have this problem to tackle about four small apps. I think that just integrated is fine, but for medium to large app, I say, you know, use integrated as just for like a smoke test, which, you know, test all all of your app together, like an end to end and covers all like the critical points in your in your app. And also for special use cases when you need an integrated like to integrate multiple parts. But those should be rare. And for the rest. Use isolated test and symmetric testing and stuff like that. So yeah, this is like I said, I cover, you know, the outer boundaries or dimensions, Maura, in more depth in this free road trip. So join in this link and that's it for me. Thank you very much. I hope I wasn't on mute this whole time, but yeah, that's it. So I will say so much, Trinity. You know. I paid by. And applause. Can you hear me say, oh, I cannot hear you. You're who you've been talking, OK? Now I can hear you OK? Yeah. Because you all smiled at all the don. Oh, Henry, Peter. God damn it. I knew it. I knew it, man. Thank you so much for this great presentation. A lot of valuable stuff. I totally agree. We we should do the isolate that last forever thing. So. Yeah. Thank you. Appreciate it. Thank you so much, man. See you in the chair. I was in the chat. Now I would Ladd do the stop video and you will. I will disappear. Ready. One, two, three. Wow. Thank you. OK. Manfred, where it is, Manfred? Yeah. Hi. Hello. How are you. Yeah, fine thanks. OK, so our next speaker is the. Great dust. Angela Architect. Manfred's stay here. So thanks for having me. It's really a pleasure to speak here at this event. And I brought some stuff with me. Perhaps I can even switch to it. Here we go. So this will be about Molcho Federation, which is quite a new topic. And if you ask me, it be leads to a micro wrong dance revolution. But first of all, let me get started with a picture. Who remembers this woman? If it chuff, think about your past, perhaps you've seen her before. I give you a little hint. Yeah, she was from Knight Rider. She was spunky and she was the engineer and the Knight Rider. And she really inspired me. Then I was a child because she fixed all those things. She was the electrical engineer and the computer scientist on this team. And I think she was one reason why I told my parents that they have to buy me a computer. I told them, hey, you know, it's might be beneficial for school, which was which was not really wrong, but also not really the truth. Something in between. But one, finally, things come in mind when thinking back to Bonnie. She was somehow a one man or a one woman show. And this is normally not the case. Normally, when it comes to computer science, when it comes to software engineering, we don't have one man or one woman shows anymore. Because software engineering is a team sport isn't. We need to coordinate a lot of people with different backgrounds and different skills. And when we speak about the huge implications, we don't have just one team. We have a bunch of teams. And so we need to coordinate all of the. While coordinating the people of one theme is hard enough, coordinating several themes can really be etcher. And there is one solution for this. The solution is quite old. It tells us we shall not write a monolith, which is a big software application, a Babel of everything, cooking a coffee and searching a shirt for me and booking some flights like this flight system. Instead of this, the idea is to write several Diniz systems, for instance, booking service at Chick Inservice, electric service or boarding stabbed in the cans. We are calling those services micro services for some years. The idea is quite old about the term is new. And in the last two years, this term became quite popular. The idea is also that all those services are isolated from each other, which means that long service does not know much about data ones. If one service does not know much about other bonds became available to service in isolation, we can enhance seeds. We can add new features without having the fear to break something. Oh, but they're within another service. That's why the less Southern know about each other that. It is. Then we take this idea of subdomains, which make up micro services, and it's the into the world of rundowns. We will end up with microfilms. The idea is basically the same. We don't ride a big front front-end instead of this. Right. Sir Redl Diana from THENS, which can be written in isolation, which don't know it needs to know much about each other, which can be deployed also individually. And now, of course, the big question is how to implement such mike referendums. And there are several Lonzo's there are several approaches for implementing Mike from, however. So far, none of those approaches will see really a great one. You needed to use several tricks, though, manipulation, eye frames, things like this. So it was not that great. But the good message is this, that back five. We will get the feature called Mutuel Federation. And Martorell Federation solves all or at least most of those issues. It is the first time we get out of the box solution allowing us to write sounds micro from this. And this is exactly what he's talking about. In Just Talk, I will tell you, first of all what the consequences of micro from Venza are, because micro of wrong things are not the silver bullet. Micro front vents have a lot of downsides. And before deciding for or against micro front dents, you should know there are advantages as well as they are disadvantages. Then I will show you how to use Marshall for the region. And at the end, I will present you a possible Rhodes. But first of all, let me introduce myself. I am month that I am a train and consultant for Angela. I'm helping a lot of companies around the globe with remote Angola consultancy and remote Angola workshops. Macfarlane's workshop is this one year, which about architectures for Angola for enterprise and industrial applications. And besides, there's some also quiet's connect that to the Angola community. I am doing a lot of stuff in the chairman's speeching area of Europe, but I'm also happy if it can be sent to other countries like Borland's. I like offshore and I will several times there. OK. Let's get started with the first chapter of this presentation, let's get started with the consequences of reform. That's mentioned before, MICRA from thence allow you to subdivide a big application into tiny bonds. And this in turn allows you for autonomous teams. That minge means we can have one diem for each and every subdomain bong, deam for each and every microphone. And they can work individually on Darbar individually without influencing each other. They can even buy British or deploy their bonds when they. So that's mentioned one that wound the chase, you get the separate development. So you don't influence each other and you can even separate deploy your stuff. That means when you are down your chest, deploy. You don't need to wait for other teams. Perhaps you know, the situation. You are down. You have great that some business value for your customers, but your customers will not see it because you have to sync with other teams. You have to sync up. You have to wait for other teams and only then you can debro everything. This is not the case when it comes to Mike Rowe from Dance to Microcircuits. Although each and every team can do their own architectural decisions and architecture, is not there one size fits all solution? Different subsystems might needs different architectures. And so you can choose what's best for your current subsystem. The same holds true for technology. Each team can do its own technology decisions. But here I would be I would say take care because it does not make sense to create that framework suit, to mix anglophilia fabric then few and so on. It's possible, but I will not do this, at least not in Schwabe. In short term, it would be beneficial if everyone used the same framework. But in long term, this is needed because a business application needs to be maintained for, let's say, ten, fifteen or even 20 years. And in the course of 20 years, a lot of things happen. So it would really be beneficial if you was able of exchanging your technology by another one for the next subsystem. You're right in, let's say, seven years. If you ask me for this reason, microphone, Ben's is a really honest architectural style. It's really honest because it tells you from the beginning that there will be that day when your technology is obsolete. Then you'll need to exchange your technology for another one because yours is deprecated or revealed not to be maintained anymore. But as mentioned in the short term, please keep with one frame. Fading this I think this all really shows that Mike Ruff rundowns, a first and foremost about scaling these. It's not about fancy architectures. It's not about mixing frameworks. It's really first and foremost about scaling things. And a good friend of mine told me that Theme's is rural, which means more than one. And that means inturn, if you only have one deam dealing. If you're from thens, don't even consider them micro frontiers. Perhaps there might be some advantages for your case, but in general, you only reached the sweet spot of this architectural style. If you have several themes, if you need to coordinate those themes, if they work on the same overall software as. And of course, there are challenges. That's why you need to be cautious. So, for instance, one challenge is you high compensation, which means you need to present your 50 Micra from Venz as a common thing. Do they use them B. S develop us like the idea of having 50 less complex subsystems instead of one very difficult and complex one. But the user does not like it. The user is not interested in starting 50 applications each and every month. So somehow they need to present everything as a common product to them. Also, they need to take care about UI consistency. Somehow it would be nice if your overall system would have a common look and feel in some situations. This is more important in other situations. It's less important when you think about the shopping system. Consistency is very important because consistency provides some kind of trust on the outside. If you think about an ERP system as a B, for instance, it does not matter that much if the top deck rate in the accounting part looks a bit different than that. That rate in the payroll. But it is not fun. It is not perfect. But I think when it comes to an ERP system, you have bigger challenges and bigger issues like writing. The right invoice is like paying the right amount of money to imbroglios. Most of the time, they are not happy. If they gets to less money. Also, we need to take care about bundle sizes. We don't want to end up having Angola five times in our eyebrows up because we have to load it five micro fronds. We just want to load Angola for a long time for our overall system. And also, we need to take care about Russian conflict. Using angle of five side by side with angle of nine, which leads to conflicts. It might work in some circumstances, but in other circumstances it leads to actually conflict so bad that prevents this. And there are some additional challenges by the think for the time being, those four challenges are in. That really shows that it is not the silver bullet. It really shows you need to think twice before you decide for my rough romance. If you can't deal with those challenges, if you reached a sweet spot because you have several teams, then it might be a really beautiful solution. If this is not the case, then perhaps the challenges. oboH weights, the advantages. The message is module federation, which comes with Fatback five, solves some of those issues. For instance, they give you a to deal with your high comp. You can load a separate that separately combine to micro from then into your shell. They deal with bundle sizes. You can share dependencies. You can share Anguilla core Anguilla home on Anguilla router amongst your microphones. And they allow you somehow to deal before Russian conflict. Perhaps it is not the ideal solution because it seems like there is not something like an ideal solution when it comes to preventing version conflicts. But there are some ways you can try out. And this leads to the second part of this presentation, which is about Martorell Federation. I am always saying mutual federation is a bit like the nineteen eighties. You have to experience them to grasp them. And that's why I'm starting with a demonstration. So if we look into my eyebrows, zoom here, I have a Shadel application and this Shalal application is capable of loading separately, combined my performance. Everything within the Stasch line here is a micro from thens, which has been separately compiled. Separately published. It even runs in standalone mode, as you see you at my shadow, this just loading the newest version of it or at Configures version on demand. So if you don't trust me, let me reload the beach and let's have a look into the network that I'm clicking here to fly. It's an TABC. My bundle is loaded. The bundle with the beautiful name, seven nine eight. And as you see here, it only has freakouts, which is nothing. This really shows that Martorell Federation allows me to share libraries like Angolite itself between all different. Angola is obviously not loaded, and now that I am here, it is just reused. Angola was loaded once into the shell and now it's reused by this Micra from then, even though it was compiled separately. Perhaps you are seeing now. Come on, man, flat. That's nothing special. This is just lazy loading, isn't it? No, it is a bit more than lazy loading, because if you look here, you'll see localhost five thousand. And if you look there, you'll see. Yeah, right. Localhost three dozens. So it really comes from different origins. And that was not easy to accomplish with more versions of that. So the big question that is answered by where Marshal Federation is this here, how would load separately compiled code in to you are ship. And perhaps are saying, no, well, that's not that difficult because we have dynamic in books. And even before dynamic imports, we had this require statement or this require function. And so it is not that difficult to point to another origin. And now I'm saying no. That's not Stich Ruth because that back does not allow for. That back does not allow for pointing to the origins with an inboard or and the required statement. And because of this, also, the angle of Selye does not allow, because the angle of CLIA is using that back on. The thing is that this bat back assumes that everything is there. It's compiled by that back needs to have all the codes available at compile. Everything is compiled together. Some optimisations are being formed and then your big application chunk is subdivided into smaller chunks. For the sake of lazy. That's the reason why this was not really possible before. But Module Federation is changing this Martorell Federation introduces a roll call, the shell or to host and another roll call that remote. In my case, that shell application is the host. And my micro from then is that remotes, the remote that has been separately compiled, that remote that is loaded on demands into the ocean. To make a shell out of an application, which just needs to add some configuration, dot the to the back configuration file configuration, dot the like this here which maps and the euro. Well, in this case, I'm mapping the your l am f Yvonne. Do you run. So it's an alliance are to say the least and none. Alliance because I think you do the same thing. But basically, that means that each and every year else, starting with M.F., you run, which, by the way, stands for Micro from them. Well, I know. Very creative. Each and every year else, starting with M.F. Ebong Boynes to something which comes from another origin Boynes to something that has been separate, decompiled, and which is also called MFT bomb. But. Also, the micro from then they look at some configuration out there like this, Expo's, the secretary using exposes, you can expose specific finds specific building blocks to your shell. In this case, I'm saying, hey, the whole file, my component is exposed as that component. And then something beautiful happens. I guarantee you now something really beautiful happens. You can do something like. You can export an F ebong slash component's. And so the costs, M.F., a bomb is mapped to an external implementation. It is pointing over there to a micro front end. And over there, this component here is loaded is component that has been exposed. And so loading something that was separately combined is really a piece of cake. Adding those lines of configuration settings is not that difficult. Perhaps you are wondering how the shadel knows to your end of the microphone? Well, for the time being, you'll get the remote and crit point when compiling the micro from that map back takes care about it. It is just a tiny file, just a tiny amount of bytes. And this remote and rebind needs to be loaded into your ship. You can grade the hardcoded script reference, you can grade the script reference there. Some lines of Dohle matchmake with Dohle manipulation or mean by. You can even call that configuration function of that back. And this configuration function then takes that you were out of this sort. That's micro from. Which means you necessarily don't need the remote entry point anymore. But the most simple of aid to go. The simplest way to go is just a load's that remote entry points from ŌBA. There are these thousands that back there, then Micra from then it's looking. So another question you might come up with is what's about sharing libraries and dances? Well, this is also quite simple. You can define a set of shared libraries on both sides. And if these libraries match, then the micro from then the remote will just reuse this library, which has been loaded by the shell. If the shell did not load this library, then Mike Rowe from Dan Charles loads its own library version. So this is quite smart. If it's there, it is reused. If it is not there, it is just loaded demands. Of course, that most. The most difficult aspect of this is version conflicts you might end up before Asian conflicts. Perhaps the Shali sequencing Angola seven, your micro from then the sequencing angle of nine. And if you tried to use both Toccata, all hell breaks. It's. That means you'll need some solutions for this and saying this Martorell Federation gives you solutions. First of all, you could configure a module federation to reuse the library anyway. You can say, oh, it does not matter. I'm a lucky person, so I guess it will work. Normally I need a Angola nine, but I'm OK. If Angola seven, because what shall go wrong? Perhaps this is also the ostrich strategy. You know, the ostrich, this bird, which is sticking his or her hat into the sand, man. There is some danger just waiting until that ship best by another other is that the microbe round them could load its own version of Angle, which means the shell would go if angle seven and the micro from then would go with angle on the. In the case of Angola, though, might be bad, pope solutions might be both in the case of a tiny library like our ex chess. It might be OK to go before the ocean, A or B. But when it comes to a leading framework, both solutions seem to be a bad choice. And if you ask me in these cases, you'll need to prevent such a configuration conflict, such a version conflicts by yourself, by introducing conventions, by introducing contracts, or by using a MONA repository, which is forcing you to just use one version of Angola. And she are acts of material and so on and so forth. Of course, integration testing can help because it shows that everything still works after deploying and you imprecation part and you might. OK. So much for the theory. Let's have a look into my example. Let's find out how my example has been configured. For this, I am just looking into my backpack Conficker charts and to see it is an ordinary backpack configuration and it just has this additional configuration section pointing to the Martorell Federation bloody. And it points to a remote which is called M.F., even on micro from Dennes one. It's also called MFT Bomb over there in the separately compiled bomb. I'm also telling the show that I want to share those libraries, Angela Korps, Angela Carmen and Angela Rupp. This is everything you need to get started with your child and Marchal Federation. Of course, this map, that configuration is quite huge, and normally we don't write about that configuration by hand anymore in the world of Angola. We have to Angola see alive. It's which grades this map back configuration. So everything we need to do is to find a way to squeeze this little configuration fragment into the already existing backpack configuration provided by the sea light. But as you will see in some minutes, I have a solution for this. This is their shell chest pointing to another microphone then and sharing some labellers. Then we look into the configuration of the macro front. Then we have more or less the same. We also have the modular federation plug in. It gives the micro from that name, namely MFT Yvonne. Here we have the name of the generated remold entry points. And he'll be exposing stuff like an Angola component or an Angola Muchow. That means that the shell can load those building blocks, then them actually run them. And the force also I have these Shia stuff here. I have this Shia array which defines all the libraries. I want to share with the Shia. If we now look into our uproots file the uproots file of the shell, we see something that's also quite beautiful. We are using here. They're out in apropo eight. They are using the Routt. As always, to get up if lazy loading. That means from Angela perspective, we are only doing lazy loading. But as you might see here, I am pointing to a module which is mapped to where micro from bends. That means when that back sees these at runtime, it does not search the current bundle for this module. It searches the bundle over there for this module. And of course, first of all, despondent over there. Are these micro from Bandy's. But from Angela's perspective, is just lazy loading. That means we don't need that extra resolution for loading our Micra from Den's, which is kind of nice. It feels. Also, we have to tell the shell they are to find that microphone vent. And for this, we need to load the remote entry points from over there. Here, I'm doing this with a static script reference. I could also created an Amik script reference, or you can, meanwhile, do this by calling some functions of fatback DB pseudocode look like this. Tweet that back. I think that real function name has a different name and here I can then provide all that your hours of my mapped post. That's also possible and that's even necessary if you have had the Namik amount of micro from thence or let's say at an amazing amount of bluffton's. OK. That's all. So it's pretty much a straight forward thing. And that's why I am really looking for about the mutual federation, because as mentioned currently, you'll need to deal with a lot of workarounds to accomplish the same. Perhaps you'll also like this idea. And so the next question you spend can be. And while there is not an official road map, but if I'm looking into my class for you, I can tell you several things. First of all, that back five is currently pito, which means we cannot use it for production. And it is not used by the angular A. The angle of Selye is always using that laid the stable version of that back, which is obviously currently version of full. The examples shown here, by the way, is a proof of concept, which is using a custom that back confit. You've seen it, but it is also using a batched version of the CLIA. So don't do this at home. Don't do this in production. It is good enough for this proof of concept. But I guess you don't want to work on an enterprise scale application with a home broon batched version of the CLIA. You deserve that. And also your teammates deserve that. Also, that seal, I will not use that back five before version eleven, which is to you in full, I guess, in November. They are off November Boston month. They are the full version of Angola came out. I can tell this because Angola 10 is due in the next weeks. And as ABAB back for is the current stable version, it's been enforced for sure. You was respectful. But hopefully if that back five arrives in time and if the Angola manages to to use it for CLIA lab and we can get it in fall, for me it looks quite good that this little people's. Also, you'll need to find a way to squeeze this federation configuration into the s.L. Ispat back comfy. But for this, we have solutions. Perhaps you know that Seelye is the enhanced level, they can, for instance, rieth custom build us to define how and she builds works. Those builders are exchangeable. The main builder is using that back to build up for libraries, is using entry, bigger picture. And so it would be possible to switch this default builder by another builder, which is capable of enhancing the bad back conflict. Or if you need something like this, you can even do they use an X builds plus, which is an open source build up and it allows to squeeze an existing barebacked configuration into another one. Just Chelse performing in March, which is what we need here, marching the Martorell config viff that that back conflict. That means we just need some patience. We need to wait until fall. Let's do some hibernating until then. And then we will have this beautiful, huge. OK, cool. So if you like this stock, I have updated my e-book before this topic. I've updated its with chapter about Martorell Federation. And there is another chapter if alternatives to Module Federation. So if you like this, you can check my. And if you didn't like my doc, check out my book anyway, perhaps I'm writing bad that then I'm speaking Whoknows. Of course I'm writing befouled accent, so perhaps you'd like it even more. OK, let me come to a conclusion. What did we see today? We've seen that the main purpose of Micro from Dance is scathing themes. It is really a dry topic like this. It is not about fancy technologies or mixing technologies. No, it's about scaling themes. And that means you need to have more than one. The two reached the sweet spot. Also, it's about decoupling, which means that one part of the application, Bong Mike for from bans should not be coupled to the other ones, because when changing something here, you don't want to break something. Marchal Federation allows you to import from other Eppridge occasions applications from other origins. So this seems to be the first sound or official solution for creating micro from. Also, mutual federation allows you to share libraries, but please take care of Russian conflicts, because if you ask me. Currently there is not a sound solution for preventing all diversion conflicts. You have to take care about this by yourself, by leveraging some conventions or by using and micro, not in micro and emotional repoll by using it. Molnau. And there he said, last thing I want you to remember. If you forget everything, please don't forget about this woman, about Bonnie and pretty's right to be a bit like Bonnie because Bonnie is always thinking first. And Opal seemed to have colic, these this mitsch from the beach. I don't remember his name. He was always hitting first and thinking then Botibol me is always thinking first. And if you ride to be like Volney, first of all, you will evaluate if you need to microphone. And if you say, no, I don't need them, go with them. My chest thick monoliths. You know, the micro from thens people, also the micro service people are claiming that the monolith is something that's that. For them, monoliths is a curse, a bad word. But honestly, it does not need to be something that's bad. If you take care about your monoliths, if you make sure that not each and every bot is accessing each and every other bot, it can be something that's beautiful. It can be something that's my chest. That's by friends of monoliths coins. This very term. Saying this, if you want to build on my chest, Dick, Mona, let's have a look into an X because an X enhances the angle of Selye. We have some tools allowing you to create loosely coupled monoliths. And if you say, yes, I need all of this because I have several themes and the needs to work in isolation, the need to do their own decisions, then consider them Archil Federation. In this case, if you ask me, Martorell Federation, it's a very attractive upcoming technology. So thanks for having me. I have already uploaded all my material to my blog. And if you're bound, follow me on Twitter so that we can keep in contact. Thanks. And enjoy the rest of the. Thank you so much, man Fred. It was amazing, amazing, amazing presentation. Get back one more time for Shine and for Manfred. But this is not the end. Today, we have a special guest, Raffo Bizzle Scarr. He will present some very specials, Angola Brek and the World Stock. So one more. Thank you, Manfred. Thank you, Shai and Raffo. This stage is your have five. Can you hear me? Yes, of course. OK. So I am so happy for the model for the nation and for the isolated deaths that compose their song. No, it's a traditional isolation song. I want to play you for you for the nice weather behind the window. And let's play. Oh, yeah. Early rock and roll. Thank you so much, Ralph Hall. And once again. Thank you. Thank you, everybody. It was great. And other great meet up and we see in two weeks. Thank you so much.