Micro frontends are the topic of discussion again, this time with Grgur Grisogono, Principal Consultant at Modus Create and co-author of the Manning book "Ext JS in Action". In particular, Grgur explains the new module federation capabilities introduced by Webpack, and describes how they can be used to construct micro frontends in a much more streamlined and modular fashion.

Panel

Guest

Sponsors

Links

Picks

Special Guest: Grgur Grisogono.

Sponsored By:

Gifting is hard. This isn't news, but what might be news is that you can now send beer, wine, and spirits right to your friends and family with Drizzly, the go-to app for alcohol delivery, which is good news because adult beverages are the only gift that no one ever returns. And Drizzly's tailored experience lets you find the perfect drink for the occasion, no matter what it is. You'll save time by shopping a huge selection of drinks from wherever you are. You'll save money by comparing prices on said drinks across stores. And you'll get to spend more time sipping with your gifties. You know, if they're the sharing type. Download the Drizzly app or go to Drizzly.com. That's D-R-I-Z-L-Y dot com and get your favorite drinks delivered today. Ding dong, it's Drizzly. Must be 21 plus, not available in all locations.

 

CHARLES MAX_WOOD: Hey everybody and welcome back to another episode of JavaScript Jabber. This week on our panel, we have AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo. Coming at you live from not using filler words anymore. See how this works out today. 

CHARLES MAX_WOOD: Good luck. Dan Shapir. 

DAN_SHAPPIR: Hello from Tel Aviv and hi to you, Chuck. So great to see you on the show.

CHARLES MAX_WOOD: I know, right? We also have Steve Edwards. 

STEVE_EDWARDS: Hello from sunny Portland. 

CHARLES MAX_WOOD: And I'm Charles Max Wood from devchat.tv. Yeah, I guess people are probably wondering where I've been. And I'm not sure if I've explained that on the show when I've been able to pop in, but essentially due to COVID, my kids were going to school half days. And due to circumstances with my wife and her working at the other kid's school, I had to do carpool during the show and we just never got around to moving the time. So they just went back full time, which means they get out of school in the afternoon now instead of in the morning. And so I could be here. I have to keep an ear out from a preschooler coming home, but that's it. So I'm back. We have a special guest this week and that's, let's see if I can get this right. Gerger Grisogano. 

GRGUR_GRISOGONO: Wow, that's amazing. Hey, greetings from the sunny split Croatia. 

CHARLES MAX_WOOD: Wow. I've been close to Croatia, but not quite there. Made it all the way to Trieste in Italy. 

GRGUR_GRISOGONO: That was very close though. 

CHARLES MAX_WOOD: You should have said hi. 

GRGUR_GRISOGONO: I should have. 

DAN_SHAPPIR: I actually... 

CHARLES MAX_WOOD: Storm rocks over the border. 

DAN_SHAPPIR: I actually visited Croatia and it's a beautiful place. Highly recommended. 

GRGUR_GRISOGONO: Awesome. Thank you. Very cool.

 

Did you work your tail off to get that senior developer gig just to realize that senior dev doesn't actually mean dream job? I've been there too. My first senior developer job was at a place where all

of our triumphs were the bosses and all of the failures were ours. The second one was a great place to continue to learn and grow, only for it to go under due to poor management. And now I get job offers from great places to work all the time. Not only that, but the last job interview I actually sat in was a discussion about how me. If you're looking for a way to get into your dream job, then join our DevHeroes Accelerator. Not only will we help you get the kind of exposure that makes you attractive to your dream employer, but you'll be able to ask them for top dollar as well. Check it out at devherosexcellerator.com. 

 

CHARLES MAX_WOOD: Well, do you want to just let people know who you are and what you do? I know you do a whole bunch of architecture stuff, and modus create, and we're going to talk about some of the interesting stuff that you've done. But yeah, what should people know about you?

GRGUR_GRISOGONO: The easiest thing to call me is Gregor, I guess. So I'm a principal consultant and architect at Modus Create. I've been doing that for the past 10 years, but I've been involved in the web as industry since 2000 or 2001. So what I do basically is I try to help all these amazing enterprises ship better products, and I guess I help touch their customers lives by shipping those products better. And that's what I guess we all do. I also had the privilege to work with Modus's R&D department. So this is something that we cherish because the company was started from the open source community, basically from a forum, an EXTJS forum. If anyone remembers EXTJS, Sencha. There you go. So that's- 

CHARLES MAX_WOOD: I worked a contract where they made us use Sencha or EXT, it was EXTJS. 

GRGUR_GRISOGONO: Yeah. 

CHARLES MAX_WOOD: It wasn't my favorite, but got the job done. 

GRGUR_GRISOGONO: But those were amazing times, you know? But it was interesting, the way I got into this was I missed the conference, the first Enchicon in San Francisco and I said, dude, if I miss this, I wanna do something about it. And I was younger, 2010, and I decided to run my own conference. And I was able to get about seven or 800 people over to Split Croatia. It was such a fantastic community that we actually visit each other still now, even during COVID. So that's one of the things that's really exciting me about the open source community is the relationships that, you know, people make and just by contributing to the code for free, all that stuff. It's just amazing. So this is something that I've been able to work on it, Modus Create and Modus Labs, work on open source, helping other open source projects, both with actual bugs fixing, coding, all that, and financially. We recently helped Vue and we are really glad with what the core team has done with Vue.js 3. It's absolutely amazing. But other than that, lately I've been working a lot with micro front ends, which is, I think, a fantastic architectural thing. I think it's very contractual setup for enterprises that solve a lot of problems from scaling to even performance. So that's where my mind is at right now. 

CHARLES MAX_WOOD: Gotcha. And I've heard micro front ends. It feels kind of buzzwordy to me, I'll admit. But I'm just going to start out asking for a definition on this one because I've seen a lot of different things where people have used the word and I'm not sure that I've gotten a real clear definition on it. 

