 Okay so we'll get started. Welcome to ThoughtWorks Talks Tech. Thanks for coming everyone. My name is Cam Jackson and tonight I'm going to be talking to you about micro-frontends and specifically how they can help you scale your frontend development process. So a little bit about me. I'm a senior consultant here with ThoughtWorks and I'm a full-stack developer. So I've worked all over the staff, worked on frontend staff, back-end infrastructure, but the work that I'm proudest of is helping large organizations to scale their frontend development processes and to do frontend development really well. So I'm just going to do a quick poll of the room just to get a sense of where everyone's at with frontends that are stuck in general. So I'll give you three options. So if you could just put your hand up if frontends totally are not your thing, you don't really know anything about it at all and this is all pretty new to you. Cool, we've got at least one honest person. So number two, you know a little bit about frontend but you know it's not really your strong suit but you can do it. Cool and frontend is your main thing you're really good at it or you're an expert and you really love doing frontend development. You're either really good at it or you love it. You don't have to be but maybe you do it but you hate it. You just find a new job. Okay cool. So we've got a big spread all across. So that doesn't really help me it'll be better if you either all were really good or all were really bad but we're everywhere so that's okay I'll threw it up. So right here's the obvious analogy. So microservices you know a lot has been written about microservices and people talk a lot about the various kind of advantages and disadvantages and trade-offs that we have with microservices. So there is obviously an analogy here to micro frontends otherwise we wouldn't be using that name but the most relevant thing here the most relevant comparison that we can make is we're talking about taking something which is really large and scary and nobody really wants to work on this thing anymore and breaking it down into smaller pieces which can be worked on independently by autonomous teams. That's kind of the main significance here or the main comparison that we're drawing between microservices and micro frontends. So I said before a lot has been written about microservices on an order of about four thousand times as much comes up in Google if you look for microservices versus micro frontends so I think I need to give this talk a few more times but yeah so a lot of attention has been paid towards China to improve our back-end code using using microservices but I think a lot of organizations are still building large kind of monolithic front-end projects which they are struggling with but there are more and more organizations who want to try to split these up especially with organizations realizing that a high-cloaded user experience can really be a differentiator for their products and for their company front-end projects are getting more complicated they are getting larger and so we need better ways to actually manage these things and maintain them especially over time. So let's jump right into an example this is an application that I worked on about two or three years ago now I'm 2015 and 2016 is when I worked on this for any accountants or former accountants in the room this is a profit and loss report and it's just one of the one of the reports which you might have in accounting software now this profit and loss report is a is a full and complete application it functions totally on its own it has its own set of dependencies it has its own automated test suite it had its own build process its own deployment pipeline and if you knew an obscure URL and you were a customer of this product you could log in and you could actually see this profit and loss report like this in production. In practice however what people really saw was this so I said before that a profit and loss report is only one part of what would be caught to an accounting software suite so you can see up here maybe you can't see it in the navigation bar right at the top this little button here which says reports is highlighted ever so slightly because that's the section of the application that we're looking at so this profit and loss report was the micro front-end one of the micro front-ends that I worked on but it's just one part of a larger application so MYOB essentials for any Aussies or Kiwis in the room you might be familiar with MYOB this was one of their most popular products and it was a great big huge monolith which nobody really wanted to touch it had been around for quite a while and they were and they were struggling with working on it and that all of what I just said was true of both the front-end and the back-end so what they were doing was gradually trying to decompose this thing you know they wanted to make the profit and loss report that was existing in the product a little bit nicer work a little bit better and so they decided well rather than just work on the existing one maybe we can rewrite it and we can do all of that work outside of the monolith so rather than continuing to work on the monolith and to extend it and make it more complex instead we're going to do our development work outside of it and again all of that was true for both the front-end and the back-end I think a lot of organizations are doing this kind of work for their back-end but not as many people are doing it on the front-end so basically the way that it works is the easiest way to do it is to just look at each of the pages or sections or views in your application and just assign a team to it and say you now you own that that feature and the the most significant thing here is to is to really focus your teams around business capabilities so for example you might have a dashboard team or a sales team or a reporting team which is the team that I was part of so they really are oriented around features in the application rather than having say a forms team or a validation team or a styling team and so the reason we do that is that we can then have a team who owns that entire feature from the very start of the development process from from the analysis and the ideation all the way through development and testing and deploying it and then the ongoing maintenance of that product as well so that team owns it from beginning to end from the top to bottom of the tech stack from the front-end all the way to the back-end and the infrastructure as well so that that actually gives you that can be a really powerful concept because you now have a fully autonomous team we were able to work on this profit and loss report totally independently of anybody else in the company for the most part and deliver value to production without having to coordinate with a lot of other teams so we do have a essentially a parent-child relationship here so a little bit of terminology the profit and loss report application itself that was our micro front-end and then the overall on the outside there's kind of this I've heard it called a few different things a wrapper application or a shell or the parent app and that's kind of the bit that sits on the outside and owns a lot of those cross-cutting concerns and pulls all of the micro front-ends together into a single cohesive product so we do have a parent-child relationship here and as with any complex system especially when we're talking about multiple teams the hardest part of this tends to be integration so ironically micro services tend to be difficult to integrate because there's a big network barrier between them and how do you cross that network barrier do you use rest do you use an hntp or do you use some sort of an event queue like getting the integration right is one of the more difficult things to do well now ironically micro front-ends the integration is also difficult but not because they're separate it's actually difficult because everything is sitting on top of each other in a single browser in a single page and you need to make sure that you know one micro front-end doesn't cause one of the other ones on the same page to fail so that that's where the integration becomes a bit difficult so the parent and the child and also the children on the same page all need to cooperate so let's go through a little bit of how we can actually make it happen so firstly let's talk about how we actually integrate these things and how we actually pull them together so you might be tempted and again i've worked on projects that have done this before for anyone who's worked on sort of modern javascript projects this would be an example of a package.json file if you're a java person this might just sort of like you or your pom.xml if you're using Maven so what we're looking at here is is where we're building an application called myawesomeapp and we've got some dependencies and the dependencies that we're building in here are the dashboard maybe the profile page and the reports page so you might be tempted to what we're doing here is we're basically publishing our microfinance as libraries or node modules and we're pulling them in at build time and compiling them all into a single application which we then deploy now my general recommendation would be not to do this so the reason is it highly couples your your deployment and your release cycles so again i've worked on a product that that worked this way and the problem is every time we wanted to deploy or release a new version of one of the microfinance everything basically funnels through that one team that owns that the parent or the wrapper application and the product that i worked on what that meant is that the team who are managing that application basically became a release management team because constantly all they were doing was fielding requests from other teams saying hey can you bump this version can you bump that version can you integrate my changes for me please and i definitely wouldn't have wanted to work on work on that team because that's a that's a pretty boring job for them to do when they had their own backlog of features which they needed to be working on so yeah this really sort of tightly couples the teams and didn't get a lot of those benefits that i was talking before about teams being able to work on things independently so this is a tweet from a couple of years back if your micro services or microfinance i would say need to be deployed as a complete set in a specific order and save yourself some pain and just put them back in a monolith and i think that's really true that that previous product that i've worked on all the pain that we were getting from trying to integrate these things and deploy them as a single a single set it probably would have been easier if we just had them all all back in a monolith that would have made our lives easier right so instead of integrating things at build time and compiling things into a single application we can integrate things dynamically in the browser at front time so what we're looking at here is just an html document again it's my awesome app that's what we're still working on and our first strip tag just pulls in the the bundle bundled up from pub js file which is for the general kind of top level of the application maybe that's got a routing or a navigation or a login sort of stuff and then underneath that we put a container on the page really there should probably be three different containers there and each one of those containers would be for the various microfinance that we're pulling in so the awesome dashboard that we pull in knows that it renders itself into a particular div it knows that sits home on the page and that's where it lives and by doing this we're basically dynamically pulling in our code at runtime and joining these things into a single application now the cool thing about this is i've shared these things here as though they're all being deployed in exactly the same place but really these URLs could be going to all various different servers and each one of those servers could be being managed maintained by a different team working on their microfinance so the team who works on dashboard they can push a new version of awesome dashboard.bunnel.js they can push that out to production without needing to talk to the team who manages this html file and so then if you go in and refresh your browser subject application of course the new dashboard will come in and it will be there live in production without having to talk to anyone else another way you can do this and this is common is you can use iframes iframes are not my my favorite approach but they do work they are a valid alternative the big advantage that you get with iframes is it gets you it makes it a lot easier to have good isolation between in your microfinance so with this approach you don't really need to worry as much about the styles of one microfinance stepping on the toes of another microfinance it is less flexible and it doesn't allow you to do certain things like managing the having more close integration so you can manage the history and the navigation and deep linking and that sort of thing between your microfinance and it also makes it more difficult for them to communicate with each other for the parent to communicate with the child or for the children to communicate with each other i'll talk more about the communication a bit a little bit later so yeah i guess with iframes the advantage is that they're much more isolated but the disadvantage is that they're much more isolated now when i was talking about this concept to a developer much more experienced than me he said this is not new you're not as cool as you think you are we've been doing this for years we used to do it back in 2002 with good old server side includes in Apache and of course he was totally right you don't need to be doing any kind of fancy in the browser dynamic integration to make this work you could just have this is just a template file being rendered on the server and pulling in our various microfinance and just glue them onto the page so this is i would still call this this microfinance and he actually asked me well i can do this using this way which is still called that microfinance and i said yes and the reason is you can still work on these three things independently and have the have the teams who maintain them work or challenge to each other and deliver value to production without needing to go on this but this is a little bit more limiting it doesn't allow you to for example dynamically pull in different parts of the application depending on what the user is doing and you can't load new content client side without a full page reload so it's not as flexible but again this this is a totally valid way to do it okay so let's talk about some of those cross-cutting concerns that i mentioned earlier so authentication this one it actually isn't that difficult to deal with usually so kind of the go-to way that i've used in the past tends to be that parent application or the wrapper it would usually be the one that owns the authentication for the app and the authorization because it's it's like i said it's a cross-cutting concern everyone probably needs this everybody needs the user to be logged in and it doesn't really make sense for everyone to to build their own login page it certainly doesn't make sense for the user to have to log in separately to each page in the application so for example the way it might work is when you load the index of the app it's going to give you a login screen and when you put in your username and password or however your your auth works you're probably going to get back some sort of cookie or or token or something like that again this is just how often auth usually works and then you just stick that that token into your cookies and that will be valid for the entire site the entire domain so if you are then loading your micro front-ends to work sitting on the same page in the same domain they have access to that cookie and they can just send it with any request they make to the server so by logging into the parent application you effectively become logged in for all of the micro front-ends which are part of that parent application so the micro front-ends basically get their the auth for free so that's kind of cool the one disadvantage there is i i've mentioned a couple of times that it should be a fully featured self-contained application with that approach the micro front-end is really relying on the parent being there to log you in so you know as a fullback maybe the micro front-end can be logged into independently but usually the way it would work is it just inherits the the auth from the parent app okay while we're talking about communications with the server I shamelessly sell this from Sam Newman who wrote a great book on building micro services and this is part of that book this is this is a different thing he talks about an architectural pattern called BFF who knows what BFF stands for can someone tell me yeah back end for front-end does anyone have a different thing that BFF stands for best friends forever yeah so this I love the dual meaning of this so if you're not familiar with it BFF is back-ends for front-ends so basically what we're saying is each front-end gets its own back-end and the sole purpose the sole reason for existing of that back-end is to serve the needs of the front-end so it serves up any data that I might need or handles requests that it makes but it does have a double meaning because that back-end and that front-end they are best friends forever so that that's kind of nice that makes me feel warm and fuzzy so when Sam wrote about the BFF I think the main sort of thing that he was envisaging is when he talks about different front-ends he's talking about a mobile a native mobile client front-end maybe a web client front-end and they may have quite different requirements so it might make sense for each one to get its own back-end which just serves the requirements of that front-end you know behind the scenes they're probably getting the data from the same downstream services but they can present a nice little facade which makes sense for that front-end but I would take this a step further and I would say especially on the web if each one of those colored boxes there represents a micro front-end maybe each one of those micro front-ends can get its own back-end now again you don't have to do things this way and I've worked on projects that have had either way maybe there's an API which serves all of the data for the whole page or maybe you have APIs which serve just the data for each individual micro front-end but I do like doing it the latter way having a separate BFF for each micro front-end because again it gets you really good autonomy of your delivery teams so if I'm working on the on the front-end for just that profit and loss report and we've built a back-end server which serves just the profit and loss data and that's the API I can evolve these things like together and I own all of that and I can work on it without having to go and make sure that somebody else working on the shared back-end doesn't have you know their own changes which are conflicting with my changes the other interesting question here is about service discovery and the question is do you have each micro front-end if it has its own back-end know where that back-end is does it know the URL that it makes its requests to like the full the full server path or does it get told by the parent and again you can kind of go either way here I like having each micro front-end know exactly where its server is because it gives it really good independence it can be deployed on its own it doesn't rely on somebody else to tell it what to do but at the same time there's something to be said for that dependency injection of having the parent app be able to tell each front-end where it might get its data from so either of those ways can work okay let's talk about style so with your micro front-ends not only does your product have to look good but ideally you want it to be consistent because probably the only thing worse than socks and sandals would be one sock and one sandal with one converse so we want to have a consistent look and feel across our whole product yeah and I would say this is probably one of one of the hardest bits to do well with this architecture because CSS is inherently global inheriting cascading historically has had no module system variables or namespace or really any encapsulation of any kind so if we're going to say that you know this part of the page has its style sheet and this part of the page has a different style sheet and if they're built by two different teams how do you make sure that they're not going to totally clobber each other so this is hard to do well so some of those features for CSS do exist now and they are coming but you know browser support is not always there and polyfilling CSS is a little bit more difficult than polyfilling say JavaScript APIs so I would say if we're going for an architecture like a micro front-end kind of architecture we really do need a layer on top of CSS which gives us you know some some nice abstractions or especially encapsulation so let's talk about a few options sas sas is okay it's not my favorite but you know it's very popular a lot of people know sas a lot of organizations have existing sas code bases that they're using specifically the feature that we might be talking about with sas here would be the way we can use its nesting in order to give us some sort of encapsulation so if on our page we've got a div which is where our confident loss report lives we can build a select like this we can select that div using its id and then anything which we say inside here selecting for h2 or table what it ends up with is it doesn't select all the h2s or all the tables on the page but it only selects the ones which are inside that confident loss report div so this is a fairly basic way that we can get some encapsulation of our selectors so that I know that when I write some CSS over here to try to style the table I'm not styling some other teams table and they're not going to come and yell at me and say what the hell to do to my table the reason I say sas is not my favorite is because some of its features while very powerful can be quite easy to abuse it's easy to end up with very complex sas code bases which are kind of difficult to reason about it also has some nasty native dependencies which in my experience make it difficult to set up in development environments so that's a bit of a deal-breaker for me but if you're already using sas this is a handy feature for for microfinance so something a little bit better in my opinion would be css modules I think that's a perfect logo for anything css related so css modules again the thing that we're up to here is some sort of encapsulation over our selectors and the way that this would work is for example I just write a normal starship which maybe selects everything on the page which has the classical container but then there's basically a compilation step which transforms just quite old container into something which has been named space so it's got a prefix at the front and the way that this then works is we actually load our stylesheet from a JavaScript module so there's a little bit of a react example here if you're not familiar with react don't worry about it but basically what we're doing here is we import our styles module which is actually a css file but we're going to pretend that it's a JavaScript module and what we actually get is that styles thing that we've imported becomes an object and if we look at the dot container property which is here this is our dot container property what it actually results to is a string which is this namespace property here so by pulling in our stylesheet like that we can just automatically get all of our namespace selectors and then we can apply them into the don so we can just add it to the class list of the element or if we're rendering a reaction kind of we can set up just the class name on our component now the final way that I'll talk about is if we're talking about doing some of our styling in inside a JavaScript module you can take that a little bit further and actually define the css directly in JavaScript so instead of writing a css file and writing a css module we can actually just put the styling code directly in our JavaScript module so for example using inline styles and again this is uh this is jsx this is not valid javascript unless you have a compiler which is transforming it for you but just go with it if you haven't seen react before basically we're defining a container component here which accepts some children which are going to go inside this container and it's a div and we apply some styling to the div and it's got the margin top now if you haven't seen this before you know for for many many years people were saying please keep your javascript and your html and your css separate we're kind of doing the opposite of that here um that's a separate talk um but the nice thing about this is that it gives us really good encapsulation of our styles because that margin top which we've defined there's no possible way that can ever go and end up somewhere that we didn't expect it to go because we've only applied it to this div or we've only applied it to this this component which is our container component um so that's kind of the key thing here when we're talking about trying to reuse the same style multiple places on on the page for example our our margin top which we want on all of our container elements rather than defining a class which we share across the page we want to define a component which we share across the page now this is getting a little bit away from micro components but the reason i'm talking about this is because that model of sharing components tends to work quite well with a kind of a micro components architecture um i've thrown this example in here as a further one um if you are doing css in in javascript just as an aside um inline styles are a nice style of components is even nicer so if you're working in a react landscape and you want to explore doing this is in javascript go and check out style components um it's a pretty cool library so the takeaway from this is don't try to reuse styles or css or classes try to reuse components because they they work better for this kind of architecture so i have been talking a little bit about react this is the first time i've gone into specific libraries or frameworks um react definitely does not have a monopoly over the micro front-end space really there's nothing stopping you from using whatever framework you like as long as that framework can be can be made to behave and say you live in this one spot on the page and don't go doing stuff with the entire page so react is quite good at just being told you render yourself into this div and this is where you live and you do all the stuff inside that div and there might be other things on the page going on which it doesn't need to know that react does that well so if you're using a different framework whether it's amber angular or whatever you can have a look and see whether your framework will behave nicely and we'll just we'll just sit in one place on the page i would say that a library which has a strong component model like like react does does tend to work well with this architecture especially when it comes to code reuse and reusing those components like i was talking about a minute ago but actually one of the benefits that you can get with micro front-ends is it does give you a bit of flexibilities that have um some diversity in your tech staff if you want to have react rendering part of the page and you want to have something else running a different part of the page you can do that i wouldn't recommend trying to collect every single framework on one page that's probably not not a great approach but hey if you really want to i'm not going to judge you um but one thing that this is really useful for is um the example that i that i spoke about earlier the real app that i worked on the the accounting app that was a backbone js application and we started using react to build the various micro front-ends which would sit inside it and so those frameworks they were perfectly happy to sit on the same page together and it gives you an opportunity to experiment try different framework move from something old like backbone which you don't want to use anymore and gradually start moving to something like react which is maybe what you want to be using so it does give you a bit of a bit of flexibility because you're not building one single application which all has to be the same framework you can build multiple applications and use whatever framework makes sense that's a good question the question there is about a parent and a child using different versions of react um that is actually moving on one of the frequently asked questions which i have at the end of this this this presentation so i'll get to that um okay cool so i mentioned a little bit before about this code reuse and reusing components um this in general is a good idea um so one thing that people often want to do is pull out common components um and put them into a library so they can be used across various different micro front ends so if we've got a button for example or any of the things that we've got here um we might want to reuse that button across our different micro front ends this has two main benefits one is it gives you really good consistency if everyone's using the same button component all your buttons are going to look the same you don't end up with all different ones in different parts of the app and secondly that code reuse makes things a little bit easier if i come on and i start a new project i don't have to build a button i just use the button which already exists and i can go about my day and do something more interesting than building a button uh this can also become a living style guide and that's pretty cool um so rather than having a great big long document which lists these are all the colors that we use these are the this is what our buttons should look like these are our styles you actually just encode that you actually write that in code and that defines this is what our style is um and if i'm a developer and i come along and i need to make a new feature look like the company's style guide i don't have to look at the style guide and then figure out how to translate that into code i just use the components that somebody else has written and it automatically kind of fits with the with the style guide that exists so that's that's pretty cool um this is not limited to just boring things like um buttons or labels or forms for example um you can also use this to build more complex things like layout components um so the bootstrap responsive grid is something which is out there and tons of people use the bootstrap responsive grid to lay out their page you could and again i would say um that that works well but rather than trying to reuse classes and reuse stylings let's try to reuse components so we can have components which say it takes up two columns out of the 12 or whatever it is and that becomes a nice way to build our applications um and feel free if you're building one of these libraries feel free to have you know fancy logic in there for example if i'm building a an auto suggesting auto completing searching drop-down box that's going to be quite complicated or a day bigger is another example of something which is quite complicated and there's going to be quite a lot of logic in there feel free to have that logic live inside your component library but what you want to be careful of is don't put business logic in there so it's okay to build a an auto completing um drop-down search box but don't make it an auto completing customer drop-down search box or product drop-down search box right because you're starting to put your domain or business logic into something which is a shared library and that often ends up going badly because now I can't change the business logic without breaking other people um other people's applications so to stick to to ui logic rather than business logic in here okay let's talk about testing um so how do we test these micro front ends now the cool thing about this is each micro front end as i've said before is pretty much a self-contained um application which exists in its own library so whatever would be good practices on any front end application we can apply the same practices to each individual micro front end so each micro front end should have its own comprehensive test suite and we should use all the same rules that we usually use for automated testing so we want to focus we've got that that test pyramid which you might be familiar with but we want to focus mostly on unit tests right lots of unit tests on the functionality and then move up and do some sort of application level integration tests and then some functional or end-to-end testing on the top um so essentially not a whole lot changes here however you would test your application normally use that same testing strategy on each of your micro front ends and if it's been working well for you in the past it should work just as well in a micro front end architecture now the one of the common questions that comes up here is what about integration testing of the entire application i want to have in an automated fashion some really good confidence that all of my micro front ends are going to come together nicely compose together on the page and actually work as a single application and that's a great question um i would draw the same analogy here to micro services so when it comes to micro services yes you want to make sure that all of your various services integrate together correctly and do actually function but you don't want to go too far with it um i'm sure a lot of us have probably worked on these kind of really large largely scoped kind of integration or functional end-to-end test suites which cover a lot of different systems and they tend to be a massive pain to maintain they tend to take a long time so to write new tests they tend to be difficult they tend to be quite flaky just randomly breaks for no kind of logical reason um so don't i would say don't spend too much time trying to build that that integration level of testing across the whole app it's definitely worth doing don't get me wrong i'm not saying don't do it but focus on only the things that you can't test at a lower level so don't go and try and test all of the various features of all of the micro front ends at that at that top level using a functional end-to-end test suite instead just focus on the bits that you haven't tested elsewhere so for example if there is some integration if there's some data which goes from the from the parent down to one of the child apps maybe just make sure that yes that data has successfully gone from the parent to the child and i can see it rendered on the page or maybe you even go even simpler than that all you do is try to load the url where the whole application is located and just make sure that yeah the title of that is there so i literally i just look for a string that says dashboard and if i see it i know that my dashboard micro front end has successfully rendered itself onto the page and maybe that's as far as you go if you don't have a whole lot of integration between the two you're just trying to make sure that it has actually rendered on the page and everything else you can test it at a lower level right so i'm talking about cross-component communication here and i would probably say that second to styling this is the next most difficult thing to do well so as a general rule don't if you don't have to communication between the the micro front ends tends to couple them together and it tends to mean that i can't change mine without worrying about how that's going to approach a different one on the page similarly even between the parent and the child the more chatty they are the more communication that goes on between the two the more difficult it becomes to evolve them independently of each other so to take one example that profit and loss report that i showed earlier if you were looking really closely it had the company's name on the report there was a different page in the application the profile page where you could edit the company name and save it so what we could have done would be to have when you edit it on the profile page that somehow instantly propagates across to the reporting page and updates what would be shown on the screen but we didn't want to link these two together so instead what we did is we just go via the server so on the profile page you update your company's name that gets saved into the database and then when they're using navigates to the reporting page we would always go and fetch new fresh data from the server so that we could guarantee if you've just got an updated your company name we would have that latest data pulled down from the server so going via the server is one way that you can you can avoid having your micro front ends talk directly to each other now of course that only works if you've got two different views or two different pages if you've got two micro front ends right side by side on the same page and you want to change one thing over here and have that show up over here that's a little bit more challenging the first thing i would say is if there is a lot of communication going on between the two maybe it should just be one micro front end maybe try to draw a big line between the two of them you're actually just making your life more difficult and you should just merge them but if you do decide that it's a good idea to have the two separate and have some communication between the two fine but think carefully about how you do it try to define some sort of protocol whether it's a message format that they send between the two and actually think about what that contract is because it is a contract and once you define it you need to make sure that it's stable you need to make sure that the two sides adhere to that contract and they both respect it okay cool so we're almost there let's go through a couple of frequently asked questions of course people want to want to ask how micro should they be and the answer is it really doesn't matter and again i think i see the same answer given to how micro should your micro services be really that there's no i'm certainly not going to give a line of code metric or anything like that you just need to figure out what works for you so i would say if you're dealing with the pain of a large monolith make it smaller than your monolith so make it small enough that you don't have that massive amount of complexity and coupling that can come with a large monolithic code base so smaller than that but don't make them so small that they don't make sense if you can't define a solid business functionality reason for that micro front end to exist then maybe you've gone to fine ground you've gone too small so yeah there's no there's no single answer to this and the other frequently asked question question which i'll answer is what about download sizes so this is not directly your question but it does relate to it um so if you have five different micro front ends um on the page and they all use react and they all use the same version of react um we're probably wasting a lot of bytes going over the wire here because if there's got lots of different micro front ends and they all have the same version of react embedded inside that that compiles javascript file we're forcing our users to download react five times right now react is not that big but you know you are wasting bytes and especially if we're talking about mobile for example you know every byte kind of counts you know there's been studies that um if your site takes more than four seconds to load like i don't know a quarter of your users just go not too hard like people are really impatient and especially if we want to think about people who are in you know developing countries and countries that don't have internet connections that are quite as fast as what we're used to in Singapore and we should care about those people and we should make sure that they get a high quality user experience as well and we really need to think about how we solve some of these problems so this is not easy to do um but if you're using something like webpack for example and some of the more modern build tools they do have options that allow you to say yes i want you to compile all of my dependencies into that bundle.js but not this one so maybe if you know we've got a whole bunch of different microservices and they all use the same version of react maybe they don't compile react into their bundle and instead the parent application can embed react on the page for them and then when they show up they just assume that that library is going to be there for them so that they can do that thing now the complexity comes if you have two microfinance that want to use different versions of react right um that starts to get a little bit more difficult um now if they are bundled up and included inside your bundle it does work and i've done this before that this team can be using react 15 and this team can use react 16 and they will actually coexist on the same page together and just do that thing in their individual divs but if we're going to try and um share our dependencies so that we can reduce our download sizes you make that a lot more difficult um if you do want to upgrade well upgrading a shared dependency is really tricky you've got two choices you either say okay everybody needs to upgrade this this major breaking change at once and we all need to release in lockstep that's going to be really painful um so you need to try to figure out some sort of way that we can have both 15 and 16 there on the page maybe the parent application supplies the default version or the latest version and anybody who wants an older version they can bring along their old their old version um these things do work they are tricky and there are complexities and bugs you can come here from trying to have the same um the same libraries multiple times on the page um but in general these things work so there's no there's no easy answer to this but solutions are there um if you if you want to try them um and yeah that's fine excellent questions yeah so the question here is about for those who didn't hear it is about um I mentioned ways to try to namespace the the CSS into each micro-frontend so the one micro-frontend doesn't clash with another but what if the parent defines its own styling how do you stop the styling of a parent um conflicting with the various um child micro-frontend yeah there's no kind of easy way to solve that problem um in general I think if you're working on something new I would generally say you just need to make sure that the parent only defines um its CSS selectors to work on very specific types of the page keep the the parent or the wrapper as simple as possible so that you know it's pretty much just a navigation bar for example and so as long as nobody else has um you know a deal with an idea of nav or a nav element with an idea of nav you should be safe where it becomes more difficult is and where this this architecture tends to be used most commonly is if you're dealing with a large monolith which already exists and already has a huge CSS code base that comes with it and you're going to try to put um a micro-frontend inside of that and you need to stop that huge CSS from from clobbering all of your own styles um yeah there's not really an easy way to do with that unfortunately you kind of just have to accept that that stuff is there a lot of the time it's not a huge problem because if the parent is defining um you know uh a color for the entire site because that's the that's the brand's primary color you probably want that color or if they're defining you know other things which are common to the page a lot of it you want anyway so it tends not to be a big problem um but yeah it did bite us in the past where you know when we ran our application like this it sorry like this it worked but when we went and put it inside this thing it it did look slightly different it was just a matter of mostly of testing those things seeing how things looked um and then trying to adjust um you could do other things like trying to look into um like resetting all of the CSS properties um so you can do things like that to try to set everything back to like a base standard and then style things after that um so yeah yeah yeah yeah if you if you were trying to put the microphone inside different applications and they were all going to bring a different star sheet it wouldn't become a lot more complex then and yeah you probably have to look into doing some sort of reset so that you have a base to work from other questions so can you speak up a little bit so the question if i've understood it correctly is is about caching so if i'm deploying a new version of the dashboard bundle without touching this file then i can't put a unique hash of the version of that bundle.js which makes it more difficult to invalidate the cache that yeah so um e-tags is probably the way that i've used to do that in the past so you can use e-tags for the um for the server to basically tell the client whether you've got the latest version or not that's what we used in the past the parent application did just have a URL like that um i mean yeah caching caching is always difficult to get right um but yeah i think the short answer is you can usually use e-tags to get around some of that or you can always manually invalidate the cache on the back end whenever you do a deployment of that bundle.js whatever you're using for caching many cdns of io to manually invalidate and say serve a new version of that file now so that would be another approach yep to what degree have you thought about the capability of this to apps and how to purify two apps in particular is to see more ota being available you're talking about like native mobile apps yeah that's a really good question so the question is about um how how we could use this sort of pattern for native apps um it's not something i've done personally before um in fact i've never worked on native mobile apps before so i probably can't rely on a whole lot of experience to talk about this but certainly if you're using um something like reaction native um you could probably use it to to dynamically glue some of these things together um i know uh in the past apple has had a lot of restrictions on pulling pulling code over the network and running on the client but i hear they've been okay with that for reactionated so if you are using reactionated you could probably um you could probably explore using this for other kind of native code um i'm not sure you could you could probably do it but you might be limited to to this kind of approach like building different pages of the app independently and then compiling them into a single app at build time you could probably make that work but again if you're going to do that you then have to be wary of the fact that if i want to publish a new um a new part of one part of the app i need to publish a new version of the entire app so um yeah i'm not really sure how that could work but it's a really good question it's worth exploring especially as apple has become a user on OTA yeah yeah there are a few ways someone there described it to me as yes you can't turn your camera app into a person person shooter but you want to extend your camera app that's okay yeah yeah yeah so you probably could i've never done it but i would love to hear from anyone who has any other questions for loading the the front ends um so the question is about um loading these directly from a server or going through some proxy um again i've used both i don't think it really matters um either approach can work um the benefit of using a proxy is you can have all of the requests going through a single place it means you don't need to worry about things like the cause for example if everybody just makes their requests to a relative url of slash whatever and maybe it's like slash like my my bff name and then whatever the route is um that's one thing that i've done in the past um that means you don't have to worry about cause it simplifies some of that but um again it then means that that proxy becomes a piece of shared infrastructure which needs to be like managed across all of the different teams so so it becomes a an extra point of coupling um so having the having the server url directly in there and each thing knows exactly um where to go or where to load these from that can get rid of some of that coupling so either approach works perfectly fine yeah so let's see i haven't too long in a program without probably our three members do i need to look and say it's necessary for us to apply this or make sure yep so the question as i understand it is about whether it's worth using micro front ends for a team of say three people i would say there's probably less benefit where i've seen this work um the most and where i've seen this have the biggest impact is when you have a large organization and you have several different teams and you want those teams to be able to work independently of each other but i think the same thing applies to microservices um i think having a single team with lots and lots of microservices um probably introduces more overhead than just having um having something which is a little bit more consolidated um again like if you have a large product and you're scared of how big this model is might become and how complex it's going to become yeah sure split it into into micro front ends to get some of that advantage of um i guess in that case you're you're you're chasing the advantage of reduced complexity and reduce coupling between the various parts of your application by drawing great big lines between them that say the dashboard is totally independent of the of the profile page rather than having them coupling into something which makes it more difficult to change but so you're still going to get those benefits but you know there's other benefits there which you might not get which is about independent teams so it might still be worth it um but it's probably less worth it than if you're working in a large organization so how difficult because i mean this opens the question yeah you start with the team of three but what happens when that team is the team of 20 next year how difficult to migrate to this doesn't make sense to what's the cost of you know yeah gotta help us future proofing yeah in this case yeah um to you know to do that and what frameworks might there be to make that easier for someone yeah so i think prematurely adopting a complex architecture for the future is always obviously a dangerous road to go down because you can add more complexity than you then you take away um but i think it's not difficult to at least leave the door open for this kind of architecture so if you are starting as a team of three you really just want to be wary of especially CSS would be the main thing you want to be you want to be wary of how well you can scope things and focus things so that if you do want to start adopting this kind of architecture in the future it's fairly easy to just say well this thing was in this div and it's not integrated with the rest of it um so i think you actually touch on a really good point which is that beginning to adopt this architecture from something which was previously a great big monolith is really easy and i've worked in a few organizations who have done this they had something which was big and scary and no one wanted to touch it and they literally just pick one feature um some places even just picks like a single button and they said we're going to experiment with react here and there's one button in the whole page we're going to render that with react and everything else is going to stay the same right and that's how they started just to experiment and see if it would work and when it did that's that then they said okay let's take a page let's take a whole page and we'll rewrite this page from our old thing which we don't like into our new thing and it's actually really really easy most of the time to get started with migrating from one architecture to the other so i don't think it's a big thing that you need to worry about up front um but but yeah there are some some small things that you can do to make that migration a little bit easier in the future if you've got that in mind and styling would be probably the main thing just because css can be difficult to wrangle into something which is encapsulated when you're starting with something which is uh which is kind of all over the place yeah so um uh i understand the meaning of having each method by hand the whole BFF yep uh so each thing can hold and and like yep so a way of why is BFF having different projects for example like we have an action on the page that likes to follow with the company profile name there's some logic behind it like yeah because that company profile BFF would have it yep yep yeah that's a good question um and i think if you kind of look out um so the the question for anyone who didn't hear it is about um if we're going to define um BFFs for different parts of the application there might be some logic which you want to be the same across the across the different BFFs so i think the excuse me the most straightforward answer to that question would be would be downstream um so a lot of the times these BFFs become fairly simple gateways or pass-throughs that's really just i can make a single request um to say fetch me the data for this page and the BFF here knows exactly what data that front end needs and it's able to go and fetch that data and aggregate it from different places or if you're talking about a mutation um that request is coming in from the front end and again this thing might be a fairly simple pass-through and it knows what downstream service that data needs to needs to be sent through and that's where that's where that common business logic lives so that we don't have to duplicate it across multiple different places um so i think with the BFF pattern in in general um it's a really good point it does have benefits but you definitely don't want to be you know copying and pasting your entire kind of um kind of business logic across all these different BFFs these should usually be fairly thin um and most of the code that's in here should be to do with the stuff that this thing needs there was a question over here somewhere yeah isolation but the better it is yeah but there's a lot of opportunity of coupling classes yeah across the world that's like it's all the same it's all the same so it's like it's that linear but it's okay yeah yeah it's a best time to go to a different position yeah let's try it yeah so how do you manage the micro front end so the question I think is about um having this macro front end's work well in responsive sites especially because the the parent application might have complex logic about how things should be laid out depending on the width of the page and the micro front end needs to work well in that kind of style right yeah so um yeah responsive stuff can be a little bit tricky um I think in general if we're looking at a page which looks like actually let's use a more visible example um so this page that we worked on was not built to be responsive so pretty bad example but what we did do is we we we knew roughly the size that we would be contained in right so I guess this was a it was not an explicit contract it was a bit more implicit which was that we knew um we knew the size of the thing that we'd be in right and so knowing that knowing that the parent was going to put us in a particular sized box we could make sure that we behaved nicely inside that that inside that box um I think in general responsive design works well you definitely want to have a view of what the entire application looks like at various different sizes but I think there's also something to be said for kind of breaking that problem down and thinking about that problem individually for each part of the page um so for example this problem loss report we should what we should have done was come up with exactly how this thing should look at a whole bunch of different resolutions and and what that actually looks like probably mostly doesn't really matter about what the rest of the page looks like as long as each part of the page makes sure it looks good at a particular resolution they're probably going to look well all together at that resolution yeah so I think again that sort of comes back to the problem of um in general we don't want too much styling to be going on at the parent to be affecting what's going on inside the child and if you can find ways to namespace our css or reset the css within a microfinance so that it does have kind of ultimate control over what goes inside the cell and it's not interfered with too much by the parent that's probably a better place to be rather than letting the parent kind of reach in and do random stuff with the layout of all of the different microfinance okay so this uh this part of the the WRAC so does it work fast with clients who are doing all this we know the fundamental difference between this to be is that the server determines your URL yeah based on your URL it determines what is the output html yeah but the client uh client rendering is like normally taken here if you're talking about react right yeah it's it's based on the mapping the router so how how does this methodology works in dropping so you're talking about how this would work um the comparison of whether this works better for client rendering versus server rendering and it should be with things like routing so um i'll have to be a little bit speculative here because i haven't used this pattern with server rendering i've only used it for kind of single page apps with with with client rendering but i mean there's there's no reason why you can't why you can't use i mean this would be an example of some server rendering here where it's up to the server to to glue the various the various bits together and maybe when the server is rendering this html template based on the the URL that was requested it figures out which one of these things should include on the page so that it can render so the correct microphone and gets gets rendered into the view so something like that would definitely work again i've only used it for used it with with client-side rendering and like you hinted at again the the route the URL of the page tends to become the the biggest communication mechanism between the components so i didn't talk too much about it before but usually the URL is kind of the one source of truth that all of the different frontends are looking at and based on what that URL is i know that it's my turn to render myself and you know it's not my turn to render myself based on the route that we're looking at um and it can also become a bit of a communications mechanism as well if you're sort of redirecting from one part to the other you know this um this microphone might say i'm going to navigate to a different URL and passing some parameter in the URL and that's where um you know a different microphone and picks up from and takes that data in so it can be a basic sort of communication mechanism between the two and i think the same thing would work on the server as well if you're doing server rendering so one microphone end might just do document dot location equals whatever in order to make the request go to a new location the server figures out which microphone should you render based on that URL and you could pass in some metadata as well and then the next microphone and picks up picks up from it so i think it could work for both with a caveat that i haven't tried it so i am going to stick around for a bit so if anybody has any more questions which they don't want to speak in front of everyone i'm happy to take more questions um i have been given a couple of things which i need to mention otherwise i get in big trouble um we do have a thing called friends of thoughtworks which you can see on the side over here so you can stay up to date on what's happening at ThoughtWorks Singapore so there's a QR code there which you can scan if you'd like to become a friend of ThoughtWorks and of course the other thing i have to mention is that we are hiring ThoughtWorks is a pretty fantastic place to work everything which you've heard tonight i learned while i've been working as a consultant with ThoughtWorks it's a really good place i recommend it so you know get in touch with me or reach out to um to one of our recruiters that i believe they are they are around somewhere if you're interested in jump um but thanks for coming everyone