The Power of Micro Frontends & Breaking Down Monoliths | Thayse Onofrio

0:00If the developers are not comfortable with the technical side of it, they don't know much about it. they might have some concerns initially. So I would say that's more like a challenge, just making everyone feel comfortable with that as they go along. But outside of that, I think folks are generally happy about just having this independence and ownership. So you heard it here. Do micro front ends, your developers will be happy. How can you drive developer productivity, lower costs, and deliver better products? On June 20th and 27th, Linear B is hosting a workshop that explores the software engineering intelligence category.

0:37We'll showcase how data-driven insights and innovative workflow automations can optimize your software delivery practices. At the end of the workshop, you'll leave with a complimentary Gartner Market Guide to software engineering intelligence and other resources to help you get started. Head to the show notes or linearb.io slash events to sign up today. Hey, everyone. Welcome back to Dev Interrupted. I'm Ben Lloyd Pearson. I'm the Director of Development Relations at Linear B. I'm pleased to be joined by Thaise Onofiro, the lead software engineer at ThoughtWorks. Thaise, thanks for being here.

1:10Thank you. Thank you for having me. Very happy to be here. Yeah, wonderful. We were talking, we had a long trip from Brazil, so glad you made it here. So we're going to talk a little bit about the session that you have here at this event, but I'm sure we'll touch on other subjects too. But the main thing is that as apps expand, so does the number of teams that are needed to manage the various functionalities. And without the right infrastructure, this growth can lead to a host of issues from communication challenges and code conflicts to busy pipelines, tangled release interdependencies. It can be a pretty complex picture.

1:47And your talk is all about the solution you've come up with, which is micro front ends. And this architectural approach has allowed individual application components to be operated and deployed independently to sort of get out of that like monolithic maze that a lot of companies are facing. So I want to talk about, you know, what the future of front end development looks like within this context. But before we get into that, let's just get into the basics. So what is a micro front end? Great question. So when we talk about micro frontends, and yes, very much related to microservices, what is more popular, but the same way micro frontends, we have like smaller frontend applications, but we can develop and deploy them independently from each other, each having their own responsibilities, but then they all look the same for the user.

2:37So as a user looking at this application, like if it's a web application, it doesn't really matter to me how it's done, how everything was created. But when we look into how it's been done, developed, deployed, everything is separate and we just compose them together. So for a user, it shouldn't really matter. But for the teams working on it, it makes a lot of difference if it's not like a whole monolith and we can work on our own thing without having so many conflicts and blocking each other all the time. Awesome, awesome. So let's talk about some of the unique challenges that you've encountered while doing this.

3:13Because, you know, I like the comparison to microservices. That concept has been around for a little while, so people are pretty familiar with it. What are the unique challenges that you've faced while you've been implementing this micro front-end practice, specifically related to the monolithic architecture? Yeah, I think with monolith architecture, especially when the teams start growing too much, we can get a lot of conflicts. And if you have different teams working on the same code base, but maybe even different products, it can be very confusing for everyone working on it. There needs to be a lot of communication within everyone.

3:52And that doesn't happen if you have separate teams. Even in the same team, sometimes there is not enough communication happening. So we start to face a lot of issues. if we are using the same pipelines, like the pipelines are always busy, there is no enough resource to handle it. So it starts to get really challenging. And I think one of the most pain points is deployment because you have to, one team depends on the other team to do a deployment. So you don't have that flexibility about just being able to deploy whatever you want. It can really slow the team down having to defend one team or the other.

4:28So I think that's where and a lot of times going towards this micro front end approach really helps and then we can and there are a lot of different techniques we can use to get to this approach uh but yeah i think definitely looking into that and seeing what makes more sense for your team depending on the tech stack that the team is comfortable with as well uh you can find an approach that you can start like slowly going towards this and separating things out as much as possible that brings a lot of benefits, I believe, to the teams. Let's dig a little bit into the technical side of this. Have you been relying mostly on out-of-the-box solutions or existing libraries that are out there, or did you have to build a lot of this yourself from scratch?