GRGUR_GRISOGONO: Sure. Well, so I don't think I have the official definition. And I also don't think it's something that surfaced anytime recently because, you know, people have been using this term and you're right, it's a buzzword. People have been using it, toying around with it in the past two, maximum three years, but it's, it existed since like early day with things like server side includes or frames. All those could be considered micro, micro front ends. But the whole principle is to try and avoid monolithic architectures and split code into meaningful business values so that, you know, even better, if we could have separate teams, dedicated teams to specific business values, they have their own lifecycle, they maintain their own code, they maintain their own pipelines, deployments, and so on. And then everything basically gets combined back into the whole eventually. So, you know, there are obviously multiple ways to achieve that. And historically things like iframes have been used or as I said, server-side includes, now we have things like edge-side includes, then we have a number of JavaScript frameworks for that. Mostly based on System JS, Low JS, all that stuff. But I think the most, one of the most modern approaches is by using Webpack 5 module federation that was just released in October of last year. And that seemed promising. 

DAN_SHAPPIR: Yeah. Before we go diving specifically into that technology, when I think of my, just want to mention that when I think of micro front and what it mostly means to me is that if we have like, let's say three teams working on the front end, and for some reason, one team prefers React and the other one prefers Vue and the third one prefers Angular, well then we can, they use all three frameworks on the same web application slash website altogether, without conflicts, that's kind of what micro front end means to me whether or not that's a good thing can be debated, but it certainly creates a situation where different teams working on the same project can choose their own stack and can also make progress in their project without worrying about conflicts with the other teams working on the same product. 

GRGUR_GRISOGONO: That's a great explanation, Dan. So I agree mostly. What I don't agree with is...Well, a lot too much freedom. And the goal is to strike the right balance, balance with contractual agreements. While in theory it would be possible to mix and match frameworks like Node.js and React and Vue, also Node.js, look at that, Angular and React and Vue. In practice that may create problems in runtime, obviously, three different frameworks loaded in the same apps may you know, they have different dependencies and all that. So I think aligning and agreeing on a minimum viable amount of libraries that run an app is going to go long ways in making sure that the application is still maintainable. On the other side, things like pipelines, even ESLint configs, TypeScript, all that, all those approaches to development, that's absolutely...You know, it's a democracy. Choose whatever you would like, as long as the end result is going to be compatible with your building as a whole. 

CHARLES MAX_WOOD: So you can't mix a match. You don't let us do anything. 

DAN_SHAPPIR: So you're not so much in favor of creating a strict separation. Like you mentioned yourself at the beginning that historically one approach to creating micro frontends has been iFrame where effectively every team has its own quote unquote browser. Because when you're in an iframe, you can to a great extent care less about what's going on on the outside, certainly in sibling iframes. So you're not actually promoting such a strict separation. You seem to be promoting somewhere that's more of a sort of a balanced approach of creating separation but still having some sort of commonality, let's call it, between the various micro frontends, correct? 

GRGUR_GRISOGONO: Yeah, you're right. Yeah, you're absolutely right. I mean, we are seeking for balance everywhere in life, right? We talked about sweets earlier, and yes, it's not good to have too much sweets, but it's not good to have too little sweets in life. So similar with that, I think...There needs to be, it's good to have balance. You don't have to have balance because after all, you can also decouple the app on the route basis. So for example, an e-commerce site could have an entirely different setup in cart and checkout than they do in product listing pages. But the thing is reusability, reusability of theming, of maybe certain source code like UI maybe reusability of dependencies. Some kind of reusability is going to be healthy so that the application can continue to be fast so that some of the business values can continue to be achieved with a little bit of shared code. Obviously, too much of that is usually not going to be very positive either because too much contracts is going to create

a steep learning curve, so it's going to be difficult to onboard people. It's going to create the need to document a lot of things, which means that you have to read about a lot of things before accomplishing a goal and all that. Again, it's a balancing thing. 

DAN_SHAPPIR: What I find interesting whenever I have this sort of a discussion is that, you know, we like to consider ourselves certainly engineers, maybe sometimes even scientists and really rational about decisions and the architectures that we create. But more often than not, what I see when I'm looking at the complicated, the sophisticated, let's say product, is that the architecture is actually driven by HR. And what I mean by that is that, say, you have 20 people working on a project, well then 20 people is going to be four teams, or maybe, or three, let's say three or four teams. So let's have four, if we have four teams then we'll have four micro frontends. So really the architect, and then we separate the product into four parts so that each team with its own micro frontend has more or less equal responsibility so we can all progress at more or less the same rate. So really, instead of having the architecture being driven by the problem that we're trying to solve, it's actually driven by the people and the organizational, by the org chart that we have.

GRGUR_GRISOGONO: That is such an interesting point. I love that you brought it up. I think what I usually, because having the pleasure to work with a lot of different clients across the globe, I don't think I ever really got into the challenge of the HR deciding, but certain aspects of agile direction that comes from either the stakeholders or product management can indeed influence what this looks like, you're absolutely right. And well, obviously one of the things that's really to HR is, hey, we already have, you know, React developers, so we need to do this in React. And kind of that made sense. But someone other than the team deciding how the team works, that's a difficult situation to be in. And if, well, I'm not sure if this is exactly aligning for success, but I guess if rules are what they are. It is what it is. To your earlier point, I liked when you said, we are engineers and we are scientists to a degree. And I think that's also an important point that you mentioned because what I see a lot is, I see people being emotionally attached to technology, to their decisions, to their, even their code, right? And I'm not really sure that that is a healthy thing too, because in my experience, being emotionally attached to technology creates healthy conflict, but also unhealthy conflict when it gets personal. And this is something that actually was yesterday. Yeah, it was yesterday, beginning of this week, that we had this discussion because we are implementing Microfriends architecture with one of the leading premium car brains from Germany. And we are running with a number of really amazing teams that are structured like the way you said, we have teams and we have sub teams like pair programming. And that's all very, very agile. People can really decide where they can contribute more or the best. But we talked about the concept of being emotionally attached to technology because we saw that some people were falling in the trap of being too, as I said, emotional about choosing specific technologies to go with. And when the discussion went a different direction, they become upset. And I think this is exactly what scientists should not be doing, being attached to decisions and not being attached to decisions really helps us distance away, rethink, and even listen to what others have to say. And usually that really helps us to learn something new, get better and grow. 

DAN_SHAPPIR: I totally agree with everything that you just said. And before I took us down the rabbit hole, you started to mention Webpack Federation as a modern means to implement micro frontends. Is that something you can elaborate on? 

