Hi, today we will talk about a two hot topic in the software industry today, especially on the web GUI, the microfrontend and the design system. Before we dive through on the main focus of today's talks design system for the microfrontend ends, it is important for us to have the common understand think about what micro front end and design system are the micro front end are independently deployable front end application that is modeled around business domain. It is an effective way to use the domain for the software boundaries and some other technique is by using the features to divide front end applications. Microfrontend ends is a technique for decomposing the front end application into smaller and simpler chunks that can be developed, tested and deployed independently. In other words, we'll be able to change portion of the application front end applications without having to change anything else that's been micro front end give an ability for the incremental change and upgrades independent deployments and opportunities forming an autonomous team the SAF organizings and independent team the design system is collection of the reusable components guided by the clear standards that can be assembled together to build any number of applications. Imagine that we have new teams that consists of the designers and developer. When we do have a design system already the developer be able to develop the page, the new page or the new model. In fact the prototype faster than having to build from the scratch and the designer have the base for them to do. The designs design system enable teams to build a better product faster by encourage teams to develop a component in abstract way because that makes the component become more reusable and the reasonability makes the skill possible. A design system unites the consumer of the design system, applications and the product around the common visual language. It bridging the gap between the design and the developments. A design system provide documentations component that been published into the living styguide and usually we use the tools like the storyboard js that have an options to review how the component been implemented and also the living styguide like the storybook provide a playground for the developer to play around with the components. For example, if we have the buttons in the living styguide, then developer will be able to click the button, hover the button and to see what is the outcome. By interaction with the components and the living styguide provide a framework for development. It is isolated from application implementations, then the codes will be much simpler and the storybook gives an option for the buffer to copy the implementation code from the styguide and use in the application. By having the living styguide documented. It makes the living styguide the single source of truth for the design and the components. Let's go through on the first design system called centralized design system. We will analyze, we will discuss is it that this centralized design system is suitable for the microfrontends. A centralized design system having a central design system where it consists of a core component developer which is the maintainer, the developer of the component that be reused by the application across organizations. The way that they use the component design system component is by using them by toggling the version in the package JSON because the design system will be published, design system component will be published into the package manager control like the NPM or internal package manager like the Vedasio or Nexus. The change that we made by the teams require for the consumer of the design system to recompile the code base and redeploy their applications or their portion of the front end applications and for the teams to make a change into the design system component require for them to make a pr or the pull request as a contributor. Their quotes will be reviewed by the core component developer, the core component developer will make a feedback and if everything is on the green light then the change will be merged into the design system components, right? So that is that this centralized system is suitable for the microfrontend. And I would say no because we not be able to do independent deployment because change in the design system component required for recompile and redeploy of their consumer, the applications and the team is decoupled because they need communication to make a change between the contributor and the reviewer and somehow they also needs to communicate about the change across the team so they be able to have an options to either stick with the old version or upgrade to the new versions. But the benefits of this centralized design system is of course it's easy to make incremental change because consumer of the design system be able to toggle the versions of the design system components. The second one approach of pattern is called independent design system. Independent design system usually use the modifierations that been provided by the webpack Phi and by using the modal federation we'll be able to make the design system as same as the application because they can be independently deployed into the productions. Once it's been deployed, the consumer of the design system which is setting up or been configured to fetching or gets the design system component through the networks. The chains will be reflected into the consumer of the design system without the needs or recompile or redeployment of them however that they always have a possibility or risk for the teams to accidentally push or commit the change that have a breaking change and if they did that then it will affecting all of the consumer of this design system because they only have a single version of the design system component. In order for the teams to avoid the breaking change that reflected into the consumer of the design system then the owner of the consumer of the design system required to make a coordinated release. They need to communicate with all the rest of the team to give the awareness about the preparations that they need to do in order to avoid the breaking change. And on my opinions, the independent design system also not suitable for the micro front end because it has decoupled between the teams to do the coordinated communication between them in order to avoid the breaking change. It's not convenient to make incremental change because of because of it is a possibility for the team to make breaking change and it require for a lot of effort for the testing team to test to make a test of all of the applications and it require a lot of the efforts. Then my recommendation is to use a design system called provider consumer design system. The provider consumer design system is separated or divided into first the provider design system and the second one is the consumer design system. The provider design system have things like the color system that have all the colors, standards, colors using uses by the rest of the consumer design system. The spacing system, there needs to be standards, the icons, typography and the fonts and they also have the atomic component which is the small UI build blocks that will be used and be customized by the consumer design system. And they also have the complex component in the form of the composite components. By using the two patterns called the headless UI and the compound component. The headless UI is the patterns to provide you the functionality which is the UI logics and the UI interaction handling handler and it gives the maximum flexibility for the consumer design system to decide on the UI user interface look and feel while the compound component, the way that they provide the component in division of the component. For example if they provide the academic component, they will provide set of ecudent header, academ body, academ title, et cetera, et cetera. The consumer of the design system we use the sorry. The consumer of the design system we consist of the customized atomic component and implemented composite components. The headless UI make a separation between the extraction and implementation where the provider is the one who provide the extraction in the form of UI logics and UI logics and the interaction handling to the consumer of the design system and they will implement the extractions and they will work on the look and feel. This is an example the headless UI in the react JS as you can see in the red circle, those is the UI logics and UI interaction handling methods and properties and we will use those things to develop the combo bots. And this is an example in the angular way, the headless UI in the angular way where the same things on the top, they have the UI logics and UI interaction handling in form of the properties and methods. The last one is the VJs example of the headless UI. So by using the provider consumer design system, it will give an faster and convenient way for the teams to make change upgrades and of course do faster deployment. Because the deployment will be independent based on the team, the other team will not blocking the other teams. They will be free from breaking chains across breaking chains that will ripple or cascade into the other teams. And each of the team we provide their own implementation of the provider design system which is the consumer design system. And the provider design system will be used by all of the consumer design system, which is the applications. By maintaining use of the package manager control like the NPM, Pedacio or Nexus. Because it's not frequent for the provider design system to be changed, then it's all right to retain the use of the version control. And if they have the change in provider design system, they need to recompile and redeploy. So in the summary, by using the provider design provider consumer design system, we'd be able to have an independent deployment, forming an autonomous teams that is couple and scalable organizations, and to make an incremental change, it will be component and easier for the team. That's all for my talk. Stay tuned and stay safe.