Micro-Frontends ​ with Module Federation​ by David Alecrim (@david_alecrim)​

[Music] hi everyone hope you're doing great technical issues happen but we're here either way so first of all welcome again to another one of our ex-geeks um live streams on youtube first of all it's awesome to see you all here because we've been growing our community in our reach lately so welcome again and if you're new to our uh youtube channel and to our talks uh we're happy to give you a brief introduction and execute the kia group company so that works that works from portugal in germany we actually have people in the two uh people and teams in the two locations so engineering company that is focused on providing capacity to product companies that are looking um for challenge driven product engineering so actually uh we're very oriented to solutions and we build solutions through software so it's quite exciting um our our day-to-day so if you're interested in knowing more about us let us know and follow us on social media and all of that and actually i have a very special guest a very special guest today to bring you which is david one of our very own software engineers and uh the vids will give us a talk about microphones and suites module federations but i think i'll give you the space and introduce you the beats and the welcome awards and welcome to our live streams it's nice to have you here um uh just a pleasure nice i'll just give you the the stage and give you the entire microphone i hope everyone enjoys the vid presentation and talk as much as i i've been doing so far so um go ahead take the stage and just one small reminder if you have any questions everyone feel free to leave them in the chat we're we're going to address them during them during the uh the park so if you have them feel free to leave them and uh we're going and we're going to answer them throughout the presentation so david i think having all of this such go ahead and break a leg thank you all enjoy okay so i hope my screen is being shared right for the presentation yeah now it is so like krita said i'm here to present to you today microfrontends and how to leverage webpack five together with module federation and this is actually a sharing of an experience that we are having while doing this in a client of ours at x geeks so a really quick intro my name is david olkri i'm a senior software engineer at tax geeks and i'll leave you here some of my contacts in order for you to get in touch with me after the presentation in case you want to reach out so to get a bit of an introduction on micro front ends historically it was a it was a concept first coined by footworks it was coined in november 2016 like in you can see in the image and it was introduced when they wanted to bring to their front ends the advantages that they were having in in their micro service architecture so it's being currently used by some big names like spotify's orlando soundcloud peasant and it's it's quite a polemic subject but like everything in our area or many things in our area it's a matter of fit right so there are scenarios where micro front ends will fit and there are scenarios where it won't fit so it's a matter of pros cons and scenarios uh you can see here some of the comments that that i extracted from from a revit uh reddit post um so yeah mainly it's bringing down the the the adoption of the microfront ends don't use it because you don't have capacity don't use it because you have a small team don't use it because it brings complexity well yeah of course but like i said it depends on the problem it depends on the institution it depends on the team itself so some of the main benefits that we wanted to bring to our clients uh from adopting microfrontence uh was were threefold basically it were it was to get more independent deployments between the different products that we have in the platform to get less interdependency between them and when i say interdependency i mean interdependency even in development and not only in release cycles right and also to get better scaling because the team is growing it and it will keep growing even more uh so with this micro frontends model we can better scale the different products inside the platform to give you a bit of context uh before i advance into the solution itself i'm going to provide you some details uh of of the client that we are working on and before uh the the actual situation we were small teams we were working in front and back and then infrastructure horizontal layers what i mean by this is that the front-end team was spanning multiple products inside the platform and one back-end team was spanning the back ends across the different products that we have um also there was already around a two-year cycle of development on top of the platform so yeah two years of is already a lot of code as you can imagine and then we have we have like a product vision change so we wanted to do something more product centric we wanted to focus more on product set product themselves instead of the platform as a whole so inside our platform we wanted to identify key products and we wanted to develop them we wanted to give to these individual vertical teams its own product manager their own design designer or design designer team depends um and this model would also scale better like i told you before so these vertical teams were what what we wanted to achieve in order to get those three advantages that i talked about in the previous slide so now that we know what we wanted to achieve we started investigating right and microfrontends was a really clear answer to investigate so he started the investigation on this basically there are some frameworks uh for for the micro frontends architecture we have mozaik9 for example which is the framework from zorando it was it was developed by them to implement the micro frontends uh in their platform we have single sba which is a really good one they have a lot of documentation and best practices to use in in the micro front-end architecture and it's really cool then we have pyro and we have several others um but then we have another problem right because like if we adopt this this one of these frameworks we are adopting another framework we are putting another framework on top of that two-year-old stack that we have we needed to adapt the project we needed to change folder structure we needed to do changes in the code itself and we really didn't want to do this so we tried to investigate something that didn't use a framework already right so yeah we wanted a no framework solution and the conclusion and the answer to this is basically module federation so module federation is bundled with webpack 5. it was released officially on october last year so it's recent still and to quote the creator of module federation i'm going to to quote now mojo federation allows a javascript application to dynamically load code from another application and in the process share dependencies there's a space missing sorry so i'm going to take a bit on this and i'm going to to expand on some ideas that this sentence has so module federation allows the javascript application by javascript application here we mean that it needs to be a webpack 5 bundled application and then it allows to dynamically load code so the load code part is really crucial and what what it means is that everything that webpack can parse we can share between different federated modules or micro front ends we're going to use this term interchangeably in this talk it it allows them to share dependence it also allows them to share code between them at run time and code means everything that webcam webpack can parse like css files js files react components images you name it so everything that webpack can parse it can be shared at runtime between different micro front ends and in the process they share dependencies so this is also really key in module federation and they have a lot of configuration to manage this because one of the main pitfalls in the micro frontends architecture is basically handling shared dependencies because when you have like two dependencies one dependency in different versions in the same scope in the browser scope you may have like conflict or conflicts it may break the experience it may cause an unexpected behavior so you really don't want that and sometimes it's hard to manage this so to expand a bit on how they manage shared dependencies i'm showing this diagram let's imagine that we have two micro frontends microphone and a and b and then the user lands on the micro front end a so he's served the micro front and the experience then this micro front end already has like two dependencies inside in the scope react at version 17 and blow dash at version 4. then the user navigates throughout the app and he reaches some kind of roots in this root we need a component that is uh specified and is used in application b so we request this component at runtime like if if it was an ajax request for the code what module federation does is he verifies what the dependencies are for this component and he sees that component c depends on react version 17. we already have it in the scope so it's cool we don't need to do it to do anything more he sees that we need lavash at v3 so what he does is he brings lavash at version three and i'm being simplest here but i'll be more thorough in the next slide and then he also sees that we need date functions and he also brings that in into this scope and what he does next is okay i have all the dependencies that the component that i need needs sorry for the redundancy and then it actually brings the component to work so component c will be imported at runtime for the application a and the user experience continues and the user is happy and he doesn't even know that a component was imported from another micro front end so yeah this is how much of federation shares dependencies really quick one of the reasons that i said it was simplistic was because wall dash at 3 3 was imported here but depending on your configuration it may or may not be possible to import it uh yeah and i'm i'm going to show you a bit more on that a few slides later so now that we knew what technology we wanted to use and what objective we wanted to achieve uh how did we process this migration because we were in a monolithic application right we don't go from a monolith application into a micro front-end application from day to night of course not today um so the plan was simple so we had this this uh architecture at the time a monolithic application a regular react single page application the user would enter the experience and then through client-side routing he would be served different kinds of components and what we wanted to do was to migrate to this architecture so this is the desired architecture that we envisioned it's basically the user always lands in a single entry point this single entry point is the app shell it serves as the only entry point that the user has then the app shell knows that there are more micro frontends in the system so he knows that there's micro front end a b and c and he knows the location where they're at then when the user reaches some kind of base route imagine he reaches slash route a as we can see here uh then we import at runtime the the the code from that micro front end and we delegate everything else to that micro front end so that's the base architecture here each square that you see in this architecture is a micro front end each one is deployed independently each one can be developed in a standalone mode so that's also really cool feature in this architecture is that like if you're working in the team for micro front end a product a uh you can work on it and launch the product only the product a you don't need to launch the whole architecture with the app shell the application bc etc so you there's a way to to actually develop this in standalone mode which is good uh so yeah another really important and key feature in this architecture is that by by providing this single entry point that we call epshell we are actually providing the same user experience of a single page application a regular single page application because when we imported runtime code from another micro front-end that's exactly the same as doing code splitting in a regular spa so it's like making an ajax request to the server and getting the response so the experience is exactly the same and that's really key because it's a really good experience in the end for the for the user another thing that we have here in the architecture is is a shared leap so this works as a shared micro front end in fact and what it does is it holds all the common components for the for the architecture so it holds the theme it holds buttons it holds text fields it holds labels everything that is common and that we don't want to declare in each of the products that we have right so we're not declaring the same button in the application a b and c we're declaring it in the shared library this has its pros and cons we can talk about a bit more on that later or if you have any questions on that but we'll get to it so now i want to show you where we are in the client so because this is all an experience based on the client right uh we're still very basic in in the migration basically we have two micro front ends in production uh the monolith was brought into a big micro front end that has all the sub routes inside it through client-side navigation and then we have also a shared library deployed with a shared micro front end and it holds precisely those components that i told you about like the theme the buttons the the labels the text fields all that stuff um so yeah this is what we have in production right now and what i want to show you is a demo of the implementation of the desired architecture so all that stuff with the app shell the different products and the shared library i'm going to show you a demo right now of how that looks like so you can see the browser yeah um this demo is available under my github in a repository called cloud store micro front ends in the end you have a link to it and we can also drop it in the chat probably i don't know if rita can do that for me or not um or i can do it i'm not sure if the private jet is visible for everyone so yeah the the code for the demo is in this repository and we can see here the architecture part um and this is a more detailed uh implementation of the architecture that i showed you on the on the slides but it's basically the same thing so in this project we have a nap shell the single entry point for the user and the only the single and the only not not to stress enough this uh it's exposed in part 3000 and then we have three different products we have items which are clothings clothing items in this case we have a checkout product and a blog product so of course well probably this wouldn't be different products unless you were like a really really really big company but let's imagine that you are right because this wouldn't be adoptable for a small company either way and yeah the items are exposed in 2001 the checkout is exposed in 3002 the blog in the three and then we have our shared micro front end which is exposed at 3004. we have a question sorry to interrupt you but i think it's a good one uh so first of all thank you for for your questions so the question is you may have multi versions of the same dependency into the shared library what are your thoughts on multiversions in the shared library um well you can uh it depends on how you manage it and um i i think i think i missed a slide in in this presentation that i had in another version but what i wanted to show you is um and i can show you really quick let me just hit the code for the actual project and it's easier that way open okay sorry okay right so i'm going to bring up an example of a configuration for the microfrontends namely for the upshell so this is it i'm going to zoom in a bit so you guys can see better right pretty sure that you can see now this is the configuration that we have for the for the micro front end and it's basically the configuration for the module federation plugin because it's a webpack five plugin um we have the name of it so we we know that this micro front end is called app shell these are the remotes what this means is that this microfrontend knows where the other micro front ends are he knows that they are located in 3001. the items he knows that the other one is in 3002 at localhost and so on we also declare the manifest file that they have so each microfrontend needs to have a manifest file and what this manifest file does is it states to the other microfrontends what it has and what can be imported and what are the dependencies of the of the imported components and then you reach the shared object so this is part of the answer right now so we here we are saying that we want all the dependencies in the versions that they are explicit in the package json and then we treat two dependencies differently and in a special way so we are saying that react and react dom for example are singletons what this means is uh module federation when it brings a react to the scope it will only bring one single instance it won't be possible to have two different instances in the in the same scope auto federation won't allow it and it will actually break um so this needs to be managed by the architect of the solution and it needs to be enforced by the teams that are working on it um of course this is for critical libraries like react and react-dom let's imagine that you have wadash probably lavash v3 and v4 won't have like critical collisions so yeah you could have uh different versions of lavash for example if one had one thing that you needed to keep and the new one had new features that you wanted to have so i hope that answered the question and now you know also how the shared object is configured for the module federation great answer thank you david for for that and also thank you for the question we actually have another question so if you don't mind i'll also pop that one is that okay sure nice so this one is from tiago first of all tiago thank you for your question the question says you said that we could develop the micro front end in a standalone mode but if we have a shared uh microphone and that contains the common common components we probably need to run the microphone sense and the shared one right yeah so that's like the exception here uh it does make sense to do it of course probably if you are working on product a you want to to actually go and and start product a or items in this case and also the share library because you are consuming stuff from it so yeah that makes sense and you don't need to do to launch anything more in the in the solution um but it may be the case that you are not running a shared micro front end and yeah in that case you would only launch your product but yeah nice question and yeah it makes sense cool thank you for the question tiago guys just before uh the vid keeps going with this presentation just uh everyone remember that you can of course leave more questions in the chat okay go ahead okay so like i was saying we have here uh the diagram of the architecture that we have and this is the actual demo of it implemented right so it's a very simple clothing store it has a list of clothes it has the details of one clothing item it has a blog list it has a blog post detail and it has a checkout screen and i also a really small checkout component here in the top right in the nav bar so i'm going to do a load of the first page and we're going to to see the network tab in the developer tools to actually get a bit more context on this also it's in a fast 3g simulation in order for us to see the the actual experience happening so here in the top left you can see a loading it was quick but i hope you saw it that was the time between reaching out to different micro front ends that are deployed and bringing out the code and showing spell over between in that time so you could choose to show nothing or you could show like a really good looking spinner or something so yeah looking at the network tab here we see here four manifest files the remote entry js files that i told you about um this this manifest files they are for because we have five micro front ends in the solution and we are reaching for the app shell which is the entry point so naturally this single entry point will need to reach out to the different micro front ends to get their manifest files so this is what these remote entry js files request ours requests are then we you see that we have a slash items here in the navbar so we have a client site routing setup in the up shell as i said in the presentation the app shell knows the base route to each micro front end so the clothing items is in slash items the blog is in slash blog and the checkout is in slash checkouts then every other subroute is delegated to the microfrontend itself and we can see here that in the in this request so we can see that we see the list of clothing items right and how did we do this you can see here this request we requested roots from 3001 so these are the roots of the clothing items micro front end we are requesting its roots we are adding this to our scope and now every time the user navigates inside it so let's imagine that the user goes to the clothing item detail so this root the slash item slash detail slash one epshell doesn't know anything about this and he doesn't need to know it it's already delegated to the clothing items microfrontend okay you can also see that there are no more imports here in the network requests because we already have everything in scope that we need for at least for these two pages that come from the coding items microfrontend so we saw here that we can bring the whole experience of the micro front end so like get me everything from the micro front end and i built built it into this scope and now i delegate it to you but we can also do more granular stuff so this checkout item here it's one really small component that export that is exported from the micro front end and we do this by stating this here so i'm going to go to the item the checkout microfrontend which is somewhere here and we're going to analyze the the configuration file for the module federation and we can see here a new key that we didn't see in the app shell which is exposes so what we are saying here for this microfrontend is that besides exporting the roots or basically the whole microfrontend right because we are then delegating it the the roots to it we also export this really small checkout card which is the component that you see here in the top right and you can actually see the request if i refresh the page sorry i messed this up because i touched the name um you can actually see here this import checkout card and this is the import of that single component from that microfront end and only that so if i add something to the card this gets updated as you would expect and then if i actually hit a slash checkout here on the top bar this is when the routes for that micro front end are imported at runtime so now the rest of the experience is already delegated to the microfrontend um and if i purchase the items yeah this gets done if i go to the list it's it's already there everything everything is in scope so no more requests are being done like a regular spi experience right we don't get hard refreshes anywhere it's a regular spa user experience and then if we go to the blog because we still haven't gone there we can see a new loading because we are requesting the roots for another micro frontend we can see here that we are requesting from 3003 which is the blog microfrontend if we go to the details this is already delegated like in the clothing items so this is the demo there's nothing really much to show besides what what i have shown i hope you understand how this implements the architecture and i hope i have explained good enough how we implement this architecture and and the benefits that it brings so yeah i'm going back to the presentation if you have any questions feel free to drop them um i wrote two articles on this subject you have here the links and the qr codes to it to them the first article is basically the investigation and all the theory behind reaching the architecture that we want which is the architecture that we have the demo for and then the second one is the actual implementation so all the steps in implementing the solution until we reach that that demo that i just showed you then on the right we have the code demos the first one is the demo that i just showed you and the page uh with the repository there and then we have this second one which is the federated web shell this is more like a playground where we are experiencing different stuff like state management in microfrontends like internationalization and other types of configuration when we initialize per say a micro front end so yeah we're kind of messing around with different stuff there feel free to see it test it feel free to also do pr's if you if you if you want that would be cool so yeah i encourage you to do some questions let's see if i can answer them and also feel free to read the articles and go to the code check it out test it see if it applies to your platform or to some other project that you want to test out exactly thank you so much uh for your talk um just to remind everyone that if you have questions the video is still here and uh this is a great opportunity to ask him um for questions comments uh opinions feel free um let's wait um just one or two minutes to see if we have more questions um popping by but in the meantime uh david um that's uh that was a great uh presentation thank you once again for for that that's always cool to hear from you if if i hit something in this private chat is it visible to the users to the to the viewers sorry not not in the private chat but i can share with them if you want to and i would be happy to okay then i'll put it here and if you can please share them because they may not have had the time to copy it actually we already shared that one so the link for the github so that's cool so if everyone if you haven't checked it out we'll share it again all right boys so i guess there's there aren't more questions yet or uh from from the audience at the moment so we have john souza saying awesome francis i totally agree with you thank you for joining us for for today um and thank you everyone but especially to david that's not only puts this uh talk together and shared some of his expertise but also to everyone at home watching us at the moment uh thank you all for being here we will have more of these talks at their center also such that it was a great presentation so i think this is a nice compliment so and um we're happy to to see you around in the next uh live stream which will be next week so see you there and thank you uh everyone for being here and especially thank you david for such a great presentation thank you it was a pleasure nice thank you everyone bye

Channel: xgeeks

Views: 1,296

Keywords:

Id: Vzp6QSc3SUY

Length: 34min 11sec (2051 seconds)

Published: Wed Jun 09 2021