GRGUR_GRISOGONO: Absolutely. So module federation is basically new and it's been released in October of 2020. But it's something that has been worked on for a couple of years before it was released. And I feel it's in a very stable state. Modular Federation is something that's, it's one of those things that are incredibly simple, but also amazingly powerful. So what Modular Federation allows us to do basically split our monolithic bundles, big bundles, into a number of smaller, I wanna say libraries, but not the kind of libraries that are published to NPM, the kind of libraries that are published to a CDN, which is a world of difference. It allows us to specify which parts of an app to load from, as I said, from the CDN at runtime. And by doing that, it allows software developers to specify dependencies. So dependencies are easily reused because Webpack, well, we can talk about that in detail if we wish, but Webpack does a really, really good job to resolve any dependencies using semantic versioning and figure out which dependencies to load, from where and how to avoid duplication. So basically what you end up with in in the final product, you end up with a really, really good scalable product that implements some of the best practices in perceived performance, such as lazy loading by default. That's an amazing feature. 

DAN_SHAPPIR: Can you give a concrete example or just a more technical explanation of how this actually configs, 

GRGUR_GRISOGONO: then what really needs to happen is for each part of a project, a team should use a custom setup for each project. Now, we talked about this. So each team works in a different repository, they have different pipeline and so on. That also means that in this scenario, each team would have their own Webpack configuration. Webpack configuration allows us to specify three main settings that are used for combining apps together. The libraries that it consumes, external libraries, which is similar to what we would do with npm, but these are actually located either on another dev server or on a CDN. We define what it is that we are defining dependencies that need to be shared so that they're only built once and loaded once. In real life, if we had an app and we can talk about really any app, so let's talk about Amazon.com. So Amazon starts with that header and the menu, and then you get like your product listing. So the menu can be a wonderful, I'm gonna call it micro feature, micro front feature or a feature app. The menu could be a wonderful feature app because a team can work just on that menu. And another team can work just on the product listing on the homepage of Amazon. Now, if you think about another example, that could be the YouTube player. A team can work on the player itself that has the video feed controls, and they are in charge of how YouTube plays videos. They have their own code base. They're they have their own build system. Then there's a team, I guess, that works on metadata like name, description, and another team that works on the comments. Now the cool thing about comments is that they are usually below the fold. So you need to scroll down for comments to load. And because Webpack Federation works with asynchronous JavaScript, so that means that things are not always loaded at once, they're loaded basically when needed, and as I said, asynchronously. So as we scroll down, we can set it up so that comments as a whole different feature can be loaded exactly when needed. Now in this setup, we just had three feature apps. Another feature app would be that coming up next list on the right-hand side of the desktop web layer. So we were just able to decouple a larger app into four sections that maybe four teams or three teams can maintain. The interesting thing about module federation is that it does a lot of the things in the background. It prepares everything at build time. It adds the necessary runtime code at build time. So when things are imported and, and actually there's a lot of standard work inside how module federation works. There's no really new APIs that developers need to learn. They just import stuff as always. And eventually the whole page comes, or app comes together at runtime. Dependencies get resolved automatically. They're fetched from the best available distribution. And the rest is just data work. Data is collected from an API and the video gets played.

DAN_SHAPPIR: If I can ask, how is this different or how is this better than just going to the simplest alternative implementation, just injecting script tags that load the different modules like that. Why do I need Webpack to download JavaScript dynamically for me when the browser has been doing it for years. If I just create a script tag, make it, let's say, a sync. It's a sync by default if it's a dynamically created script tag and have it load the module that way. 

CHARLES MAX_WOOD: I was wondering about that too. 

GRGUR_GRISOGONO: Absolutely, you could. But that creates a lot more contractual agreements, right? You can add a lot of script tags. But the thing is, how do they play it together, right? I suppose you're still creating a monolith, which means that there needs to be a lot of shared understanding and shared knowledge. Things usually have to happen at a given time. Whereas with something like modular variation, which is really the bare bones of microfrontalism, you know, honestly, there needs to be a layer of additional support on top of that to make things work properly. Things like communication between those feature apps and a few other issues to resolve. But the whole thing is if you're adding script tags, you're still building a monolith. You still need the teams to be aware of what each other are doing. And aside from that, in that case, there's usually, well, wouldn't that there be always the usual build step that needs to combine most of the application? Or if there isn't, isn't there a lot of work to make sure that everything actually plays well together, especially with dependencies that may or may not be shared or duplicated and that kind of problems. 

DAN_SHAPPIR: Putting aside sharing and duplication, what this mostly, and again, I might be missing the point, but what this really seems to sound like to me is like the resurgence of AMD kind of like what we had with require.js, where we could specify dependencies and be sure that things are loaded in order and properly exposed to each other. Is this what it's all about, or am I missing some bit of functionality or insight here? 

GRGUR_GRISOGONO: You're not. So this would work on top of AMD, because you get to choose how your modules are bundled. You can bundle AMD or Common.js or ES modules or system.js, registered modules, a number of things. Eventually it is going to resolve with, well, depending on the way you bundle the library, it is going to resolve, end up being loaded as script acts too, which is also a great thing because everything Modular Federation is bringing to the table is using existing standards to make lives easier, right? So what Modular Federation makes easier is to combine all those technologies that already exist and make it easier for developers to communicate and reuse their features. So basically what you end up with is all those script tags that were mentioned, all those separate features that were mentioned, being able to use and reuse as part of JavaScript code through your JavaScript without needing to worry about where it comes from, where it is what version are you running and so on. To that extent, it really helps make developers' lives easier by kind of adding that layer of functionality to the end users, right? Again, we still follow the same standards that are already in place with a little bit of automation that helps developer experience and helps developers communicate together without having to add a lot of contractual agreements. 

DAN_SHAPPIR: If I, again, assuming that I understand correctly what you're explaining, then essentially what we're getting is Webpack modules, either static or dynamic, but that instead of being built together and coming together from the same location, either as a single bundle or as separate chunks, but still built together and coming from the same origin. Now we can specify that these Webpack modules are actually coming from any general URL. And then, like you said, it's just coming from a CDN instead of being built together. Is that more or less what it is? 