5:10I think now there's a lot of options. I think previously, mostly doing that on the server side. But now we have, and I will talk on my talk as well a lot, about using Module Federation, which uses Webpack to do it. So it's way simpler because now A lot of front-end teams are already using Webpack. You already have everything configured. You just need to add a new plugin to use Module Federation. So that really helps. But yeah, I think there are many more solutions now. It's becoming more popular. And it's easier to get started, I would say, for most teams that are already using a lot of those technologies.

5:49So in front-end libraries in particular, I feel like that's an area of technology that has just, I mean, it's become a meme, just how many different libraries and services are out there. I see all these posts on social media about how there's too many of them and how when everything is working together in sort of the golden package, it can be great. But the moment you try to break out of the cookie cutter formats, particularly with JavaScript, it can get pretty difficult. Because there's hundreds, maybe even thousands of libraries that you can choose from out there. So I'm wondering, how did this complexity affect your ability?

6:31Did you have to change how you approached the challenge? Were there specific groups of libraries that you found beneficial? Just in general, what kind of challenges does that complexity of just how many options are present? That's a great question. I think a lot of people actually say that one of the benefits of using micro frontends is that each micro frontend that you have can have their own tech stack. So you can choose to do this frontend in one library, this other using another library, and then you just kind of stitch everything together. That's possible. That works. But I wouldn't recommend it.

7:08so if you are looking at the same view and you are loading just as a user going to a web page I would have to download a bunch of libraries dependencies that not really needed and that can really become complex to manage and really affect the performance so it's that kind of thing that it's possible but that doesn't mean you should do it and even if you are using the same libraries you have to be careful about versioning If you have different frontends in different versions of those libraries, how will they interact once you are composing them together? So that's a big concern, I would say, with using micro frontends as well.

7:49Being careful with using so many different libraries. And the system needs to work together well. So you need to have a lot of coordination between the micro frontends in a lot of ways. And I think dependencies is one of them. Yeah, so do you give teams a lot of leeway to sort of build that or define that path themselves? Or do you rely more on sort of like, do you give developer teams solutions or guidance on this? Or do you let them kind of choose their own path more? Yeah, I think there needs to be a lot of coordination in that, in a sense. And I think it's a bit challenging because you do want the teams to have their own freedom of choosing what path to follow.

8:32but there needs to be some kind of governance around it. So I think it really depends on each context and each team. But usually having someone that can at least set the guidelines, set some guardrails around it really helps. So you avoid having one team going a completely different way than the other and then creating those complex challenges. So yeah, just having a forum for the teams to talk about it as well really helps. but I would say just setting guidelines. And I think a lot of teams also use these templates to get started as a micro frontend. So you have some libraries there, you have some guidelines that are automated already to get started.

9:18So at least teams get started in the same direction. So one other thing that you mentioned or you mentioned in your talk is some of the complexities around build pipelines. So a monolith is typically going to have very different build requirements from a front-end microservice. So how has that played into this equation? And what sort of things have you had to do to overcome challenges with that? When we are in a monolith approach, the pipeline, we need to handle everything related to that so we can become challenging. and then when we start to break down each frontend monolith, microfrontend actually, will have its own build pipeline so you can build and deploy code independently from each other.

10:08But I think it really helps that you can add the sort of validations that you need based on that specific piece of microfrontend, which doesn't necessarily is the same as the other. So you can really adapt that and make sure that you are having the right validations, you are building code the right way for that specific piece of code and getting that interproduction. So yeah, I think it just gives a lot more flexibility so each team can do what's needed for their own challenges. Yeah, sure. And it seems to be like that's a big theme with rolling this out. How many developers do you have at your organization?

10:48It really depends on the teams that I'm working with as a consultancy. It changes a lot. But I think the last time I was working with this, in my specific team, I think we were around eight people. Okay, gotcha. Because I just know when things get big and complicated in the developer's world, it is great to offer a lot of those templates, effectively, that sort of set them in the right direction. But there's always just so much nuance to the technologies, to the processes those teams use. So I'm wondering, what does it take to migrate from this monolithic design to one where you're doing more micro front-end, maybe even some microservices?

