Hello, so I guess you have obviously seen the topic you probably saw some description, which is why you're here welcome Thank you for coming. I hope this is an important topic for you or an interesting topic anyway It's a mixture between some patterns that I'm going to show and also some code actually is mostly based on my personal experience But it is about microservices and front-ends In this talk, I brief you want to give an introduction This comes in two parts one a shorter part where I'm explaining What this is all about where it came from why the need and why am I even talking about this and then the second part I'm going to show you five different patterns for micro front-ends What were they thinking? What were people thinking when they came up with this idea? This is probably very Common to you many of you have seen something like this, right? This is a typical Layered architecture with what people often call technology stacks You usually get something and they're drawn at the bottom with the databases, you know the drill, right? You get the DBAs database administrators or all sorts of other people dealing with some persistence data storage messaging You oftentimes have different teams that are responsible for the back-end development for the development on the server side And you get front-end which today of course splits in two major areas One is the web that a lot of people of course are having applications in and also native mobile This split has been so dominant for so long in the industry. It's sometimes really hard to forget. I've even seen people Talk about themselves to identify themselves. I've heard people say I am a back-end developer It's as if it they are or I am a DBA What happened though and you could have a whole talk about microservices here What happened at some point people realized while there were some efficiencies to be gained by having one team of DBAs Deal with all the databases The efficiency was not their core concern anymore. What they were most interested in was cycle time They wanted to get out features very quickly It was a competitor is a competitive advantage to get features out quickly and this structure doesn't really help Your problem is if you want to get a feature out you have that team Coordinate with that team coordinate with that team and so on. I've been working with organizations. We're deploying Interproduction several hundred times per week in a setup like that. That is clearly completely impossible So what did the industry do basically they turned this on the side and they said we want to do something like this We want to have vertically Oriented functionality we want to build microservices and we want to have cross-functional teams that are responsible for them these teams are often In the Amazon language, they talk about two pizza teams They talk about these big American pizzas and they're saying the team should not be larger than what you can feed with two pizzas 8 to 12 people cross-functional Obviously to clear up a misconception obviously not everybody in the team needs to be able to do everything But the team as a whole should be able to do everything from interacting with the user to their persistent store And when you're set up like this you gain the two benefits that the original people the original thinking behind microservices Wanted to have and that is on the one end Independent evolvability the idea that I can evolve the service independently I can make changes without having to coordinate with somebody else which increases throughput and reduces cycle time And the other one not so relevant for us tonight was this idea of the last rewrite that you can actually Say I don't really have to write rewrite ever a big monolith I don't ever have to say I want exactly the same thing but on a different technology stack I don't know whether you've been on projects like that They're usually quite painful then you hear words like ugly words like feature parity and all these things And you're just doing a huge amount of work just to go from one tech to another Microservices and the project that avoids that because you can start you could imagine these colors mean different technologies You could start changing your landscape But that is as I said not the key thing for tonight tonight. I want to focus on the independent evolvability Because what happened unfortunately is more like this picture We've seen this quite a bit if you think that gray line here Is the limit between the client and the server the web browser at the top and the server side at the bottom We saw lots of teams writing very nice microservices on the server side, and then they had one big Application if you will one big piece of JavaScript. There was consuming all those services That is oftentimes known as the front-end monolith There's a huge problem with this kind of system you're getting All the inefficiencies I should say of microservices you have to do all the work to now put a lot of different services Interproduction you have to have lots of different build pipelines You have to have complete infrastructure automation You have to find a really complicated solution for monitoring to aggregate all the data back You have all the effort you have to do for microservices But you don't gain any of the benefits because again you're not getting the independent Evolvability because everything is in that big one front-end monolith Some part of the blue service is smeared across the orange services somewhere visible and each time this team here that middle team Wants to release that service they again have to coordinate because they're still in the end working with the monolith So this is worse than not having any microservices having microservices on the server and the monolith in the front-end is the worst of all worlds Really unfortunately that happened quite a bit. It was really unexpected And I know many people who were there I mean I worked with ThoughtWorks in Europe many people who were there at the original days when we discussed microservices when James Lewis worked at At the GDS the government digital service in the UK Where they started building systems like that and it came unexpected because we all had assumed that it was clear That we meant something like this. We really meant that the services had the user interface would interact That was something that didn't occur to us, but we saw it happen quite a bit To the point and know how many of you know this ThoughtWorks publishes a document called the technology radar We do this twice a year and at some point in November 2016 When we were designing or we are creating the technology radar we said this is a major problem 2016 already the microservices paper came out early 2014 and rather than saying don't do my Don't do these front-end monolith. We thought okay. We should be more constructive. We should tell people maybe what else they could do and Then reluctantly We created a new term front and sorry micro front-end It wasn't really necessary We thought because we had microservices envisioned to include the front-end, but everybody or not everybody But many people didn't do it. So we said never mind The development community has spoken micro service is the thing on the server side We need something on the front-end. Let's do micro front-ends and that's what we Stipulated in that edition the situation changed Even more as we noticed that a lot of the development effort that we were seeing was shifting From the server side to the client side what we saw is and this is was in volume 18 in Whenever that came out November 18, I think We said one of the major themes of that radar was even that the browser is bulking up There's more work in the browser I've personally been on projects where over 70% of the code is running in the web browser and only a small fraction It's running on the server and of course if you then think back about the picture Then you have a handful of little microservices truly micro mini services But all everything else is really one big monolith and you are exactly where we were 10 years ago So that really can't be it So we thought okay Micro front-ends what does it actually look like how would you design or how would you build micro front-ends? And over the years given that we talked about this in November 2016. We've done it before We've a thought works. We're not a small company anymore We've explored different options in different contexts around the world We started to realize that there were certain patterns and these are the patterns. I want to present to you In a certain order, I'm going to show you the most simple pattern first and then the most complex pattern last That does not mean you should progress from one to the other. It just means there's five different ones There might be further variations. I doubt there's something completely different if there is I'd love to hear about it, obviously and Sometimes one pattern is applicable. Sometimes you might want to use a combination depending on what you are actually building The simple most pattern is the web approach Basically going from one page to another page and all throughout I'm using a hypothetical example of an e-commerce site where you can buy shoes a Lot of it actually all of every all the examples I show you are actually rooted in real examples Sometimes I'll show you a little bit of code that is changed to protect the innocent But I'm always putting into that context. So what we are seeing here is we have service number one That is responsible for Rendering what we call the article detail page So there is a page where the customer on the e-commerce website Can actually see details about the product and they can make up their mind Whether that is the right product they want to buy this will include a longer description of the article Probably some high-resolution photography Maybe even like a 360 view and so on like a lot of detail about the article and Then there's a second service that is doing the order capture This is the service that actually when you click on the put it in the shopping basket button That then gets activated and does something else on the server side to remember That you as a user who's logged in Actually wants to buy this pair of shoes What is important to remember is that the idea of micro services was that they store their own data So this service number one here will keep most of the information are talked about Service number two will have to know a little bit about the products Maybe the price for example, and it is totally normal in that case to duplicate this information To have some data feeds that are asynchronous that are feeding service one with all the detailed information and service two Probably only gets a small amount of details I'm not really going to talk a lot about the back-end architecture tonight. Actually, I'm not going to talk about it at all I just wanted to highlight that assume that those services can act completely independently as fast user requests go And if you then think oh my god data duplication It's actually totally fine and in many ways is actually the right thing to do For example, if you're putting a pair of shoes in the shopping basket and the price changes You generally don't want the user experience where you have to tell the user the price of the item in the basket has changed I mean if you put something on a wish list at say Amazon or so and you keep it over there for a month That will happen But normally actually these services keep a copy anyway for a better user experience, but anyway The most simple pattern is service one renders a complete HTML page. This could be a little Little JavaScript application that allows a bit more interactivity and renders the whole thing When the user then clicks on a hyperlink to say add this pair of shoes to my shopping basket It goes to a different URL the URL at some point I'm not showing this here is routed to a different service and that service then renders it back and shows the shopping cart With say that new pair of shoes added to it and maybe other things that as a user I've placed in the shopping cart beforehand If you can use that approach It's the simplest approach one of the reasons why the web works so well is because you have that nice abstractions You have URLs and pages and URLs can go anywhere. This is really easy to do Unfortunately in many cases is not sufficient because the users have higher expectation for example they might want to have Something like this and most e-commerce websites do this actually you actually have a little bit at the bottom at the top Here where it says you have so many items in your shopping basket or even maybe showing you the total price and so on Again assuming we have those two services How would you deal with that? If you do server side composition that means you are rendering HTML on the server still Which is a common and valid approach especially if you have a lot of traffic if you have a lot of customers and Visitors on your web page It can make sense. You could do it like this. You do server side composition So service number one renders the HTML for the entire page So when the URL comes in there's a piece of software that decides this URL should be rendered by service number one Because it is the article detail page It renders HTML which leaves conceptually a little gap here and in the HTML code it puts Usually an include this is a directive. I would recommend to use edge side includes It's a little bit more standardized But many of the servers can actually do also server side includes ESI is just a standard and many of them support it and this is actually correct syntax So when service one renders the HTML it includes this little bit here and says at this spot Please include include navigation. It should actually say shopping cart here Please include that and then you have varnish or nginx or something like that While they stream the byte stream for the HTML page back They pause briefly when they get across one of the ESI directives. They will then Resolve this make a request to service to that returns HTML which they insert into the stream When that is finished they continue serving the data from service one and the web browser sees one HTML page Of course, you can easily see how it can expand this and you can see how when I copy pasted this code together I made a mistake you can of course use that for navigation as well You can have an heavy navigation here at the top or for example if you think about an e-commerce website again on the front page You usually have multiple different components coming from different back-end services like recommendations for you or like a shopping like what you call it like a Set of images like current offers and so on and so on and you can do that very well when you do server side rendering With edge side includes the key thing here is if you think about it, of course once this is set up The teams can work independently service to can completely change how they render the shopping basket What they want to display without ever having to talk to service one? The only coupling you get is at some point service one needs to include Include the edge side include they need to put that into your code But I think that coupling is totally fine because you only do it once at the beginning and In a way you need to do it anyway because this page needs to somehow express the intent that they want to have the shopping cart, right? But after that they can work on their own I'm not going to go into complete detail here But I want to show you this as an example of one of the myths I've heard this many many different times that people say but but but If I use server side rendering and server side composition, I can't use caching or Caching doesn't really work and all my pages need to be cached And if I do server side include then everything has to have the same time to live and so on so what is this is? This here is actually a little bit More from a debug version This is the complete varnish configuration to allow you to do different time to live so different caches So you can see this at the top there in the vcl fetch function. You can see some basic Matching and it says if the request URL is for a page Then the time to then actually do edge side includes and the TTL you can see that here The time to live is 30 seconds. So all those pages will be cached for 30 seconds That's usually quite a long time if you talk about the high traffic website If you get hundreds of requests per second You're reducing the load on the servers that need to render the pages by a factor of over 1,000 Obviously don't think about ours or so 30 seconds is actually a long time when you need caching on a high traffic website But what you say is and oftentimes websites want to do that They want to include some tracking so they can track with where which web user is going which of course doesn't work when they get Served cached pages. So what we're saying here is if the request URL contains the Pass segment track. I'm saying actually no, please. Don't cash this ever and Here, this is just an example a little trick. We're saying if this is the URL if it includes track For the moment being return a 999 status code that doesn't really exist and then here we can just do whatever we want We can just insert anything into the response. So even though varnish here is working as a reverse proxy It is composing pieces from different websites together from different services HTML one can be cached for 30 seconds You could put five hours in there if you wanted to but another piece not only can be not cached But it can also be created dynamically for each individual request There are other myths around service had composition, but this is probably the most common one that says oh everything has to be together What is a little bit more tricky? I'll be honest with you is handling of the assets Style sheets and graphics and so on if you have all these microservices and They all render individual pieces of the HTML. They all need other resources like as I said images and CSS This is not a simple topic and you have to at least spend some thought on it a standard approach is to say for CSS use something to do namespacing in the CSS so that every team can actually Work separately There will be some duplication if on the odd day where your company really changes the corporate colors You will probably have to do a synchronized release because you have the corporate color in multiple CSS files I don't think that's a major problem oftentimes people say oh we have to have one sheet It can only be in one place, but really try to make the trade-offs having it in multiple CSS files Gives you the independent evolvability if you deploy 500 times a week That's the more important thing than actually having the corporate color only in one place because that only changes every few years normally so There are a nice number of approaches, but I had to make a call at some point This is a talk by a colleague of mine that talks in detail how they did this at one client in Europe The the QR code is just you well As a recall a video recording of a talk where they describe in greater detail how they use mod page speed Which is of course a module for NGX to do this in a different way where they use mod page speed to actually get together All the JavaScript and the CSS in a high-performance way for a high-traffic website to actually also get the benefits of the Microfrontend with the assets. I thought about trying to pull all of this in But then we would have been here for two hours and not one hour, so I give you the QR code so a quick a Quick detour I want to talk a little bit more about independent evolvability because I haven't done that enough This is a real example from a website that was doing classifieds for selling used cars and The page looked roughly like this you get the picture or multiple pictures of the car You get a description but on the website it's also dealers who can sell used cars and The case was that he wanted the contact information for the dealer on that page Let's say under the picture now imagine you are the team That is writing the classified page service the team that is building this page and you want the dealer information in there You happen to know that there's this thing the contacts detailed service another lovely micro service And then you discover that they even have an HTTP endpoint and they can give you JSON documents And for the dealer information you can see this here It says is dealer true and then there's a street a house number a city and a postcode This is a German address and you can see things like the postcode is a number for example You see no quotation marks because I don't know what it's like in Singapore, but the postcards here are numbers So they see that and then the blue team things. Oh, we need to be independent We don't have to talk to the yellow team fantastic. They've built a service We can just call their service and then they do that And the code flow in one way of describing it looks roughly like this The classified page service calls the contact detail service gets this bit of JSON and then renders it in the correct place Into the page and this is how addresses are formatted in Germany You have the street name the house number the zip code and the city All well right the blue team is happy. They could implement it. They didn't have to bother the yellow team Now the rollout continues throughout Europe for example, and they go to the UK Nothing different on the classified page, but our friends in the contact detail service They start to have UK addresses and then they return something like this You get an address in London, you notice suddenly quotes appear around the postcode because in the UK the postcode have numbers They didn't even know that that was happening. They consume that Jason and they print this Water Street 76 null because they were expecting a number which it isn't anymore and of course if you know the UK This is completely wrong in the UK The house number should be before the street name and the postcode should be behind after the city So they thought they were doing the right thing the blue team But I don't think they really did because they coupled themselves and Again think about the idea of micro front-ends. We said we wanted every service to own their own user interface Here the mistake was they didn't own the user interface. They provided data not user interface So a better approach would have been for the contact detail service to render a little bit of HTML So they give me like two paragraphs and of course this all semantic I can format it as much as I want the classified page does a server side include or an edge side include and The address appears in the right spot What happens if the UK gets into the fray? Nothing because they know what they're doing. They know how to render. Yes, correctly The classified page service doesn't have to do anything because they get the right document So sorry the right rightly formatted address So the idea really is you want to keep all that logic together in the service that should own it They should own not only the managing of the contact details But the user interface so when they own the data they can make changes and they don't have a dependency of course That meant for the blue team though when they wanted to include it They had to talk to them to say hey we discovered your Jason interface Can you give us a user interface? Maybe they said yeah sure there is one already you missed it or they said okay? We don't have a user interface. We'll write one for you or They're saying we don't have a user interface. We're super busy with something else Couldn't you do this and maybe you just the blue team writes this makes a pull request and they accept it That sounds like more work up front But in the long term you really go in with the original goals for each service to have their own user interface and for them to Be able to evolve further independently Okay, going back to the patterns Here's a third one client side composition This is sometimes helpful When you have very very high traffic websites that needs to have a little bit of dynamic content I remember doing this for a project in the UK for a TV station And of course when that TV program was run there was a huge amount of traffic on the website most of the Website didn't need to change. It was just basic information This could be pre-rendered you could use a static site generator such as Jack Hill to actually do all the rendering and create the fully Created HTML pages, but they wanted to include a little bit about the user Maybe the logged in user name saying hello or you have messages or something like that so one trick here is The service here would render the HTML But would also include some JavaScript and the JavaScript could then asynchronously when it's running here Connect to service to and retrieve some HTML and it would know At which point to place the HTML in the DOM tree in the web browser So again, they're completely independent this service continues to leave to deliver HTML fragments But rather than being assembled with engine X or varnish or another reverse proxy Ultimately, they're in a and they're Assembled they are put together in the web browser It's not a pattern. So you see that much anymore, but it is still a useful one to remember What is more common these days? It's the next pattern and it's this one here and that's client-side rendering It's not only composing at the client side, but it's rendering at the client side. So it looks very similar Service one again returns a lot of HTML and some JavaScript But the JavaScript here knows I need data from somewhere else But you don't really want to depend too much on the data as we've seen can lead to big problems So what they do is they actually fetching some JavaScript from the other service That JavaScript is then run in here And then that JavaScript knows what JSON data to get to actually then render the HTML on the server side And this is an example actually for my own personal website how simple something like that can look like on That web page. I mean I was really tired when running my own website I've always having to deal with WordPress and all the security problems and it doesn't change that often to be honest So I also switched to a static site generator But I wanted to show people that I'm doing some work with open-source software And so I wanted to show an up-to-date view of when I committed something to GitHub And I didn't want to regenerate the website every night or so. I wanted that to be up-to-date So I used that approach and what I'm doing here as you can see in the top rows I'm just I'm creating a div that has a name of course And it says loading hardly anybody sees it most of the time the internet is fast enough And then I'm loading a script from somewhere and then here. I'm just saying using jQuery still This JavaScript function show repos and this code is then going to GitHub is consuming the API is Returning a JSON document that JSON gets rendered and down here. It says target personal repos and the rendered HTML that was rendered in the web browser is then being put in that place Which is why people don't generally see the loading bit but now The fifth and most complicated pattern. I'm going to spend a little bit more time on this We do want or many times these days. We want to have single-page applications Oftentimes they're nowadays also called PWAs progressive web applications It doesn't really matter for what we are talking about here Whether it's either one or the other and what the real difference is between the two of them But the idea really is that in these systems you generally don't do any rendering of HTML on the server all the rendering is really done in the client and The framework that I'm going to use for the example is react.js But I'm sure it will work in the same way with Angular which a lot of teams and thought was also like and probably also with voodoo.js So what's happening here? Like in a normal react application or in many standard react applications We're sending really only a tiny tiny bit of HTML You know like I don't know whether you've seen a react application It is used like ten lines and it basically says I'm a react application load some JavaScript bootstrap code And then all the other magic happens all the data is actually being loaded from the server using JavaScript And all the rendering happens in the browser So what we are conceptually doing is it's sending a little bit of HTML The web browser then requests JavaScript and that JavaScript can actually pull in some JSON to be rendered If we want to compose this what we need to do is if we want to have it from the other service think again about the shopping cart and the shoes It is pulling JavaScript from the other service and that JavaScript the JavaScript that was pulled from service to is then making a request To service to to actually get the data it needs to render HTML What is so important about this one? It's only one tiny box away from the big anti pattern This is the front end monolith Right, it looks almost the same Look at the difference This is terrible and that's fantastic But you know why right because here I can maintain independent devolvability if that service changes if the data format changes This team that is responsible for service to can also change the JavaScript to adapt to the different service in the different functionality in this case if they change the data JavaScript came from the other service and they can't change it. So this is the good pattern and I want to give you a brief explanation of how on one real project. We actually built this using react.js and I need a few minutes to do that, but we have some time So at the top you can see we're defining In the outermost usually you have something that is sitting like a frame around that loads the further one So if you go back here usually you don't have service one two You usually have like some Frame the initial application that maybe shows is the user logged in or maybe doesn't show anything It's just there to load the rest and then you don't only have one more service usually have like three four five different services So this is in the outermost frame and it's a it defines a JavaScript object called Externals you can call it whatever you want But this is just the things that are being pulled in from the outside and we do have a little bit of coupling here So we're saying we will have this cart preview tile tile is just what we called it in that context and it's a component and There's a route, which is part of how react actually works and then at the bottom We need to export this of course for the rest of the JavaScript code to know about it And here's one function that I will show you in more detail what it does But it's only being called once the react application is initialized. It says Load all the other externals and here does it in two steps It first loads the front-end config that I'll talk about in a minute and with that front-end config It then calls load the actual front-end So it's a two-step process it first gets a configuration and then it loads the additional front-end and that is an important point So load front-end config looks like this It fetches. So let's assume. This is the blue service deal It goes to an endpoint and Says get me the config resource that is a little jason document and that basically contains a mapping from a known name Like shopping cart to some resources Usually like most of the time just the URL where to load the JavaScript and the CSS from Could be a little bit more of information, but that's basically the idea Yeah, and the rest I don't know how much JavaScript, you know the rest is just boilerplate You need to do something with authorization and if it works you're returning the response that Jason This is the return value here and gets into the promise and then load front-ends will have the configuration What is super cool about this approach is if you're running this frame You can configure where to load the other services from and if you've ever worked on a large application That has like tens of services and you're working on a normal laptop with 16 gigabytes of RAM You can run into trouble. I've seen in solver's developers say they need laptops with 32 gigabytes of memory Because it really doesn't all fit into RAM This approach makes it quite nice. Let's say you have like ten different services There's this framing service and then you have like ten different components What you can do is you can run the frame on your machine and you can configure the frame to say Load the service the URL the endpoint for the service. I'm currently working on load that from my machine and The other eight services you configure the URL to actually point to your continuous integration or to some other staging environment and They will load the JavaScript from there and the JavaScript will also contact a service running on there So you can run the full application on your laptop You have only the service that you need running on your laptop everything else you can pull in from somewhere else You don't have the complexity of running all of this of having to check out the source code running all the front-end pipelines You can just point at something else, but you still get the experience of having a full website It's quite an important benefit. I would say What you do next is and this is the second part here You actually need to load the front-end and you can see here as I mentioned you get a bit of config back We had here load front-end config that gets passed in here and you can see How in the config I'm looking up cart CSS So this is where I need to load the style sheet from as I mentioned And this is just a naming convention.  It's very easily done in JavaScript Now the interesting part is in this conflict dictionary that came back from the endpoint here I'm getting the card JavaScript and that is a URL and I'm loading this and I'm passing the name To actually put it in the right place Loading the script we tried lots of different things the easiest way I'm not showing the source code for this method here for this function But the easiest way we found is simply to create its script tag and put it into the DOM Which will make most modern browsers actually load the JavaScript and then what it will do by loading them You will have access to this exports to a variable that I'll show you in a minute That was exported by the JavaScript you load it and you can see again We're using promises here and then we're just pushing everything that was in the exports into the externals thing that we defined before So now externals The object we defined on here has a reference to all the things that were defined in the JavaScript for the cart and they can make use of it and Then because I don't know how much you know about react and redux We actually use the store here the redux store and we add a reducer That we can now get from the JavaScript. We just loaded so cart.js Included the reducer we can take it here because we've assigned it and Added to the store so the react application now is Extended a little bit because it knows about the reducers in that case what I'm not showing you in the store To actually keep them separated you can path prefix you can put The state in nested objects in the store So what we're saying everything that the shopping cart wants to store is actually under the prefix cart And if you have like the article detail page, so the ADP would be under ADP and so on so again The teams individually could work they could store things in the react store in the in the store in the web browser Without actually treading on each other's toes and again could work completely independently Of course in theory you can see some duplication He's he cut CSS cut j s card card and so on and if you're loading 10 services You might want to have another little function where you can just pass in the spring card And then you have created a convention and then you could extract that into a method or Because you're only writing that on a two-year project. Maybe once you can just copy paste those four lines It doesn't really matter in The end of course you're chaining up all these promises that you're creating here with a load script and Then if you see we're returning them here From the init one and then whatever the react application wants to do it loads a javascript I will admit this is slightly simplified because you do want to handle the case that maybe one of the servers Under certain circumstances might not be available and then maybe you want to be okay If the shopping cart doesn't respond you have a problem people can't buy anything But maybe the recommendation engine just doesn't work at the moment. Maybe you just gloss over it and ignore it So there is sometimes a little bit more Like a couple more if statements if you will but in in structure. It doesn't really change very much What is important to remember is at the top here? We're seeing some coupling and what is coupled is which of the components am I loading and that's okay? If you're writing an e-commerce site is okay to at some point write down. Yes I will have a shopping cart. That's not much of a commitment. That's actually okay You don't have to dynamically discover that you suddenly have shopping carts It's okay in my opinion to couple this what is decoupled is where to load the assets from That already is giving you some benefits because it allows you to split your application onto this laptop service scenario What is important here is also that is also I Mean user experience is most important But what we have learned over the past few years developer experience is also super important And one thing that this solution offers that you can do is it allows you to do hot reloading so If you think about how this works in the end it just loads some JavaScript But what you can do on your laptop is because of the way react works If I start having a front-end pipeline for this service number one or the cart service and I say if the JavaScript source code The web browser notices that and can refresh it in the same way you would do with a normal react application That is quite different. I mean an alternative approach that on purpose. I'm not showing you in slides is another way of composition which involves the services building npm packages and Then the build pipeline for something outer takes all the npm packages combines them But that is a bad idea because you can't get the developer experience right because then for each package You offer each component you're changing you always have to trigger the pipeline for the thing that combines all the npm packages And that means immediately at a minimum you have a one-minute turnaround time between changing your code and see in the web browser It's not a good user experience. Sorry, not a good developer experience And the code here at the bottom. There's nothing secret somebody could write a little JavaScript library for it I'm sure somebody has at this stage. This is just very generic code The fact that cart appears here is just my laziness and trying to keep it a little bit more concise for you So what we're seeing is there's some coupling which I think is okay The important thing where to load stuff from this decoupled and how to load something is completely generic There's one more slide where I show you how that is actually then being used So this is now again the frame where you can see in The top box how it is actually hooking this up in the routing mechanism in react and what we can see here We can now because of the setup we have done previously We can just say externals which is that variable that was exported that has all the symbols and we can say just ask for the Cart just ask for the cart service route and we can add that under the route in react that works fine And then in the second box you can see how we can actually then use the react component again There's nothing wrong. You can actually this is valid and correct react.js code I can just say externals dot cart preview tile This is now the tile that was loaded from some completely random URL that I could configure and it is going to be rendered at that place what we often do is the The service that responds to this API config That is something that is often configured itself through environment variables So when we deploy it we can actually set this is where you can find the other things and then Well to repeat this so there's some coupling here again. I hear coupling is bad I think it's actually okay here again if you render the article detail page It's actually okay to say and I do want a shopping cart here. You need to express this somehow So I think coupling the page that renders something to say here cart preview tile I think it's a totally okay thing because you only do this once Very briefly. This is now the other side This is the shopping cart that is being included and that's very simple in components.js You just basically say what you want to export Those JavaScript variables and then in your front-end pipeline. I forget which one. This is I think Webpack one You basically have to say I mean it's unfortunate. It's called exports here You basically saying what you're trying to build you're building app.js, which is where all the JavaScript gets into and That was one thing that we fiddled with for a long time There's different module formats, and I'm not a huge expert in JavaScript That was the one that in the end worked and we found this out by trial and error So there's ea6 modules and a couple of other things the UMD format was the one that was most easy to actually deal with When you're loading it because that allows you in the easiest possible way to get access to the symbols you've defined I'm sure there's variations. This is not the only approach, but I'm just showing you one approach To show you there is actually not that hard But that's all you need to do and then when you're building say the shopping cart the front-end pipeline is running all the time You're changing in JavaScript file It builds app.js and then the hot loading kicks in and the application actually sees the change in the frame in the whole context So these are basically this is not coupling really. I'm just defining on the side of the included bit What it is that I'm exporting and the key thing to remember here is there is coupling But the coupling is one of I Add this once when I introduced a new component whenever I make a change to any of the components I don't have to touch any of this not Not gonna work so nicely now not what is on this page on the previous page I don't have to touch any of this None of the teams that are working on the individual services has to go back to this bit Except you're adding a new component, but once you're working you're completely independent and similarly You don't have to change that This one doesn't change either. So this is a one-time setup in the beginning and after that you have teams that can work independent of each other They can deploy without the other teams knowing at all. I mean you can have a pipeline for example Into the production system that only builds the shopping cart That is actually being pushed onto a new production server a new instance a new docker container in your cuba to cluster Whatever you want and because the web browser from the user is making a request to the URL It is actually loading the latest version for you and that is basically all I want you to say so I'm happy to answer some more questions Okay I Think I don't know it depends on the use case.  There's probably some reactive There's probably a version for mobiles where this is actually moving underneath You don't have to use peace You can also use spans and then leave it up to the consumer to say whether they want to spans underneath or they want next to each other It really depends, but I know what you mean about the On the layout. Yes, it depends I think you probably have to deal with the fact that there's a minimum and maximum size or something like that At some point you have to talk Possibly. Yeah. Yeah, I mean it depends on how I mean it depends on how much variability you have Is it going from one to ten? You probably have to talk if it's two or three lines. You maybe don't have to talk It's just an example to you Rendering is done by the web browser, right? I mean the web browser places all the elements It could be it could be but I said I mean most of the time And this is an example because most of the time addresses are written on top of each other But as I said if you are in a use case where you're saying, I know we sometimes need them in a long line You could probably rather than peas use a different element and then ask the consuming side If you want them in lines, you need to make sure that they are positioned correctly It gets it depends on the use case. This is just one example in some examples You can do it like that in others you can do it differently Sometimes you also get I mean they might give you a long version or I mean not for an address But for other things you could have a long or short version and then You can pick which one you want That makes sense. Ah Okay, I'm Slowly making my way through it. I should have stood in front of the laptop and press the right button So the question is what do you need to do if you need to share information between the services or especially in the web interface? I guess this question always gets asked. I hope you should add a slide to the presentation Again the number of different patterns, so one very robust pattern is to not do it I mean you can always use something like web sockets or so I mean for example if you think about the shopping cart This might not actually be the worst idea You can also be in a situation where you have a call center and you're on the phone and the call center agent is saying I'm taking I'm putting something to your shopping basket not a pair of shoes But if you're booking flights or so this could happen So maybe the application that is running in the web browser needs we prepare that the state is changing on the server anyway And be able to listen for an event. So what could happen then is that service one is sending a request to its service on the backhand side and That service has some asynchronous or otherwise communication With the other service and that then pushes the change back to the user interface So the two bits of JavaScript don't talk to each other at all And I remember a case where we did exactly that because the application was built in such a way that service one was developed by one Company and service to was developed by the other company and the synchronization overhead and for reliability reasons was just too complicated So we said we would only do asynchronous communication on the server side but of course as I said the JavaScript needed to be capable of receiving through a web socket a change on the server side and then it worked There's two other ways especially when you use react one is You can actually use the store object that you have You can actually have a shared area there. There's nothing. It's just a convention again You can put another you can put a shared object in and then but that becomes a contract between the two job pieces of JavaScript that they know there's something in the shared area We've done this in one application where yeah, the two JavaScript pieces needed to know a selected entity something that was selected and then we tried to have a minimum contract So the only thing that was in shared was the ID of the entity that was shared And if that changed the service could then load its information about the ID from its own back-end service So let's say the blue service pushes a change and says the ID is now changed And then the yellow service would see it and would say oh for this ID get me my information And that brings me to the third way Also in react what is very easy to do because you're sending these actions around Often times you don't notice it But the actions really are only strings most of the time when you write idiomatic react code you're using a variable name That's how it's defined because you don't want to mistype it and so on but in fact it is only a string So what you can do is you can use that as an eventing mechanism inside the web browser so what you can do is the Service one that is running here could say I have now changed something and Then again it becomes a contract what the name of the action is but another service can register for that action and can do something based on that action It is very tempting to always do that because it feels Nice the problem though is you're often getting back into this event Hell that we try to get out of with react because of I mean the one way binding made a lot of things much more Sane, but if you now have one service sending an event that service to listens to and then service to does something and creates an event And then service three and four listen to it you can quickly get back to a lot of the events But these are basically ways of dealing with communication between the two of them with varying degrees of coupling The important thing though is the moment you use either that store approach Or you use the event those do become contracts and I got asked the question ones Do you do contract testing on those ideally you probably should but when I've seen this We didn't do it because it was actually quite complicated to do I can't understand you very well So you're saying if you want to avoid this our web sockets the only option Yeah, yeah web sockets because that means the server can initiate of course some transfers or some re-display in the web browser I mean of course instead of web sockets you can always use polling, but that's usually a bad idea for Yes, it would Sorry without Yeah, if you use web sockets it scales better if you don't use web sockets, of course It doesn't scale as well because you need to do polling that makes sense Yeah, I think it's not too bad. I mean with HTP one you can always use keep alive, so it's using one HTTP connection shouldn't make much of a difference really Yes, but you generally want that anywhere because you you don't want to use I mean if you use an authentication solution You don't want to have you don't want the user to log in into multiple different components, right? You generally want to have in any case I need to need to make the diagrams a little bit more abstract But in any case you generally have some reverse proxy in front that does the distribution to the different backend services And you don't have to I mean the example from a personal website and github shows you don't have to But most of the time you actually have that situation that there's a reverse proxy in between and as I said with keep alive Is usually not such a big deal and to be honest The biggest thing is normally either the libraries or nowadays in the times of retina displays actually the graphical assets And not so much the minified JavaScript that you have written yourself Good point Yes, web components. I didn't mention them, right and also didn't mention one thing. I was wondering whether you noticed that in that approach You have to use the same version of react basically because the the frame is loading the react library And then it is loading all the individual JavaScript. I Think from a user experience perspective. That is the better approach Web components in theory. Yeah, I mean there's standard They've been around for a very long time web components in theory would allow you even more independence each of the components could have their own framework Honestly, I've not seen this in the wild. I've not seen anybody use web components for that Thoughtworks are very curious about it and we are in a lucky position that in some countries including Germany where I'm normally based We work with Universities and we currently have one student writing a thesis about the idea of using web components for micro front ends So that student is really trying to figure out how that would work and whether web components could indeed be a good solution for It as I said, I've not seen it in the wild But I briefly wanted to come back to the idea Of using web components and the freedom it gives you it would in theory give you the freedom to write say This piece in JavaScript in one version of react and that piece in a different version of react giving you more independent evolvability and That is important for the organization that is writing the software but I think everything is Less important than the experience for the user and if you have eight services and they're running in web components And they each have the liberty to use a different version of react then you would load react eight times And that is probably not a fantastic idea. It's independent Yeah, I understand. Yes, what yes, but for I Totally with you web components have a lot of promise and they would solve some of those issues at the moment We often use workarounds right for the CSS. I forget what it's called. There's this module that mangles the names I think it's cost CSS modules, right? And then a BEM is also another one which is more like a convention of how to name your CSS So it doesn't collide with your these are workarounds and yes It gives you web components would give you better isolation as I'm saying I'm super excited about this thesis to see what are the benefits, but it is also for me an observation I mean I work with as a consultant We work with multiple companies not seen anybody do this with web components and I've always been passing myself because I Understand the benefits, but I I want to see what stops people from doing it or maybe it's just because nobody has done it but Yeah, but I mean it has been in its infancy for like what four years five years I mean it should be supported and now with even Microsoft switching to To the new rendering engine to chromium. There's only like Firefox and chromium left or safari is a slight variation I think it should be possible to do it. We'll see maybe if we talk into a yes You would do it but I briefly I briefly wanted to come back to this idea of loading multiple versions of react because just because you could It's a bad idea what we think what I think we can do is we can learn on that case a little bit from The the lot of work that companies like Google and Facebook have done around mono repose I mean they are doing a lot of this on the server side. I'm Unconvinced I've spoken to some people I've even spoken to one of my old colleagues who ended up being at Facebook To write buck which is a special build tool to allow mono repose So I'm unconvinced on the server side, but I think on in the on the web browser It can actually probably make sense to learn some of that when you have to deal with it And then of course what is also important to remember is There's a lot of Security problems in the front-end site in the user interface and if you use that approach and the first team that wants to Switch to a new react application has to make sure the other teams work with that Can potentially be actually a good thing for your security So service such Yes the server side ones are really good When you have really high traffic and you want search engine optimization when you don't want to render something different I mean there are a ton of other approaches to but generally when you have a big e-commerce website I'm using e-commerce as an example here. It works for many other things too You have a product catalog and you want the search engines to actually provide deep links It's of course easier if you render HTML and I don't know what happened to it I think Google wanted to have a minimum JavaScript implementation to actually be able to render your pages for search I'm not sure what came of that. There are all sorts of other ways. There are technologies What was it called again? There's one technology that actually allows you to have client-side rendered But it basically uses the browser part on the server side to render the HTML on the server if a search engine comes your way So it's actually quite good for For the fact and of course it actually creates minimum load. It is easy to cache the browsers are Simple to use these ones are harder to program because you have to use more JavaScript You have to do more testing in the browser and it gives you of course on the other hand more interactivity Yeah, this is interactivity, right? I mean especially the applications We sometimes see that companies are writing for internal use oftentimes. They're replacing applications that were written with Windows forms or whatever the Java script the Java one was called SFX No, I can't remember whatever these applications were they're now being replaced and we're doing this We are building the application that all the dealers that Mercedes-Benz They are selling Mercedes-Benz cars both in China as well as in Germany This is a react application and that's very interactive, right? I mean you can there's all sorts of like these like tile like things and you can configure the car and so on You could never do that with the static web page, right? I mean just to scroll up and down and choose all the different trimmings and so on that really feels like Application for many reasons. They did not want to write native applications for mobile devices it needs to work on a PC for the sales representatives as well as an iPad in the showroom so a web application is the best way and That is often where we see the push. I mean we've done this also for all sorts of applications I mean we did another one for a logistics part of a big Yeah for a big company and the drivers when they drive around They get all the route planning and so on it's a react application You couldn't do that with HTML really and at the same time they still combine multiple things and then you can use an approach like this Oh, it's quick. No, I'm gonna start from the right I'm not sure I understood you mentioned NPM. Are you saying you want to do create an NPM package? I Understand I'm not familiar enough with Angular to really comment on it The one thing I would wonder is if you change the component Can you hot reload that in the browser or do you have to build the NPM package again? I'm not a hampton Yes, that was what I meant with develop experience that you don't want to have to rebuild anything that when you're working on the components I'm sure I mean I've seen component libraries as well If it's small things like buttons and so on that can make a lot of sense You can also share those in a storybook or so But yeah, I know I said I'm not a big Angular expert. So I don't know the most again. It depends. I mean what Yeah, the most common way of doing this today What I'm seeing is that you some form of SSO So no matter where you go it will check whether there's a cookie and if you don't have a cookie normally a JWT token If you don't have it it will bounce you to an SSO server There you log in that bounces you back that takes apart the whole thing issues a JWT token And then the user can continue Now that begs the question of course If I go to say the article detail page here This needs to understand the JWT token But then I go somewhere else to the page in this example here to the shopping page that also needs to understand the JWT token And suddenly you find yourself that each and every service has to understand the JWT token format And you can't take that lightly you can't just decrypt it You also need to check the signature because otherwise of course anybody on the internet could say I'm an admin Here's my token So then you find yourself having the need In both of these services and potentially all of the services to add the code for analyzing the JWT tokens Which we really really don't want to do In my opinion a bad approach, but better than nothing is to create a chat library But chat libraries are usually fraught with problems because then you write them in Java and somebody else is using Even just like Kotlin although it's on the JVM But maybe they write it in a different programming language and then the library doesn't work or somebody forgets to update it and so on So it's not a great idea chat libraries are generally I would say discouraged. You shouldn't do that One option that I've seen being used quite a lot is to integrate that into the reverse proxy, which you inevitably have and for example in engine X One thing that I worked on recently We wrote a lot of the back-end stuff in closure anyway and engine X can be extended with closure And we wrote a little bit of code in engine X that takes apart the JWT token makes all the necessary checks and Then adds that as HTTP headers Onto the downstream services so the request comes in Engine X takes apart the JWT token verifies the signature and then puts username and some entitlements and so on as normal HTTP headers and the services behind here They can believe it now because they know somebody else checked the JWT token further down and of course the most I Know the most fashionable and hip way is of course to use service mesh When you are using a service mesh, then it becomes very easy because you have a sidecar and you can put all of these things in the sidecar You know the idea, right? I mean you have in Kubernetes. You have the pods and you have the your service is running Next to something else that is delivered by the service mesh and then the service can deal with it You are into a layer Yeah, it is yeah, where does the layering start is it still platform? I know it is I mean in many ways, so it is Separation of concerns that gives you more flexibility I mean separation of concerns you already get with the engine X because then the concern of actually verifying the authenticity of the JWT token is separated from the services Yes There's many different that's I said there's many different ways But these are the most common ones shared library not a great fan reverse proxy or then sidecars for authentication There was one more That's what I mean you can have a shared library that does this and That is linked or embedded into all the services or Because even in that example in all these examples, maybe it can only get so much onto a diagram It is always going normally through a reverse proxy and you can put it into the reverse proxy before it actually ever hits the service and Then the service doesn't need to it can just read an HTTP header And the header is called user ID and whatever's in there the service can believe because it knows that somebody else has checked this beforehand maybe I should Say that that is not an approach and this may be coming back to the Angular question also This is not an approach to do components like a drop-down list or a date picker or a button This is an approach for microservices microservices these services should be Business relevant components. I mean if you look at the definition or definition the description that Martin and James wrote about microservices They they wrote down like eight different characteristics and one was a microservice should really represent a business capability a Date picker or drop-down is not a business capability. So this is really more for integrating chunkier bits You'll be loading you that you'll be loading JavaScript code that you have developed your teams have developed That's what this is about Exactly, that's what I'm saying most of the time when you do this you do want to have a reverse proxy in front And they are running on the same domain. So they all get the JWT token, right? Yes, it can get it from the web browser. It is running in this on the same in the same context, right? I'm not sure I understand the question Yeah, yeah, I Mean that cookie. I know what you mean But that cookie is accessible to the JavaScript code, right? It's going to be sent anyway I mean if you if you take the example that I gave with Say this one here and that's running on a different domain. You have a problem Then you would probably behind the scenes see this dance once But as long as you do something like this or in such an example you would generally have a reverse proxy here then they're all going to the same domain and whether you get some HTML or some JavaScript or some Some JSON document you can always include the JWT token or it is always included It is taking apart by the reverse proxy and the services then have the information they need It is no good answer for it. It really depends. I mean sometimes you need a back-end for front-end depending on bandwidth requirements depending on how many different Devices you have with very different use cases if you are sound cloud or Netflix or somebody like this That is in like smart watches and speakers all the way to TVs and PCs You might need a back-end for front-end. Sometimes you don't I don't know Sorry Good that you ask. Yeah Yeah, I know so native mobile applications and because if you will native mobile applications are also a front-end monolith, right? And here it's really tough to say. I mean, I've not seen very many people try this There is made available as open-source software by one of the big Chinese companies. I think it's Alibaba, but I'm not 100% sure there's a set of oh Yeah, there's for iOS and Android open-source software that allows you to modularize an iOS or mobile application. I think one was called beehive, but I'm not a hamster sure It's a bit like OS GI on the Java side so you can load things. I Don't know the problem. I think he has again the user experience But also the developer experience the native applications always get in store I mean with some exceptions in the enterprise space. I understand that but they generally get deployed through an app store and You don't have the same deployment frequency for mobile applications. Anyway, you're not doing 500 releases per week You have to find a different way to make it manageable. You can automate most of the app store processes But at some point even if you could and you could deploy Once every couple of hours you don't want to do it because your users will completely hate you for it, right? So I mean, I don't like them at all I mean we've actually in on the ThoughtWorks technology radar in the current edition We have specifically put release trains as a technique to avoid in general But I think for mobile applications There is probably the right way to actually come up with some release train And then do it once a week and at that point you probably don't need that anymore You you can assemble it on the server side. It's not ideal I know and some of the benefits I talked about from a deployment perspective Sorry from a development perspective you don't get But they're really not made for this. I think the frameworks. I don't know anything about Android development I know a bit about iOS development at least there you can have separate pieces like the Storyboards and the zip files you can make them separate But then you still need one bill to put them together But as I said in the end you cannot can't really deploy in the same way as you can do on the web I'm not sure what will happen. I mean Google really tried to push hard on progressive web applications I mean I used an iPhone so I know that Apple really doesn't like them very much I don't know how many of you know this but I think Starbucks is an example of an application that Can actually be pinned to the home screen, but Apple really doesn't make it easy There is a way you can I think on the website if you go to share and then like further down in the gray section You can say pin to home screen or so they really don't want you to do it But of course for many organizations that want to deploy rapidly and want to have these cycles It would be much much easier to use web technology But yeah with the with the applications as long as they go through the app store. It's really tough If you if that's your problem if you have a big application I mean I also know like some of the larger organizations. They talk a lot about Application portfolios and there's always these things should they have one massive application like if you think about we chat That does everything from chatting to payment to something else or like I mean if you take a typical airline You have one application to like To check in and book flights another one to check your mileage account and a third one for the in-flight entertainment Do you have multiple applications and then you'll split even more? But if you really want to put everything in one I guess there are the open source frameworks you would explore But I've not seen them used in practice Yeah navigation to me is a component like this there should be a service And that's what I've seen especially here on that approach on websites that the navigation is one top-level thing that is included And there's one specific service That is respond Yes, yes, exactly. Yeah, and would decide which goes where Maybe even for different customer segments. You can run a B test but by swapping around things by checking different ways The navigation Sometimes Yeah, the idea really is that they try to use the same versions That's what I meant I mean we have to learn really from what people did with mono repos on the server side and find a way for them to share the same version It's really difficult to get this to work without web components for them to have different versions And I totally get that it limits the independent evolvability because you now have to coordinate you have to die one death as they say Because I mean the other thing I mean if everybody I mean if you look at the current JavaScript applications You often have so many libraries You don't really want if you have and it's not uncommon You have like 10 different services if they all use their own version of react and the own version of redux One of them uses immutable JS the other one uses images And it's just adding and adding and adding and then you're suddenly loading I don't know 10 20 megabytes of just JavaScript code Which is really bad impression on first load for the users that first come to your website because then even if you strong caching They don't really have it cash. They download the whole thing doesn't look very good so I know Not a great answer as I said, I mean The best approach I've seen so far is to try to To arrange between the teams but then yeah, of course if a new version of react comes out if you want to switch You have a coordination problem Yes As I said, the hierarchy is the user first and then the developer and then the architect I know So if there are no more questions, I would like to thank you. Thanks for coming fantastic questions