GRGUR_GRISOGONO: That's on point. That's absolutely correct. And what that allows is, is I think a lot more flexibility in how the organizational aspect of running teams work, where we allow teams a lot more freedom. And I think I used the term democracy earlier, a lot more freedom to work on their features to focus on delivering business value of their business unit. And to maintain the entire lifecycle of developing their part of the app, right? And eventually, it all comes together in the final result, final application. But this is, I think, one of the biggest values for an organization. And this is something that when you look at it, when we zoom out and we look at it, it really allows for scaling of large apps. So I think what I would add is if we look at it, if we start to think about microfinance and module federation, if we think about, hey, is this good for my project? Then I would say it's probably an overkill for a lot of small projects. Because this is really meant, and I think the largest value of using MicroFriends is in scaling. And setting that whole thing up for small applications, I think, can be a little bit of an overkill because a lot of things have to happen to make this work, right? We need to do a couple of things into separate repositories, separate pipelines, separate deployments, and so on. Another amazing value for this. Now, I know a lot of developers are listening to this. I mean, they may not care, but their businesses or clients will care, is that if you think of it, if you have all these features deployed separately, then what you could do, you could really track the usage of those features. And the cost of the features, because that cost is also associated with, you know, maybe how it's provisioned in the cloud. So you can manage cloud costs or AWS or Azure or something, and how much that costs per feature, not to mention analytics that are, you know, beautiful for this kind of approach, but you can also, also track things like the patterns of how people use feature as from the aspect of how they're loaded. Also an interesting point. Another thing that I find interesting is it's versioning of those features, which is great for business because when you can version things, you can also do incremental upgrades. You can have beta testers that can toggle kind of a new pre-release version, or they can run A-B tests fairly fairly easily, something that could be driven by configuration. So I think those are all really important things to consider, which makes microfinance not just a cool thing for developers to play with, absolutely a great thing to learn, but it makes sense to couple that with the right needs of the business. 

DAN_SHAPPIR: How do you actually version these URLs to those CDNs? Webpack Federation, how do things get versioned? Because obviously when you're just using Webpack the old fashioned way, you've got the package JSON, but that is not really relevant anymore when you're just downloading stuff from a CDN. So how is versioning managed in that scenario? 

GRGUR_GRISOGONO: Yeah, great question. This is what I said, Modular Federation is not the end of the game. It's not the final step. It's one of the parts of the architecture that makes, I want to say, loading of features a lot easier and streamlined, but there are other decisions that architects and developers need to make. And that is, as you said, versioning is one of them. A very easy thing to do, a thing that really works is to deploy every new subfolder, for example, if you're using S3 buckets, right? And we are deploying version 1.3, and that goes into a separate folder, 1.3. So the final URL for that feature will contain the version number inside. Now we can do a lot of clever things and have things like a Lambda or resolve the closest semantically version that people require. So for example, you can insert the URL to say slash latest, or you can do things like slash 1.3.x or something like this. All those smart things can happen, but that needs to be developed. That needs to be architected.

DAN_SHAPPIR: So basically out of the box URLs are just fixed strings. If I want them to be something, if I need to do some sort of version management in this type of a scenario, but you're basically saying is that I need to build it myself and I can make it if I needed to be sophisticated, well then I'll probably need to build some sort of a versioning microservice and use that. Is that what you're saying? 

GRGUR_GRISOGONO: You're absolutely right. But what comes out of it is, well, definitely, as I said, modularization, not silver bullet. You need to build on top of it. But if you have all that infrastructure, if the team can work that out, make sure it happens, then another amazing thing to do, a feature that the business gets, is when a new feature is deployed and there is a regression issue, then the system can be develop in a way that regression is caught and the application loads the last known version that works really well. Now that's also amazing business value that comes with Microfront as, and this is something that Webpack Federation makes a lot easier than ever before. 

 

Have you ever wondered if you could be offering a faster, less buggy experience for your customers? I mean, let's face it, the only way you're gonna know that is by actually running it on production. So go figure it out, right? You run it on production, but you need something plugged in so that you can find out where those issues are, where it's slowing down, where it's having bugs. You just, you need something like that there. And Ray Gun is awesome at this. They just added the performance monitoring, which is really slick, and it works like a breeze. I just, I love it, I love it. It's like, it's like you get the ray gun and you zap the bugs. It's anyway, definitely go check it out. It's going to save you a ton of time, a ton of money, a ton of sanity. I mean, let's face it, grepping through logs is no fun and having people not able to tell you that it's too slow because they got sidetracked into Twitter is also not fun. So go check out ray gun. They are definitely going to help you out. There are thousands of customer centric customer focused software companies who use RayGun every day to deliver great experiences for their customers. And if you go to RayGun and use our link, you can get a 14 day free trial. So you can go check that out at javascriptjabber.com slash raygun. 

 

DAN_SHAPPIR: I'm not clear on why it's easier. 

GRGUR_GRISOGONO: Sorry, so you're not clear as to what Webpack Federation makes, why Webpack Federation makes that easier? 

DAN_SHAPPIR: Yes, I'm not sure. I'm not sure I understand why Webpack Federation makes handling regressions easier.

GRGUR_GRISOGONO: Webpack Federation doesn't handle regressions, but it helps us stay aligned with proper building approaches. And it helps us build those, because Webpack Model Federation is a part of a bundling or a build tool, Webpack, right? It helps us really tailor it to what we actually need. And it works well in combination with other tools in this ecosystem, which in this case can be things that are actually loading on in the cloud, right? Webpack's module federation does not solve for these problems. This is part of what we as software architects and developers actually do in association with Webpack module federation. Does that make sense? 

DAN_SHAPPIR: I guess.I guess I know. 

CHARLES MAX_WOOD: He's sold on it now. 

DAN_SHAPPIR: No, I mean, look, it seems to be one of those things that until I actually get my hands dirty with it, I'm having some issues grasping the intricacies and the benefits. Let's put it this way. 

GRGUR_GRISOGONO: OK. As I said, Webpack Module Federation is a very simple addition to Webpack as the build tool. But that simplicity gives it a lot of power it doesn't solve all the issues. It helps us use the existing standards in a very defined way. And it helps us build microfinance and maintain how microfinance import dependencies resolve shared libraries and put the application together. It helps us build multiple features independently and then load that together. What I was talking about are the effects of that freedom that we have. Okay, so module federation is not going to help us create a cloud scaffolding, but it gives us the freedom to think about our apps well, in a different way, which is again why I said maybe microfinance is not something that a small website should leverage, right? It's probably something that's going to be a lot more interesting to enterprises or any larger projects and so on. 