11:33What's step one? What do you do after that? Is there a predictable progression or is it more nuanced than that? Yeah, I would say that the initial thing and one of the most challenges part is understanding how you are going to do that in terms of which parts of the application can be separate modules, how you're going to break things apart. So thinking about bounded context and how do you get to that approach of knowing this should be a separate module, this other thing should be its own module. So I think that's the most scary part in the beginning, trying to do the right thing, because at the same time that you want to get all the benefits of separating things out, you don't want to get too granular because otherwise then you are just adding new challenges and not really getting the benefits out of it.

12:22So there needs to be a balance of whether it makes sense to do it or not, much like microservices. And yeah, if we are able to align the microservices approach with the micro front-ends approach, I think we get a lot of value out of it because then we have this one deployable unit of code and getting all the benefits from all of that. But I would say, yeah, the first thing is understanding exactly how to do it in terms of which will be the physical and ownership boundaries of those micro frontends. And then you can start looking into thinking about the trade-offs, like what will be the benefits added, what will be the new challenges that we'll get.

13:05Because there is always trade-offs, always we need to think about the new challenges as well. And then I think we can move on to like choosing the approach, how we are going to do that and really take into consideration what's the team's knowledge of the tech stack as well. So you can choose an approach that makes sense for the team, that it's not everything new for them, that they need to learn everything from the beginning, you know. So then after you do that, I think you can start actually doing the migration and thinking about small steps as much as possible. What's the minimal thing that you can do that you can start already to get some value out of it before you move on to increasing that.

13:47So doing that as slowly as possible in a way that we are not impacting user experience, right? Because we can't just stop working in what is live in production and stop maintaining it, stop adding functionality to it, to start working on something new from scratch. So we need to find a way to do that a little bit more slowly and starting to get value out of these changes. Nice. Use a phrase there that I've never heard before that I want to dig into a little more, bounded context. That is, I feel like I should know what that means. Maybe can you explain a little more like what exactly you're describing there?

14:24Sure, yeah. So bounded context is a concept from Domain Driven Design, the DD. So here we are talking about this, finding these boundaries, about like physical and ownership boundaries. and it really means that each bounded context should be an independent service and in this case talking about microfrontends that should be evolved independently from one another so developed and maintained independently but while they should work together to create this unified system. So really what we want to achieve here with microfrontends but it's a concept that doesn't really need to be attached to a specific approach like microservices or microfrontends But I think both of these approaches feed from bounded context and DDD in that sense.

15:13So it kind of sounds like this is kind of a critical aspect of understanding where to begin effectively. It's like, where can you pick a part of your UI that you can just pull out and make that your first microservice? So for an organization that is like, wow, this sounds amazing. I want to do this. Like, how do they find that first thing that they can divide off that way and start their journey? That's definitely, I think, very challenging. And I think it really helps to think about the user flow, like how the user interacts with your page. So you can start to think about what is the flow that the user is doing here.

15:51and you kind of start seeing that the user is going to focus on one specific part instead of the other. So you start to see how things are separate from a user point of view. And then you can think about how that would make sense from the development team point of view as well, starting to separate that out. But yeah, I think using a lot of those DDD tools as well might help. I'm not an expert in it so I'm not going to dive deep into that but just studying a little bit about it I think it would really help for someone who wants to start going towards this and separating things out, trying to think about what approach you use for that.

16:35Wonderful. So have there been any sort of cultural changes that you've had to do in terms of how people think about how they build code or the way they approach problem solving as a result of adopting like a micro front end framework you know so beyond like the technical challenges even the process like is there is there cultural challenges that you have to overcome as well from an engineering perspective great question yeah I think mostly teams are more are usually happy you know about being able to have more ownership about their own things, not having to rely so much on other teams and other folks and just having more independence in that way.

17:22So I don't think there is so much cultural challenge. It's more like opportunity, right? It's a way to empower developers while also giving them a framework to be a little bit safer, have a little less risk, I imagine. So yeah, that's actually a great point, I think, Because this is a great way to encourage your developers to be a part of a positive cultural change. Yes, definitely. I think the only challenge more related to that, I think, is more if the developers are not comfortable with the technical side of it. They don't know much about it. They might have some concerns initially. So I would say that's more like a challenge.

