SPA as Platform with Micro-Frontends & Capabilities | Saranya Thangaraj | ng-conf 2021

[Music] hi everyone i am very excited to be part of ng-conf 2021 my name is sarina tangaraj and i work as master software engineer at capital one i'm the mom of a two-year-old and during my free time i love drawing and painting uh so these are some of my favorite pencil sketches so let's jump into today's topic spa as platform with micro front ends and capabilities so what do we mean by a spa as a platform so traditionally uh front-end applications are used to be single-page monoliths and uh when the application became bigger multiple teams contribute to it uh so when changes have to be made then it should be a lot of coordination and testing between teams this causes a lot of friction and we want to get out of this pattern so that's why we want to reimagine our single page application as a platform so platform is nothing but a group of capabilities that can be used as a base upon which other micro applications can be developed and they can all be composed together to provide a single unified customer experience so that there are three main fundamental pillars of a platform they are consistency reuse and isolation we will see uh in detail each of these pillars so the first is consistency since multiple teams develop different applications and they are all composed to provide a unified customer experience it's very important to have consistent look and behavior across all the applications so we can achieve these by using a common design system common icon library and common web component libraries so common design system is much more than a style sheet it is a single source of truth that can be used by designers and developers to develop your front-end application so you should provide details on foundational concepts like accessibility grids colors typography and it should also give guidelines of content language error messages and it should have detailed documentation of how you should apply styles for different html elements are in different situations uh and uh by having a common design system we can have a shared vocabulary across teams uh and uh across our uh tech product and uh design so for example if you say informational alert then everyone knows what it should look like and how it should behave based on the common design system so similar to a common design system we need to also have a common library for icons so that we can use a same icon across all applications um and also common web component library we might have instances where we want to create a custom html elements um for example if you want to create a custom input element for currency then we can create a currency web component um and it can be consumed by all the applications so when creating a custom web components it's best to use vanilla js so that we don't have to worry about uh you know frame framework conversion collision um and they can be easily consumed by their uh applications so other candidates that are good for uh web components are like common headers and footers that are used across all the applications and more importantly all the web components must be documented properly and we also need to have a storybook for all the web components so that our developers can go and reference that when trying to use that in the application so the second pillar is a reuse so we want to reuse as much uh capabilities as possible uh and our redundant work so all applications i have um analytics and a b testing uh uh that they might want to perform so those uh uh scripts can be uh moved to a common sdk uh and also uh common utility functions like validations uh and tracking user activities all of those can also be moved to a common sdk uh so that individual applications can just consume the sdk and get those uh um services um similarly entitlement and future toggle services can also be part of the common sdk and we can also create a reusable micro front end so reusable micro front ends are different from web components in that micro front end has a end-to-end feature so it has a ui uh back-end service and then it interacts with data so it provides end-to-end functionality for us a particular feature uh so we can also create uh micro front-ends as a reusable components um when we do so we have it's best to use a vanilla js so that uh if you have to embed this micro front end into another uh application um we can avoid version and uh framework conflicts uh if it is a built-in vanilla js and then the last pointers are to create a shared infrastructure so instead of each team having to uh uh host their application and in their own container and ecs we can have a shared infrastructure uh which which can host all the static assets uh so that uh all of the devops work is abstracted from the teams um and we can also enhance it in such a way that it has a uh connectivity to sso and api gateway uh so that it comes out of the box for the application teams and the final pillar is isolation it's very important to enable teams to develop and deploy their applications independently so in order to do that we make use of a micro front and architecture um so micro front ends enable us to uh uh create uh teams based on our business our domains uh and it allows us to scale uh teams um uh efficiently and uh also it provides isolated failures so that a failure in one microfront end will not affect the other parts of the application so there are several patterns that we can use to create our micro front ends we are going to discuss about three of them uh multiple spa spa with the embedded micro frontends and the spawita model federation so for the purpose of this demo i have created a music store application so this is a how the application looks like it has a home module albums module and events module and it's part of a monolithic application um and uh in the backend there are microservices for login album event and the order [Music] so we want to convert this a traditional monolith into a multi-spa architecture so in that case what will happen is each of the route in the application becomes its own micro app and uh based on the route that is requested alb will redirect the traffic to the appropriate container so the consistency between these micro apps will be maintained by using the common components sdks and styles um so there are several advantages uh to this approach uh so this uh makes uh the uh micro frontends to be truly isolated um because uh each micro front end is basically a micro application um and each team can own their technology decisions they can choose their own version and framework uh there doesn't need to be any coordination between uh different teams uh and uh you can reuse the microfrontend as a whole without integration for example if the albums now microphone 10 needs to be used in some other application you can just uh add that route to that other platform so that it becomes available in that platform it is great for linear applications uh what it means is that for example uh if you take a loan i mean applying for a loan so first step was uh getting pre-qualified second step is looking at the offers and third is choosing an offer and then submitting an application so it has a series of steps um in a sequential order uh so it is great for those kind of applications in that um each route could become its own micro front end so there are some considerations that we need to take when using this approach uh the first is state management since uh each application is a independent of the other and doesn't have a knowledge of the other application now it's very important to have a minimal uh data communication between the uh micro frontals um and uh we can use make use of query parameters uh session storage and local storage to pass some minimum data between applications and also the second one is to uh keep an eye on performance because uh every time we are bootstrapping a new application so um we can make use of some techniques like preloading our static assets and also using service workers to uh um create cash um for static assets we can make use of those strategies to uh you know manage some of the performance performance issues um but we need to keep an eye on our performance and we also need to have a thoughtful transitions when we move from one micro app to another we essentially unload the uh first app and then reload the second in the browser so we might encounter the white screen so in order to avoid uh seeing the white screen we need to add some uh kind of animation or spinner uh that uh you know gracefully transitions the user from one uh micro app to another so let's look at the demo of this so i've already started uh our application so here i have uh the home uh running in port 4000 and i have my our um albums uh micro front end running in 4001. so each micro front end is its own micro application and it bootstraps it its own up app uh and let's see how when we move from home to uh album route uh how the transition happens you can see that we saw a spinner and it uh gracefully transfers us to the uh second uh micro app which is hosted in 4001 and similarly when we move to events it loads our third app which is hosted in 4002 gracefully uh so we need to think about how we transition from one application to another so that um although we are loading new application it uh it uh feels uh like a single uh page experience for the user and the next uh pattern that we are going to see is a spa with embedded uh micro sentence so in this case uh um there will be a shell application which will uh host other micro front ends uh so the shell application is responsible for routing the traffic to different micro front ends uh uh based on the route um so uh shell and all the micro frontends will uh make use of the shared uh components sdks and styles um so let's uh look at the two different integration patterns uh uh that we can use uh for a spa with uh um embedded micro fountains the first is uh we can publish our micro front ends as library packages and these packages are can be referenced in the shell package.json file uh so that whenever the shell application is built it will pull the code for the micro sentence and bundle it together and have a single bundle which is deployed to the server so there are advantages and uh considerations in this approach the advantage is that since uh all the uh micro fountains are added during the build time we can do tree shaking and remove duplicate code um this makes the bundle size much smaller and it improves the performance but on the flip side there are some considerations that they are not truly uh independent because uh whenever you make any change in your micro front end you have to publish a new version of the package and that the new version should be updated in your package.json file in the shell application so whenever you deploy your micro front end you also need to deploy your shell application so there is a data dependency and uh micro front ends uh must use the same angular framework uh and version um or uh microphone tense can be created as a you know vanilla uh js and there should be minimal communication between your microphone and the shell application uh you you should not have a lot of input and output events um between the micro front end and the shell application the second uh uh uh integration pattern for us power with the embedded micro sentence is a runtime integration so in this case the shell application dynamically loads the requested micro front-end assets in the browser at runtime uh by adding the script tag and the element tag so how this works is whenever uh microfrontend uh is requested in the shell application the shell application will make a call to get the latest version of the uh micro front end uh and then load the latest asset files on the uh um browser by creating the script tags so all of our micro front ends will be uh running uh in their own containers in the asus cluster and whenever we um you know deploy new changes uh uh it also deploys a version.manifest.json file uh which actually maps the static asset with the latest version that has been deployed so shell application will get this a manifest file uh read the main.js version that's a latestly available and then add a script tag for that so this way um the micro front end is dynamically loaded at run time so there are some benefits and considerations to this approach so the benefits are the microphone 10 and the shell application are truly independent you can deploy your microphone separately and the shell application separately um whenever the browser is refreshed our cell application will pull the latest copy of the micro front end um and uh we can uh uh have dynam lazy loading of the micro front ends only when uh the particular microphone is requested the script will be downloaded um and then uh um it's well suited for micro front ends but back and forth uh interaction um because it's very similar to uh having a um i mean moving moving uh two different routes in your single page application uh so uh uh it will render the microphone tensor uh much faster and uh there are some considerations uh for this approach as well so the first is bundle size because um the microfunctions are not known during build time uh when it is a loaded on the um browser at runtime we need to be cognizant of the bundle size uh so that we can approach this in two ways uh the first is a create about micro front ends as a vanilla js so that the bundle size will become much smaller without the framework um the second approach is to use the same versions and packages across um micro front end and the shell application uh and the reference uh global uh uh object uh uh to uh download these uh common dependencies so we can uh by uh using webpack externals we can achieve this so in order to use our webpack externals we make use of the ngx build plus uh a package uh that is created by uh manford's tire uh so um we add that to our project uh and we generate uh ngx build plus externals so what this will do is uh it will uh load angular files as umd bundles and uh it will map the umd bundles to a window.ng uh global reference so that uh when shell and microfrontend requires these umd bundles they will get it from the uh um window.ng object so uh here uh uh the other considerations framework compatibility uh since uh um microfrontend and shell application uh um need to uh reside together uh it's best to use the same uh version and framework otherwise uh we might encounter uh um some unexpected dog archers um and also when uh there is any breaking contract change in the micro front end then at that time we might need to uh deploy our shell application uh for example if the shell application expects a particular input property and the uh micro app msc removes that input then then now we need to uh make that change in this shell up so a demo for this uh pattern so in this case uh um like when i first load the uh application you can see all of my rxjs and angular core and other dependencies are downloaded as umd bundles uh and when i move from one uh micro front end to another the first uh call that happens is uh uh searching the version manifest.json so it has a mapping of main.js with the latest version of main.js and then uh the uh uh shell application um uh downloads that are main dot json version and then also adds a script tag to the uh body so this way uh uh the uh microfrontenders are dynamically lazy loaded um and also uh we get the uh latest copy of the micro front end every time and the last pattern that we're going to see is a spa with a module federation so uh webpack five model federation provides efficient way for sharing libraries between uh your shell application and micro front ends uh so um in angular 11 webpack five is available as an experimental feature so we are making use of the angular architect model federation plugin in order to create this demo so when we add this model federation uh plugin it uh creates a two webpack configs um so one is for the micro front end and one is for the shell application in the micro front and weber config you can see um there's a new plugin for model federation and it um you specify the name of the micro front end uh and the entry file for your micro front end and also the modules and components that you want your microphone to expose you can specify any module and component defined in your micro front end um here and shell application should be able to consume it uh uh easily um and then uh the shared object has all the uh libraries that are shared between uh shell land uh micro application um on the micro front end uh so here uh there are two properties singleton and strict and both are set to true here um but you can have a different combinations here uh which i'm not going to go into detail but uh setting these two to true um means that we are going to use the same uh singleton version uh um i mean a singleton copy of the uh um singleton copy of that library and we are going to use the same version um so this is recommended to have a same version and framework across all your microphone tense and shell applications so that we don't run into unexpected um change detection issues and unexpected routing issues so similarly in shell lab also you have this shared object uh with the libraries that you share and also the remote object so in this you can hard code the uh microphone 10 and the uh js file that you want to download but uh in instead of hard coding it here we can also do a lazy loading by using a uh load module load node remote module function that is exposed by the uh module federation plug-in um in order to do lazy loading of your microphone ton so let's look at a quick demo of this uh we're going to see the same music store application so here uh when i move from uh my uh home page to the albums you can see that uh uh downloads the remote entry dot jsr file and then adds a reference of that file uh to the dom so uh by this way uh the micro front end is lazy loaded and we are able to easily manage the dependencies between our shell application and the uh host application by using a webpack 5 model federation so this concludes the demo for all of our microphone 10 uh architecture patterns uh so the key takeaways are there are no one-size-fits-all pattern um so based on the necessities of your team you can choose either multiple spa or a single spa with a microphone tensor um so for when you use multiple spa approach um uh you can use a different frameworks and uh versions but with uh um you know a spar with embedded micro front ends you cannot uh use multiple frameworks and versions uh to prevent unexpected gorgeous and uh it's not that you cannot but uh it's not uh you know recommended to use multiple frameworks and versions um and then microphone turns are suitable for large ui applications uh in which multiple teams contribute uh it's not uh uh it's not needed for uh smaller applications and uh uh the third is uh um when if you want to build reusable micro front ends it's best to build it in uh vanilla js so that they can be consumed across multiple applications so without uh um considering the framework conversion collision problems uh and then uh uh we have to keep the interaction between micro front ends and the microphone tension application to a minimum uh and we need to use custom cache busting solutions when we uh do uh use uh dynamically loaded micro front ends uh and uh um finally micro frontals are suited for scaling uh teams for example if you want to create a new pod to work on a specific uh feature then uh instead of disturbing any of the other teams you can set up a new team and have them work on a micro front end and integrate it with a bigger application so that's a very important benefit of having a micro front end that you can scale teams so in conclusion by using the common design system web components sdks shared infrastructure and the micro front end patterns we are able to create a platform for our ui application development and enable teams on delivering core business values this concludes my uh session today i'm very happy to answer any questions thank you for listening to my talk

Channel: ng-conf

Views: 1,302

Rating: 3.5599999 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: y5X1WdETuCg

Length: 23min 45sec (1425 seconds)

Published: Mon Sep 06 2021