DAN_SHAPPIR: I have to kind of say, from my perspective, sort of a word of caution about micro frontends. So we've actually been discussing micro frontends in a couple of episodes. We talked about micro frontends working with web components, for example. We talked about the micro frontends as a solution for framework versioning and stuff like that. And in fact, as a sort of a way to manage larger projects, like you said. The word of caution that I want to throw in is that at the end of the day, micro frontends are, let's call it, a benefit for the developers. And we really need to be careful that when we're making life easier for the developers, that it doesn't come too much at the expense of the end users. And too often I've seen situations where like, I kind of joked about it at the beginning of this conversation that you might see micro frontends being used to create a web application that uses React and Vue and Angular all together on the same site. Now, this might be great for an organization that has a lot of legacy code, or developers that are used to particular frameworks and don't want to go to the hassle of switching, but it comes at an expense of the user. Because when you load these three frameworks into the same webpage, it's going to have overhead. And that loading overhead, slow loading website, for example, is going to be coming at the expense of the user or the visitor. So you definitely need to be careful about that. But if you can get your cost down in that regard, keep your costs down. Maybe it's because you're using really lightweight frameworks like Preact or there was another one that I recall on our show, AJ, you remember the one that talked about in the past? Lit, the Lit HTML, that's it. So if you're using really lightweight frameworks, then it can work. Or if you're, let's say you're building an enterprise solution that's only going to ever be used in sort of an intranet where everybody has really fast connections and fast computers and don't care about slow networks and lower end devices, then this can work. But otherwise, you need to be careful when making this sort of a decision. That's really the summary from my perspective. 

GRGUR_GRISOGONO: It makes sense and I can see why you said this, which is why I would like to add micro front ends is, if we take a step back, it's just a concept of being able to decouple business features, parts of the app, so that we have to choose how they are glued together. Now, different implementations are just different types of glue and how we actually connect that together. Mods with iteration is a type of glue, but the main content, the main app, the stuff that we create is still on us. This is still on someone or some teams from people to decide on. When we say microfrontends, we basically allow teams to worry about what they know best. And which is why I said in the beginning, striking the right balance is incredibly important because I think we definitely want to avoid having too many technologies being loaded in an app. And if that happens, you're absolutely right. The user is going to suffer the consequences, most likely in the ways of not enjoying good performance. But again, this is not the result of using micro frontends. It is the result of, it's probably not right to say too much freedom or too little constraints, or too few constraints. And we need to worry about that no matter if we use micro frontends or we use any other solution, because you could do that in a regular app and use multiple frameworks. If it's a big monolithic app, it's still possible to do that, but we don't want to do that. Why would we want to do that in micro frontends then? That would be the question. 

CHARLES MAX_WOOD: I guess the thing I'm wondering, and you've both kind of spoken to this is so let's say that I get to a certain level of complexity and I'm starting to think about using module federation and micro front ends to solve some of the issues that I'm facing in my app. How do I know it's a good fit? Like how do I know if my app is big enough or complex enough or has enough concerns or you know whatever that's going to make it a clear decision as opposed to you know Dan is raising some of the trade-offs that really do appear, you know, in a solution like this, you know, and so, yeah, when do you start looking at it and going, okay, this is clearly the direction that we ought to be at least thinking deeply about implementing versus just going, no, not yet. 

GRGUR_GRISOGONO: I hear you. Well, also Dan is on point to a degree, right? Because the one thing is when someone has a lot of experience, and someone knows exactly what they're building, they're gonna make sure that the application is, you know, performant, it's fast, it's optimized, it uses just enough libraries, and all those best case scenarios are applied. But to be told, we don't live in that kind of world, right? People use technologies, which is, again, all the more reason why we should, why it's good for technologies to do one thing and one thing only and be good at it so that we don't introduce a lot of complexity that people need to learn because they're absolutely going to use it in the wrong way. That's going to happen. So from your question was, when do I know that my app could be decoupled and, and go run as a micro front end? It's, it's a nice little question. I think I know the exact time when you say that. And I think that decision I absolutely believe that that kind of decision needs to be made in partnership with the business. Being product owners, stakeholders, being software architect or architects that are working on a product. It could be even content authors because we end up really building something that's going to be consumed by multiple personas, right? And I think we need to know what kind of benefit this is building for the business bringing for the business. I'll just give a couple of examples. I mentioned content authors, right? A lot of bigger apps are data-driven. So what happens if someone out there is using a CMS or a Hella CMS like Contentful or something, and they are in the driver's seat of deciding what it is that gets pushed to the apps that the users see, right? When they work with data, they often don't have a good preview functionality because they either need to rebuild the entire app or they need to run the entire app and so on. When features are decoupled and deployed individually, then content authors get a very unique opportunity to see what their content is going to look like because they can preview on in the scope of a single part of a whole or a feature instead of having to work with the entire app and maybe wait for rebuild time to happen and so on. So that's a business value. Another business value is obviously when you have multiple teams. So how do we cut new releases? How do we create new increments? If new increments require long build steps, so this is taking a lot of time, a lot of testing, a lot of time wasted in CI CD pipelines, then maybe that's a good sign that an app could be decoupled in smaller units so that all those lengthy cycles can be minimized, which means, hey, maybe I don't need to rebuild the whole app to create an increment. I just need to rebuild the feature and here goes the increment. In some scenarios, it's security. I know some companies don't like to share the entire codebase with their developers for whatever reason, and they go use, take different approaches to handle their intellectual property. That could be a reason to go to micro frontends because you want to allow developers to only a subset of the entire feature set. 

DAN_SHAPPIR: That's cool, but I wouldn't work at a company like that. 

GRGUR_GRISOGONO: I hear you. Well, honestly, I wouldn't work at a company where HR decides on what kind of teams work on a project. 

DAN_SHAPPIR: Oh, yeah, I was kind of flippant there. I mostly meant that the org chart determines the architecture rather than the other way around. But anyway. Absolutely. 