18:02Just making everyone feel comfortable with that as they go along. But outside of that, I think folks are generally happy about just having this independence and ownership. So you heard it here. Do microfrontends, your developers will be happy. So what's the ideal end state for this? Like pie in the sky, you've mastered the world of microfrontends. What does that future look like to you? I think there needs to be like, once we are in a state that is good, that makes sense for everyone, folks can work independently from each other. We need to be careful with having like some guardrails in place and always looking into that again, because software is not static, right?

18:55We are always evolving, always changing. maybe some part of the application previously was not very important, would not get much attention, and we decided not to separate it in a micro frontend at that moment. But one year from now, we need to build a lot of functionality into it. So now we are seeing a separate user flow for that, and now it makes sense to start separating it. So I think we always need to keep an eye on it and making sure that we are following up with the evolution of the system. So we can always think if, should we break this up? Should we go back to how we were? Maybe it doesn't make sense anymore, this approach.

19:38So yeah, just thinking about software is something that is always evolving. I think it's important. So we don't just think that we've reached this peak of everything is good now. Not going to have any issues because it will not stay the same. So we need to be constantly thinking about it and see how we can improve. Yeah, it almost seems like, if I'm reading between the lines correctly, it almost seems like what you're saying is that we need a world where developers can easily understand whether or not something is a thing that should be broken out into a microservice or a micro front end versus something that is better to be a part of a more monolithic structure.

20:17because it does sound like there's a lot of questions about when to do that, where to do it and maybe that is the future we need is just better clarity through talks and sessions like yours, right? Yeah, I think just empowering folks with knowledge and they can make those decisions and bring up when they see issues and things that should be changed, I think that's really important. Wonderful. Is there anything that you feel like we've missed that you'd like to share about your session or the work that you've been doing in this area? Yeah, I think one other thing that is really important about micro frontends, like one of the new challenges is thinking about the testing part of it as well.

20:59Because yeah, we can have a great testing strategy when we were in this monolith approach, but as we start to break things up and then we need to compose them, there is a new challenge of how do we make sure that we are composing things the right way, that maybe each application works correctly by itself, but then when we integrate it, how do we make sure everything is working right? So we are just thinking more about functional tests, contract tests, just looking into that to see what's the right approach. And I think also thinking about ownership of doing this testing, because you can have one application being displayed in multiple different views, So interacting with multiple other micro frontends.

21:43So who is responsible for making sure that the composition works as it should in those different views, for example. So, yeah, that's definitely a new important challenge, I think, that we need to think about when going through this approach. And, yeah, I would just say in general, just thinking a lot about the tradeoffs and, you know, thinking about the benefits that we add, but also about those new challenges. so it really supports us in making those decisions about when to separate things, how to do it and should we not do it, should we do it so just having all that knowledge in place I think we can make better decisions Yeah, so if I had to guess, I imagine micro front ends probably makes things like unit testing easier but then integration and end-to-end testing a little bit more complicated because now you have this monolith and the microservices that sort of have very different ways of solving the problem, right?

22:38Exactly, yeah. So we need to rethink our testing approach so we can make sure that everything is doing what it should, basically. Well, wonderful. I'm super happy that you were able to join us today for this conversation. Are there any other last words that you want to leave our audience with? Oh, yeah, just getting to know more about it. you know, just go after this knowledge about micro frontends, but also anything that makes sense to think about how we can improve collaboration between teams when working together and just trying these new things. I think it makes a lot of sense to experiment, see what works, see what doesn't work, but having a lot of flexibility to try things out and see what makes more sense and can bring more value to our teams.

23:26and yeah if you have those issues I think it makes a lot of sense to try Microfront ends out. It's not bulletproof. There are new challenges with it but it can really bring a lot of benefits so I would encourage folks to try it out. So if our audience wants to learn any more about you, your work the company you work for, where's the best place for them to follow? Yeah I actually have a blog. It's thaisianoffer.com so I write some stuff there I will publish some talks there as well so feel free to check it out also social networks the same handle yeah I think that's it wonderful well thank you Thaisa for coming to join our podcast today it's been a real pleasure yeah thanks thank you for having me