GRGUR_GRISOGONO: So what I want to say, a lot of these business values, micro frontends make it definitely easier to migrate, not just to whole new frameworks, also to new versions of libraries, because you can go step by step. This triangular pattern is almost natural to micro frontends. Then again, it's a beautiful pluggable architecture. So if you need to work with something pluggable that doesn't load at the same time, the loads were needed, where places where you can theme apps on demand. You know, that's all great, but eventually that's all possible with micro-frontends, but eventually the team organization is I think one of the core values that teams get, you know, big bigger teams can be easily made smaller because smaller teams, I think this is perfect for pair programming. Pairs can work on specific features that are that big or that small and really excel. So it's not just scaling in terms of the application size. It's also scaling in terms of the speed of development. 

STEVE_EDWARDS: So I have a question here that sort of a little higher level than some of the weeds you guys have been getting into. Obviously we throw around the term micro front ends a lot. And I don't know if we've define what the term micro means. So my question is, and I'm sure this is relative or situation dependent, but in your experience, how micro is micro? So are we talking a page? Are we talking element on a page? You know, are you talking a line of text within an element? I mean, just throwing things out there, but is there like a generic definition of micro when we're talking about micro front ends? 

GRGUR_GRISOGONO: That's a fantastic question, Steve. I love it. You know, honestly, that's a difficult thing to figure out. If we think of atomic design, where we have atoms as the smallest unit, and then we have molecules that grow into organisms, and then we have templates and pages, right? If we think about that for a second, then I would say micro frontends really make sense for organism templates and pages not so much atoms and molecules. In a more, well, kind of real-life sense, I think anything that's a UI component library stays a UI component library, right? So a button is not gonna be a micro frontend. That doesn't make sense, but we have too many of those. But as I said, a menu, a menu could be an excellent micro frontend. So things that are more into organism templates and pages, realm and less atoms and molecules. There are exceptions when we want to allow content managers or content authors to work with very specific layouts and their CMS doesn't have all the powers, all the super cow powers to ensure proper set up of these features into smart layouts. And those smart layouts could be anything from complex carousels or those layouts that have multiple placeholders, if you will. In that case, it may make sense to create a micro, micro front-end that speaks just to that problem. But in real life, I think what really makes more sense is something that's a collection of meaningful components that make up a business value. I'm also gonna add, if you look at an app or a website, and you notice the above the fold content, right? And let's redefine that, or critical path content, if you will. If you redefine that, I would say, it's everything that a human sees when they first load the app, without having to interact with it, without having to scroll down or hit on a button. That's the most meaningful part. So if there is a hamburger menu that goes behind a button that opens on in Ration. That's something that we can definitely consider to put away as a feature app. Or if there's a big chunk of content that needs to load when we scroll down, and an example is those comments on YouTube. I think that's a fantastic candidate for a feature app. So as I said, it's not easy. It requires thought, it requires understanding the business case. It also requires understanding user behavior. Does that help? 

STEVE_EDWARDS: Yeah. I mean, there's obviously no one set definition for it, a micro-frontend. It's obviously going to depend on the application. I think you answered my question, though. How small do we get? Obviously not down to a button, but something larger than that that contains a piece of functionality. 

CHARLES MAX_WOOD: Yeah, makes sense. What's the testing story on micro-frameworks? Is it the same as just other libraries or other work that you do? 

GRGUR_GRISOGONO: Well, with testing, it's, as you said, the great thing about that is when I see people test apps and whenever testing is on the table for discussion, I usually see a lot of people being very passionate about different frameworks and approaches, different ways of testing apps, and a lot of different things that are brought to the table and need to be discussed. And maybe this is why, this is one of the clear benefits of using Microfrontends is because every team can choose their own strategy, their own setup, and live with it, enjoy doing that, love their lives. But one thing that I believe needs to happen is the whole project needs to have real good integration testing and two-end integration. Eventually, what is going to happen obviously is the user is going to see the whole project, not just the feature by feature. And we need to make sure that when things run in the whole unit, they work well together. And how we do that, how that's achieved. Now there are again, different approaches, but one of the things that I found very interesting is testing with screenshot comparison. And it's only because obviously pictures speak a thousand words. Sometimes we don't catch theirs. And letting screenshot comparison show us the differences between different iterations and how they play together can actually point interesting bugs and situations to QA engineers or even developers who end up seeing that. So before cutting a final release for any feature app, it's great if it's possible to run a test suite that's going to test that kind of regression in a kind of end-to-end integration test. I think that's a very important thing for the company. 

CHARLES MAX_WOOD: Awesome. We're kind of getting toward the end of our time. Is there anything else that we want to jump on folks before we do picks? 

DAN_SHAPPIR: I'm good. 

CHARLES MAX_WOOD: All right, well let's go ahead and do some picks. 

 

This episode is sponsored by Sentry. Sentry is the thing that I put into all of my apps first thing. I figure out how to deploy them. I get them up on the web and then I run Sentry on them. And the reason why is because I need to know what's going on in my app all the time. The other thing is, is that sometimes I miss stuff. I'll run things in development, works on my machine. We've all been there, right? And then it gets up into the cloud or up on a server and stuff happens, stuff breaks. I didn't configure it right. AWS credentials, something like that, right? And so I need to get the error reporting back. But the other thing is, and this is something that my users typically don't give me information on, is I need to know if it's performing well, right? I need to know if it's slowing down because I don't want them getting lost into the Twitterverse because my app isn't fast enough. So I put Sentry in, I get all of the information about what's going right and what's going wrong, and then I can go in and I can fix the issues right away. So if you have an app that's running slow, you have an app that's having errors, you have an app that you're just getting started with. Go check it out, sentry.io slash four, that's F-O-R slash JavaScript, and use the code JSJABBER for three months of their base team plan. 

 

CHARLES MAX_WOOD: AJ, do you wanna start us with picks? 

AJ_O’NEAL: Yeah. So you might've noticed during this episode, I didn't use any filler words. That's thanks to not having said anything. But what I'm gonna pick, I picked this last week, is Jim Quick. The YouTube channel is actually Mindvalley, the one that I was first introduced to. He has a video on having a morning routine. And after years and years and years of being a very late riser, night owl type person, I do to various reasons, but wanting to feel better, wanting to feel more healthy and really needing to, I decided to develop a morning routine. And it is making my life so much better because once I've stuck one, how to say, I've laid the first brick down and it's more clear where the other bricks need to go. I feel like I'm more organized. I feel like I'm more healthy. That's because I've got a small, tiny amount of exercise as part of my morning routine, but it literally I'm running for about a minute, but it makes all the difference in the world to the way that I'm feeling throughout the day. So I'm going to give a link to Jim quick. And I've got a couple other ones here at that end was a filler word. Dang it. This is hard. It was very hard to develop this habit. 

STEVE_EDWARDS: Resist the urge. 

AJ_O’NEAL: Well, my goal is that if I can learn to speak without using filler words, that means that I have to change the way that my thoughts are processing in my brain so that I'm doing whole sentences at a time. And then I can pause poignantly to let my brain catch up and then find what the next sentence is going to be. And it will also help me to communicate better with others. And I think that it's a good thing. Anyway, pardon me as I stumble through this with such awkward pauses by avoiding saying like, so, um, you know, et cetera. I've so I, for a long time, I've had this idea of beyond code bootcamp, and I've talked about it a little bit last year, but I haven't really done much with it. And a lot of that was due to analysis paralysis where I know that I can create some really great content, but that great content takes me 10 to a hundred times longer than it takes me to produce mediocre content. And that's part of what this not using filler words is about is if I can produce better mediocre content, mediocre content that is up towards good, maybe not quite towards great. And I create more of it. Then I will be able to have a greater effect than if I let my analysis paralysis get ahold of me. Now, eventually I do want to create really streamlined, super smooth, super professional videos. And I've done a couple of those, but in the meantime, I am taking your questions. I would really love it. If you would either follow on Facebook, YouTube, or Twitter, if you've got some questions for me, or if you just want to follow how this goes, I am starting from the beginning with things like how to use VIM, how to use Markdown, how to set up a server. And then, there are a couple of computer sciencey things that are being sprinkled in in between. And I will move on to coding. So most of you that are listening to this already are coding. But if you know somebody who isn't or you've got some questions that you'd like to ask, please do and I will have a link to Beyond Code on Facebook, YouTube and Twitter in the picks section here. And one last thing is there's a TV show on BYU TV called Comedy IQ. It's super clean. It's a reality TV show based on a comedian who is teaching kids how to be comedians and get their start. And it's something that my wife and I have enjoyed that my little two year old daughter can somewhat pay attention to. It's interesting enough visually that it keeps her eyes on the screen a little bit too, not that I want to train her to be a brain drain type of person, but It's a good show, Comedy IQ on BYUtv. Do recommend. 

CHARLES MAX_WOOD: All right, Dan, what are your picks? 

DAN_SHAPPIR: Well, I've got two picks today. One that is totally related to technology and the other one that totally isn't. So which one do I want to start with? I'll start with the one that isn't. So after watching a couple of YouTube videos about how to make them, I decided to create two pair of smash burgers. Luckily, we've got this grill that's right next to our kitchen in the yard, and it's connected to the gas. So it's really easy to start up. And I've done it twice now. And it's with apologies to our vegan and vegetarian friends. It's absolutely delicious and highly recommended to the meat lovers amongst us. And it's really fast and easy to make. And like I said, very, very tasty. My kids definitely approve. So that would be my first pick. And the second pick is one that I may have made before in some episode way back, but I think it's, it's worth mentioning again. So I have this thing for JavaScript riddles. I like exploring the various strange edge cases of our, of our favorite programming language. And one way that I like to do it, to go about it is by making up riddles. And I've been doing that for the past five years. And if you want to try your hand at solving the, all the, all the, these rebels that I've created, they're all on Twitter, just look for the hashtag JavaScript riddle as one word. I'll actually give a link that we can put in the show notes that will just open Twitter on that hashtag and you can try it out. I try to put them out at, you know, not regular intervals because they don't always have good ideas for additional riddles, but you know, every once in a while. So if this seems like fun to you, make sure to follow me on Twitter. And those would be my picks for today. 

CHARLES MAX_WOOD: Awesome. Steve, what are your picks? 

STEVE_EDWARDS: So I'm gonna go down the humor route again today and go with a couple of Instagram accounts that I follow that give me, or a couple of my sources for my daily jokes or puns. One is called Pun Bible. So it's Instagram.com slash pun underscore Bible. And that one has a variety of different formats and jokes that they use over and over. And then the second one is one that pun Bible has had once in a while and they've got a full channel and it's called Stand Up T-Rex. And it's all it's a all the jokes use the same four panel drawing of a T-Rex was doing standup in a comedy club and two of the panels are jokes. And then the last two everybody looking at him like, huh? And he's looking back at them. So anyway, I'll put the links in the show notes but those are two good ones. If you're into the bad jokes like I am. 

CHARLES MAX_WOOD: All right, cool. I'm gonna throw in a few picks. So I just finished the process of designing my 12 week year which is basically my short-term planning for where I wanna wind up you know, and that's usually based on a three year plan that I break down into a one year plan. And then I plan out, you know, the next three months, which is 12 weeks. It's a, there's a terrific book called the 12 week year that I kind of based it out of. Okay. And, uh, I'll put a link to that in the show notes too, cause I really ought to. So anyway, what I've been doing is I put in my 12 week year and I'm not going to show it off cause there's some stuff in there that I, uh, don't necessarily want public at the moment. But one thing that I have really been diving into here is just planning this out. When I, when I planned it out, one of the things that for whatever reason I decided to do was at the end of the 12 week year, which is for me ends June 6th, there were three things. The first one, I'm not, like I said, I'm not going to mention the second one is run a marathon. I ran a marathon a year and a half ago and I want to do it again, but I'm going to do one that's local because last time it just didn't work out that my family could be there. So I literally ran the marathon hobbled over to my truck and then drove back to where we were staying all by myself. 

DAN_SHAPPIR: That was probably a really fun drive. 

CHARLES MAX_WOOD: Oh yeah. Yeah. 

DAN_SHAPPIR: You're able to actually move your legs to push the pedals. 

CHARLES MAX_WOOD: Yeah. I, so it ended at a park and I wound up sitting on a chair in the park in the shade and just kind of sipping water until I could make myself stand up. And then after that it was okay. But I was probably in the park for 20 minutes, just recuperating to the point where I could walk. So, you know, without feeling like I was going to keel over and pass out. So realistically, yeah, that level of exertion is interesting. And my ultimate goal is actually to run a full iron man. So, but I need to get back into shape. I've done a marathon. I know what it takes. And so I thought, okay, well I'll do a marathon. I just, it feels a little bit crazy to me to be planning to train for and run a marathon in three months. But I'm going for it. So what I'm pulling together in that is I bought a training on TrainingPeaks, which is an app on your phone. And so I'm just following that running plan. And so far, so good. I've done the first day. But yeah, actually made it through the run. It wasn't terrible. My body knows what to do. I've been doing some training off and on for a little while before that going to be an okay shape and I'll be okay to run the marathon in three, in three months, but it's going to be a little bit nuts, but training peaks. I'm really, really liking it. I actually paid for their membership and I think it was like a hundred bucks for a year or something like that. But what it gives you is it allows you then to import these trainings and that training costs me like 30 bucks. So you import the training into training peaks and then it just tells you what you're doing every day. Right. And they have different coaches that have designed them. So So that's been awesome. The other goal has to do with church and just kind of getting some stuff organized there because in my congregation, I'm the president, one of the auxiliaries and anyway, of the Sunday school is, is what I'm in charge of. So, you know, just some goals there and some, some planning for that. I've been using a system called ClickUp before we use the system called Notion and Notion had some pretty severe lack in functionality. The ClickUp doesn't lack. And most of it's around automation. So I can automate with it, I can use Zapier with it. It actually integrates with Zoom and GitHub and Sentry and a whole bunch of other tools that I'm using for some of my more software related stuff. And so I'm really, really digging it and I'm probably going to wind up moving most of the podcast tracking stuff over to it. But it's project management system right now. I'm on the free plan. And I think the only limitation is the amount of space you can have. Right. So I can add as many people to it as I want and stuff like that. And then if I wind up paying, then I do have to pay per user. So that is a consideration down the road, but for right now, it's working out really well. And I love the way that their task management works in ways that things like Trello or Basecamp or some of these other tools that I've tried to use in the past just haven't quite worked for me. So anyway, those are, those are my picks. So click up, uh, training peaks, and you know buying a plan so you can go run a marathon. The marathon I'm running is the Utah Valley Marathon. So like I said right here where we live. So anyway those are my picks. Gerger, do you have some picks for us? 

GRGUR_GRISOGONO: Well first of all I love hearing about that. It's amazing. If I can add you know one of the you know personal things I actually what I love doing is I love baking bread and I've been I've been doing that for years. I've been growing my own cultures and the fact that's amazing about that is, you know, we engineers enjoy building things, creating things. And in that aspect, I think we create a little bit of life. Bread is, I think there's nothing like bread because what we do is we actually create life three times to build one bread, right? So from the actual ingredient, from the flour that used to be a plant at some point, we killed it. We create bacteria and yeast, which is another form of life, which we kill by baking. And then we get bread that gives us life. So it's a very interesting life cycle. I love doing that. I just recently bought about 200 pounds of flour from Italy, from South Italy. They have phenomenal types of flour. And now I use that to, you know, build, ferment bake pizza and so on. So if there's anyone who is in any way like me and enjoys doing that, it's a fantastic habit. It's like having a pet because you have to feed something every day, you build something with your hands, not having to use the keyboard or anything. And it's really hard to actually, if you're into building, creating your own culture of Le Van or yeast, then...You basically, it's very hard to kill it because it's so resilient. And if you need to go somewhere on a trip, you know, nowadays trips are very popular. Just kidding. But if you need to leave it at home and not feed it for awhile, then that's all you okay when you come back, you can redo that. Uh, I know there is a lot of content on YouTube about that. I don't have anything, anything specific to recommend because all these, all these content creators are going to have different approaches to sharing their knowledge. And it's actually a very simple thing. So I would suggest just trying to search for it if you're into it. Very fulfilling thing, at least to me. Aside from that, from that, I think what I'm going to share, again, is if people are interested in any of this, what we talked about, we kind of love sharing that in form of blog posts or videos. So if you want to know more, if you want to learn more about anything that's related to our lives as engineers, whether it's development in JavaScript, React, Review, or Angular, or Node.js, or Cloud, or whether it's, you know, Jira and dashboards and all that stuff, you can head over to moduscreate.com. We have a really well-visited blog and we have a lot of people who are actually participating in creating that content. A lot of perspectives too and also YouTube slash modus create, actually just modus create where we are standing up YouTube channel. A lot of, again, similar topics I try to record as well. I've been way into micro front ends lately, so I haven't had the opportunity to record more. But I kid you not, I'm working. I'm committing to recording more in a way that I'm continue to invest continuing to invest into my little home studio. And that means that I will get back to that game and continue creating content for everybody to, you know, do things that we do together. Contribute here and grow. There you go. 

AJ_O’NEAL: There's one more thing that I wanted to throw in real quick that I didn't mention earlier. So it turns out if you use a referral code for DigitalOcean, you get two months or a hundred dollars credited to your account that you can use. So I'm going to slide my referral link right in here in case anybody wants to use DigitalOcean two months for free or with a hundred dollars of credit. 

CHARLES MAX_WOOD: Nice. All right, Gerger, if people want to find you online, connect with you on Twitter or GitHub. That's usually where people are. How do they find you? 

GRGUR_GRISOGONO: Sure. So on Twitter G it's my first name with an add a G G G R G U R. I'm sure that's going to be listed. Also, well I am trying to pin up my own website. I've had the domain for grgur.com for the longest time. If you want to email me at grgur.com, actually grgur at grgur.com or it's easier at moduscreate.com, feel free to hit me up. I actually love communicating about everything we are working with. I love solving problems. I love hearing about problems. So feel free to do that. If there's anything you see on those YouTube videos, feel free to comment. I really try to respond to every single one of them. And that's it. I really enjoyed having this opportunity. I love the challenges. Thank you for that too. I know it's a complex topic. It's not always easy to introduce something like that. So I really appreciate having this opportunity. 

CHARLES MAX_WOOD: Awesome. All right, folks, we'll go ahead and wrap it up there. Thanks again for coming. This was a lot of fun. And- 

GRGUR_GRISOGONO: Thank you for having me. A lot of fun indeed. 

CHARLES MAX_WOOD: Till next time, folks. Max out. 

DAN_SHAPPIR: Bye.

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. To deliver your content fast with Cashfly, visit c-a-c-h-e-f-l-y dot com to learn more.