Welcome to React Roundup, the podcast where we keep you updated on all things React related! In today's episode, we have an enlightening discussion featuring Paige Nedringhaus as host, our panelist TJ Van Toll, and our special guest, Florian Rappel, a solution architect from Munich, Germany. Florian, a noted figure in the web community, especially in TypeScript, React, and Microfrontends, dives deep into a variety of engaging topics.

Throughout the episode, we explore the complexities and benefits of using React, often described as a "black box" for the way it abstracts away many details from developers. We also delve into the intriguing world of Microfrontends, where Florian provides a comprehensive overview of this approach, discussing its practical implementation and the organizational shifts it can entail.

Additionally, Florian introduces his new book, "The Art of Microfrontends," and shares insights on how to manage complex front-end projects more efficiently. Whether you're a seasoned developer or new to the ecosystem, this episode offers a wealth of knowledge and practical advice to enhance your development practices.

So, tune in for an insightful journey through the realms of React and Microfrontends, and get ready to elevate your coding game!

Lucas Paganini [00:00:00]:
Welcome to React Roundup, the podcast where we keep you updated on all things React related. This show is brought to you by Envoy and Top End Devs. Envoy provides high quality design and software development services on a client friendly business model. Unlike all other software agencies, Envoy allows clients to only pay after the work is delivered and approved. Visit envoy.com to learn more and reach out if you know a company that needs more professionals to help with design and software development. That's unvoid.com. And Top End Devs helps you stay up to date with cutting edge technologies like JavaScript, Ruby, Elixir, and AI. Visit topendevs.com to join their AI Dev Boot Camp, weekly community meetups, and access expert tutorials.

Lucas Paganini [00:00:53]:
I'm Lucas Paganini, founder of Envoy, and host of this podcast. Podcast. Thank you for tuning in. Let's jump into the episode.

Paige Nedringhaus [00:01:07]:
Hey, everyone. Welcome to another episode of React Roundup. I am your host today, Paige Nedringhaus, and I am joined by our panelist TJ Van Tull.

TJ Van Toll [00:01:16]:
Hey, everybody.

Paige Nedringhaus [00:01:17]:
And our special guest today is Florian Rappel. Welcome.

Florian Rappel [00:01:20]:
Hi.

Paige Nedringhaus [00:01:21]:
So, Florian, tell our audience a little bit about yourself and why you're famous.

Florian Rappel [00:01:26]:
Oh, I wouldn't say I'm famous, but, yeah, thanks for the kind words. Yeah. My name is

Phil Lopple [00:01:31]:
Phil Lopple. I'm a solution architect from Munich, Germany. If you know me, you may know me from my work in the web community, especially TypeScript, React, Microfront and c space, especially. You may also maybe know me because of my work in

Florian Rappel [00:01:47]:
the dot net c sharp community. I am

Phil Lopple [00:01:49]:
a Microsoft MVP, and more than 10 years now, Now depends if they what they do with accounting. They they switch. So so let's say, the award ceremony there, it was always the full year, then it's now, let's say, in

Florian Rappel [00:02:03]:
the middle of the year. So they always make it, let's say, both both years. I don't know. But anyway, it should be 10 years now. Either way, so this is also where I spend, of course, most of my time. I write articles. I write blog posts. I wrote a book recently, so it was a big achievement for me.

Florian Rappel [00:02:20]:
So a lot

Phil Lopple [00:02:21]:
of work, shouldn't be underestimated, and I'm I'm very happy that finally it got released. So I guess we will talk a little bit about that too. And, yeah, besides that, I'm contributing to open source on the on my professional work. I always do, well, architecture review, a lot of implementation work, and, working together with with a lot of different teams and a lot of different clients and always having fun just staying on top of the, say, technology advancements and just, quite some some interesting time that we are living in. So that's mean

Florian Rappel [00:02:56]:
a nutshell, so to speak.

Paige Nedringhaus [00:02:58]:
Wow. That's quite a list of achievements. I'm not sure when you find the time to sleep with everything that sounds like you've got going on.

Florian Rappel [00:03:05]:
Yeah. My rings are yeah. The good thing is, I mean, I have 2 little daughters, so sleep is pretty much off the table anyway. And then yeah. I mean, it just always goes, yeah, one step further and one step further. And, since it's all so much fun, let's say, writing all these these great React projects, working with micro front end, always, of course, being being interested in in everything that's happening out there. It's just, well, all too exciting to sleep, I would say. Yeah? But sometimes I often need to rest, of course.

Florian Rappel [00:03:38]:
Yeah. That's called vacation. It's their vacation with kids. That's that's what it says, I guess. But, at least so they're they're growing older, so the vacation days are also, my experience, a little bit expanding. Right? So starting with 0, now we are maybe a week of vacation per year accumulated. Yeah.

Paige Nedringhaus [00:03:59]:
Nice. I love the enthusiasm. So one article that really caught our eye was one that you wrote for Log Rocket, which we will link to in the show notes. And it's called React as a Black Box and Why Does This Matter? Do you think that you could give our audience, if they haven't read it, a little bit of insight into it and and your opinion on that?

Florian Rappel [00:04:19]:
Sure. Yeah. I mean, please read the article, everyone. But, to, let's say, summarize it in, 2 or 3 sentences. If you're using React, you are mostly well, not using it very much directly. Of course, you're writing, let's say, React components and all that, which are pretty much only functions these days. Most of the things that that React does for you, it does under the hood, which means you don't explicitly interact with this API, and it's really just a black box. So you just throw something in, and you expect it to work.

Florian Rappel [00:04:48]:
Your components being efficient, rerendering just happening very fast. You have a lot of stuff going on, but you just expect it to work. Right? And there are, of course, pros and cons to this approach. I mean, there's a reason why React is successful, and one of that reason is certainly that the black box, you don't need to care about what makes the decision or what what really goes on behind the curtain. But on the other hand, of course, sometimes you're wondering why is my component slow? Why is it not really behaving the way I think it is? And this is where the black box really comes from the other side. Right? And trust you because you can't really see what's going on and debugging this can be yeah. I mean, I don't know how much time I spent debugging rear components that don't behave the way I imagine they should behave. And personally, of course, I mean, you can already see that I have both sides and, yes, I'm a little bit torn apart.

Florian Rappel [00:05:41]:
I think I mean, that really great great achievement and what makes functional programming also great is that the runtime is doing a lot of stuff for you and you get a lot of guarantees then on your, let's say, programmer side that you don't need to take care of. Right? You just say, okay. I always have my stake here. I can be sure that no one else is shipping the stack because it's immutable, for instance, and all that. And you just work with it and you say, well, all these that they would make decisions is under the the hood, and it just works. And I think, there will always be this trade off, so it shouldn't be, too problematic in React's case. And, my personal point of view is, well, you can't test the, let's say, perfect thing here that just does everything for you, and you will never complain about it. There will always be these edge cases, and you will then, of course, pay the price in some debugging, let's say, sessions that you would have wanted to avoid.

Florian Rappel [00:06:35]:
But, yeah, this is the price we pay. Doesn't mean it's perfect. Doesn't mean we shouldn't try to improve it, And doesn't mean we can't criticize it. It just means that I think it's a good model after all, but we should be aware of it. And that's that's my personal point of view.

TJ Van Toll [00:06:51]:
Yeah. It's it's interesting. In a way, this is like the classical software paradigm, like how much do you trust a black box versus how much you control on your own. I feel like it's somewhat at least somewhat new to the front end world at least because back in the day, I feel like the jQuery days, like jQuery I I mean, obviously, it's a bit of a black box. It's it's got APIs that abstract things for you, but you could sort of fundamentally know what jQuery is doing under the hood. Like, the code could get a little bit gnarly, but, you know, they're like extracting browser APIs for you. They're they're doing some basic things. And if jQuery didn't do exactly what you wanted, it's like, okay.

TJ Van Toll [00:07:28]:
You at least had a rough idea of what was wrong or how to work around it. Whereas I feel like nowadays with stuff like React, and this isn't really specific to React because you could make the same argument for other frameworks as well, but there really is a lot more magic going on than there used to be. So if something went wrong in jQuery, like, I could probably go into the DOM at least get a high level overview of what's going wrong. But if, like, React doesn't reconcile my JSX, like, correctly in some situations, I mean, I I've certainly ran into and and this is rare, but sometimes I run into React situations where it's like, oh, man. Like, unless I unless I Google it and find somebody that ran into the same problem that has, like, some ideas of what I can do, like, it can be I can be at a loss because it's just there's a lot more complexity in the front end world than there used to

Florian Rappel [00:08:17]:
be. Mhmm.

Paige Nedringhaus [00:08:18]:
And there's just some use cases that React doesn't have a solve for. And this I think this came about earlier in React's life cycles, like when it was still using a lot of class based components. But there were some situations where if you like you wanted a model, for instance, to just pop out and sit on top of everything else that you could then either interact with or just close and go back. It was really, really hard or darn near impossible to make that happen in a way that made sense or was as easy as some of the other JavaScript frameworks like Angular made it. So there was a lot of at least for me when I was getting familiar with React and starting to learn, there were a lot of really frustrating moments where I couldn't do things that I would have been able to do pretty easily in other JavaScript frameworks. Mhmm. But at the same time, it's funny that you make that comparison of it being a black box because that's almost something that I haven't heard React described as in a very long time. It seems like Angular really took that and got hammered a lot with it because of all their specific syntax and components and the way that they wanted everything built and styled.

Paige Nedringhaus [00:09:31]:
But everybody's like, oh, React, you can do anything with it. But you're you're very right in that if it's something under the hood that we don't have either access to or any understanding of that's in their source code, yeah, we're we're limited in that regard.

Florian Rappel [00:09:49]:
I mean, the Angular example is a is a good one because that is I mean, if you look at Angular, I tried it a couple of times. And, I mean, there may be, some folks in the in the audience who completely disagree with me. But for me, that was felt wrong because they pretty much reinvented everything. And you couldn't even use other stuff from, you know, I mean, the plain JavaScript ecosystem because, I mean, you first had to wrap it in some some Angular specific notion of a a service or, you know, following all the terminology and and what they I mean, that they made a a great thing, but it was my opinion always, why do you need to reengineer that? That that's already there. The problem already ships with that. Why? But you need to wrap it just to bring it to your framework. And so, I mean, Angular maybe on the run time, people may disagree with me, less complex than than what React is. Certainly, there are other areas like injection, for instance, or what it does is meet the data reflection and bond where it is certainly more complex.

Florian Rappel [00:10:46]:
But if you look at the core of it, right, the reconciliation algorithm here, what really makes React special. So this is a lot of complexity that's completely hidden for you from you doing, let's say, your work usually. Whereas React Angular was always on this change detection algorithm and and so in this case, a little bit more lightweight. But then it brought all these complexity, also in form of what we could call a black box because it was also just showing terminology if you and use everything from our framework, and we then do something under the hood which goes back to basic browser APIs. Right? So you could look at it from 2 angles and certainly in some perspective, React was very open and Angular was a black box. But from other perspective, and this is really where we look at the core run time, it's the other way around. And then, of course, you can ask, well, what is the better way? Personally, I mean, I already I guess, you gave me nothing. I think React's way is quite good even though and this is great that you mentioned the model.

Florian Rappel [00:11:43]:
React always try to then, let's say, find solutions. So they introduced, for instance, the portal API, which is a great API in my opinion. But in the last 2, 3, 4 years, we got a lot of new APIs. I mean, starting with hooks. We've got all these things that you certainly now use from React. Previously, we're only using, I mean, create elements unknowingly, but the glass components knowingly. And now it's it's really a lot of things like lazy you should use, I guess, all the hooks, of course, because they are awesome even though highly debated. And so now you have this whole zoo, and and I'm not even starting the strict mode and all that stuff.

Florian Rappel [00:12:20]:
So where you that you also should know. So also here, I mean, suddenly complexity goes into the API, comes at the user, and we now need to make decisions. So it's it's not as severe as with Angular, but it starts also to shift here. The worst case is, of course, if you have, let's say, API complexity like Angular, plus you have the internal complexity because suddenly you need to know a lot of things to use it and then you need to look to know to know a lot of things to debug it. And it's just like, well, I don't know. I mean, let's hope it doesn't go in that way. If it goes, React will not be that successful anymore, I suppose. Yeah.

Florian Rappel [00:12:56]:
I don't know.

TJ Van Toll [00:12:57]:
I'm curious, like, based off this, like, what advice you have for, like, the just the average React developer, like, building their their apps. Is this something you think people should just be aware of? Is this a reason to, like, avoid React or use it only when you need it? I'm I'm curious what advice you'd have for people.

Paige Nedringhaus [00:13:17]:
Still reach for it?

Florian Rappel [00:13:20]:
I mean, I always reach for it even though I'm very, let's say, open for alternatives. Yeah. These days, I mean, a lot of what I would call lightweight alternatives to to React. Things like solid chats, for instance, which say, okay, what React brought to the table, how you write components, this is really great. But maybe what other frameworks bring to the table, let's take for instance Svelte. Svelte is, in my opinion, also an awesome framework, is also good. So how can we combine these to make, for instance, the amount of JavaScript that we ship to the user, yeah, less heavy. And, I mean, this was always one concern with these, let's say, more bloated frameworks.

Florian Rappel [00:13:58]:
I mean, React is certainly not in that space. When when Angular started, I don't really want to, let's say, bash Angular. And please forgive me for always mentioning it. I'm just an Angular and you always think of 7, I thought. So, anyway, I was always shipping I always thought at least the guy is shipping for hello world 600, 700, 800 kilobytes of JavaScript, minified. Of course, Jesus, a little less. But, nevertheless, it's nearly a megabyte. And all you did was, I don't know, using HTTP servers in there.

Florian Rappel [00:14:27]:
And it did really some elementary stuff and not really a lot of pages, just, you know, one one simple page that was just fetching something. And, of course, in React, you could have that a lot more lightweight, but you still would ship, I don't know, a 150, a 120, something like that. Still 3 digit amount of JavaScript. So all you do is fetch maybe one resource and and display a little string on on the on the screen. Now, of course, one could argue, I mean, this is not what React will build for you. It should then be build a real single page application. And suddenly, if you have, I don't know, 1 one and a half megabytes of of JavaScript, hopefully, lazy loaded in chunks and so on, then it suddenly makes sense. You you can't afford bringing React and React DOM, especially React DOM.

Florian Rappel [00:15:09]:
I mean, React is still lightweight to to the end user. But then we have now these other frameworks like Solid, and they really aim for, let's take the small use case apart. We can still help you, make you productive, and then we just shift the minimal amount. So what is my recommendation? If all you want to do is write with something really simple, one screen, Just look around. You will find something that will suit you from how you approach the thing as a developer with the community also, enough documentation, and maybe also being efficient and lightweight. If you say you're building a full single page application, a tool like experience, I always call it. Let's say you're building the next Photoshop in the browser or something. I mean, React is certainly a good choice.

Florian Rappel [00:15:53]:
You can certainly afford shipping this 101120 kilobytes additionally, which Jesus, Jesus, maybe, I don't know, 50, 40 kilobytes. I don't know. Something in that range. So that certainly doesn't make a great difference. But that will be my my recommendation. There are a lot of great frameworks and, I mean, the principles and the the paradigm that we have across the table, you can find now in a multitude of of frameworks. And there are really some great ones. Just because they don't have so many stars or not baked by by Facebook doesn't mean they are worse.

Florian Rappel [00:16:23]:
Just look around, make sure that they are properly maintained and and not just stopped tomorrow. Yeah.

TJ Van Toll [00:16:29]:
Yeah. Well and I think it's just decent software development advice in general. Right? Like, abstractions in of themselves are not bad. Black boxes are not bad, but you have to accept a certain amount of trade offs. You have to make sure if you need the abstraction, if you need that complexity, if you're dealing with that level of problem, then great. Like, that's a trade off. It's probably good for you. But if you're solving a much simpler problem, you could probably reach for a much simpler tool, at least to start with.

Florian Rappel [00:16:59]:
Right. Right. And, I mean, this discussion with obstruction is also not new, but I'm surprised that these days, it seems like obstruction well, at least there is a little bit of, let's say, a trend in articles to say obstructions are bad. Be cautious here. And I mean, of course, they're right. There is no simple solution to say, oh, I mean, always obstruct away. We've seen and the Angular example, sorry, again, it it will be a theme that that I guess, that too much obstruction will just hurt you because you need to learn all these things too. Right? So at first, it starts simple.

Florian Rappel [00:17:34]:
Oh, which is one obstruction. I can save these 3 lines, but suddenly, oh, oh, which obstruction did I use to abstract these 3 lines? I need to find it. And suddenly, you're more concerned about finding the right function that you extracted formally than just to to do the coding. Right? And, so there's always this trade off and there's certainly no one size fits the model solution here like with everything. Right? So this is one of the things that always criticize many articles only say, oh, this is good or everything else is bad. Yeah. I mean, there's always a reason why, for instance, why exist even though why is now bad and x is the new new thing to do. Right? There was a reason for that, and we shouldn't forget that reason.

Florian Rappel [00:18:16]:
Maybe, of course, technology advanced and maybe why is really not the thing to do anymore, but maybe there was a reason and that reason just well, in this context is not valid anymore or something else should be, let's say, considered too. And it's always good to know the trade offs and what other things exist and in in what context that makes sense because, yeah, I mean, there is in my opinion, there is no real black and white always. It's just gray. And you need to find which shade of gray fit to your particular problem. And, I guess, yeah, we can discuss it in the React context, but as you said, it's all in soft I mean, I guess, also generations before knew that. And we we we also learned it again, at least I do. And, yeah, it's always a little bit of this cycle that that, goes around, and we just need to see, right, where we end up with, where we are currently, and what we can do to just, yeah, not make the same mistakes again. I mean, I think this is the only thing to to really go forward, to reflect a bit, and to to find, let's say, a better way forward and to not forget why we picked that one.

Florian Rappel [00:19:21]:
The why is quite often really crucial.

TJ Van Toll [00:19:24]:
Yeah. I feel like the I the ebb and flow is an interesting way of putting it because I feel like that's we've had cycles like that before even in the front end world. Like, I remember there was a time where pretty large JavaScript frameworks were quite popular. There are things like Dojo, Incentia, things that were fairly, fairly heavy that got popular for a while. And then there was the push towards jQuery and, like, smaller things. And then now we started to creep back up again with some of these JavaScript frameworks. And I almost feel like this is true in the build tools world as well. Like, there's I mean, there was a while where Webpack had, like, a monopoly and everybody was totally cool with it.

TJ Van Toll [00:20:03]:
And now it's, like, cool to be, like, counter Webpack and to be using all these, like, hip new strangely named tools that are, like, different and smaller and faster. And it's it's like we just as an industry, we can't make up our mind. Like, as soon as we go too far in one direction, we come back in the other.

Paige Nedringhaus [00:20:22]:
Yeah. It's very much a pendulum of of popular opinion. But one thing that I remember from a senior developer telling me once, which I I liked a lot, was that if I could explain to him why I had chosen a particular way to solve style or whatever, he was fine with it. He just wanted a reason for why I was choosing to to solve a problem other than, well, it was like this and the rest of the code, or I saw somebody online do it, or somebody told me if I had a valid viewpoint, he was totally good with it. It was just have a reason for why you're choosing to do it this way.

Florian Rappel [00:21:01]:
Mhmm. I I think there's a good attitude. But, I mean, code reviews or let's say yeah. Just knowing why things went in a certain directions are always good to, let's say, be based on on, well, this kind of knowledge because at the end of the day, I mean, there will be always also new people joining team plus, of course, people that are not as as on on your level or as senior as you. And so for them, knowing the reason is also really good as a learning experience either to the company, to the project, or to to software development in in in general. Right? And so I I always think that quite often we are not asking the why or answering the why good enough. At least I noted for myself. So I think this is always something we where we can be also, yeah, full of critics of ourselves and always try to improve.

Florian Rappel [00:21:50]:
Yeah, I think the the why question is one that is, also, of course, if we go back to the black box topic, one that you don't really see them. Right? This is again, you're interacting with something where the system is is completely hidden from you, so you don't see why things why it ends up in this state. Yeah. And microphone lines would be also a good why question. Why are you doing microphone lines? This is something I get asked a lot these days because, believe it or not, I don't know how you guys feel about microfinance, if you heard a lot about it or on what side of the pendulum you are, but this is again like Evan's, guy who's saying, we just had micro service, didn't work or was used for everything, and and, shouldn't be used for everything. Totally agreed. Then the other guys will say, oh, Microsoft is also great. Now we need to do microfinance.

Florian Rappel [00:22:38]:
We don't know why because our our front end is working great, but we want to do it. And so, I mean, also here at the full spectrum, we'll really be eager to know what what your opinions are on this one.

Paige Nedringhaus [00:22:50]:
Well, that's a great segue actually as we were talking about things that are gaining popularity. So I have not really worked with micro front ends. I've worked in a very heavy microservice environment where we had different back ends, mostly serving 1 per one single front end. But I'd love to hear more about what is the use case because I've had pretty big mono repos that are massive React projects. So I could see if you could break that up. That would possibly be useful, but I'd love to hear more about how this came about and your your experiences with it. And, TJ, I don't know if you've ever worked with micro front ends either.

TJ Van Toll [00:23:31]:
Yeah. Similar experience. I've I've got a back end with micros or a background with microservices, but never really had a use case for a micro front end. So maybe so maybe a good place to start is maybe you could just give us, like, the the very simple, like, 101. What is micro front end? Why would you use it? That sort of thing.

Florian Rappel [00:23:51]:
Yep. Alright. So MicroFundend is all about distributing the work on on a front end application. And there are various ways to do it, which is where the complexity already comes into play here. So you could, for instance, do what you just described as a monorepo. You could do that. You could say, okay. We just now make certain libraries, let's say, component libraries, for instance.

Florian Rappel [00:24:13]:
And in order to, let's say, have it still altogether, we have them in the monorepo and we have one large build. That That could certainly justify, let's say, or could be counted as a micro front end, but then we still have maybe large or longer build times, let's say. We still have maybe conflicting, yeah, poor requests, and we still need to give everyone access to this. Plus, of course, yeah, CICD, I already mentioned the long build time. Now everyone, of course, shares the same build pipeline, which means this is always, let's say, the one bottleneck potentially. And so there are, of course, other ways. So one way is to say, okay. Instead of having real microservices, we now have micro web servers, so to speak.

Florian Rappel [00:24:57]:
So servers that still, yeah, are there, but instead of serving, for instance, JSON, they may still do. They now serve also HTML. And then we combine these things, for instance, on a on an, reverse proxy. So we we have 1 like an API gateway in front of it that now takes these different HTML fragments, puts them together, spits it out. Challenge here is, of course, how do you now debug this? You're responsible of one of these fragments. How do you get that? And who's responsible for for, let's say, maintaining that reverse proxy or this let's call it micro frontend gateway. The area where I'm mostly working is in the third one where you say, oh, what you can do is you still may have something like these component nips, but instead of needing a a build process with tooling like Webpack or another bundle, You deploy them independently in form of still JavaScript, for instance. And now you combine them in the front end.

Florian Rappel [00:25:53]:
There are a couple of popular approaches. Usually, what you do here is, of course, you have the single page application And sometimes people call it in a single page application or single page applications because each of these JavaScripts can be independent single page application. I'm not really into that one. But nevertheless, you can can, of course, refer to it. The gist of it is that you need some orchestration engine now in the front end that runs in your browser, on your web app, and that can handle now getting these different JavaScripts and bringing them together, isolating them as well as possible even though, I mean, there are limits, of course, in document object model. If you want the true isolation, only way to do it is an iframe, which is problematic for a couple of reasons. Then, of course, we have the web components here in this space. They allow us at least to have proper style isolation, which is great and can be also not so great.

Florian Rappel [00:26:44]:
My opinion is born a partier. And, but we still have from the scripting perspective a lot of potential conflicts. And then we can also do something like, yeah, send a script injection with e ESMs or UMD modules. And here, things like, SingleSpa or the framework where I contribute to, which is called Pyral. They help you to to use that as an orchestration engine. So in the end, it's really about that you allow different teams to work on the same application even though they have their own repository, own CICD pipeline, right, which allows to ship new updates of the code or a new feature in in really seconds to minutes depending how it is all set up instead of waiting longer and maybe having more bloated processes sharing things. So this is what it is about. A little bit like in the microservice department, also here, you often hear hear one argument.

Florian Rappel [00:27:39]:
You can now use independent technology. So one team uses React, another uses Angular. Well, let's not go there. Right? Personally, I I would say you should try to to have a set of core technologies because it's the front end. If you combine it in the front end on in the browser, right, you ship all that to to users' browser and you should suddenly run 10 frameworks in this yeah. Maybe on a mobile device, it will not be a great experience. Right? So you should maybe try to to limit it to one or maybe there's another cool framework that's used in a particular page or particular part of your page, maybe you should try to limit it. But I guess it's the same again as with microservices that is the goal was also never to have a patchwork of technology that was always to just, you know, allow you to different technologies that's been the best thing, the best tool for the job.

Florian Rappel [00:28:28]:
If you have their service that deals a lot with, I don't know, data manipulation, you can use a language or framework that's dedicated to that. If you have another service that I don't know, you should do something else and you have a team that only knows, I don't know, csharp.net that can use this this one. And I guess it's similar here. Right? So you shouldn't just because you can doesn't mean you should. Yeah. It gives you a little bit more freedom and this is what Microphones is about, giving you this freedom to actually, yeah, have distributed development possible and be a little more flexible in in a journey that we got. But they are, of course maybe that's a good transition there. They, of course, counterargument too.

Florian Rappel [00:29:07]:
Right? So complexity wise, we do that too. And, you need somehow to, yeah, have this orchestration layer under control. You also need new processes because, yeah, now teams can maybe deploy independently. Maybe you don't want that. Yeah. Maybe you want that. It it always depends. And so you always, of course, also hear shift complexity.

Florian Rappel [00:29:29]:
Right? So you gain something, but then something else is maybe a little bit worse or challenging than before. No silver bullet there too.

TJ Van Toll [00:29:36]:
Well, no. It's interesting because I'm thinking, like so it helps my brain to think in terms of, like, concrete examples. So I imagine I'm building my, like, standard React app, but I have a shop, and the shop is quite a bit different. And so today, because I my brain doesn't think in terms of micro front ends, I would think like, oh, okay. My shop is quite a bit different, so I'm gonna wanna do my best to make sure I'm, like, lazy loading that or, like, deferring loading of that. But I would still my gut would still be like, oh, well, of course, I'd keep that a part of my same React application. Right? I just make sure to try to do my best to lazily load this stuff in. It sounds like the micro front end approach would essentially say that shop would be almost like its own separate project in a sense.

TJ Van Toll [00:30:23]:
Right? That it would that there's some, like like you said, orchestration layer that figures out how to bring that app in and reconcile it. So first of all, I'm curious if my understanding of this is correct. And then I'm also trying to get, like sounds like the benefits of this is it's because it's, like, it's isolated thing, then the team that's working on it can kind of work on it, potentially even, like, deploy it without worrying about the rest of the app. Like, if you're, we assume the rest of our React app is quite large. It probably would take forever to build and test and deploy. And having, like, little logical sections of these isolated, I could see some benefits of that. But like you said, I could also see trade offs. So I guess, first of all, is my understanding of this correct? Does that use case sort of make sense?

Florian Rappel [00:31:06]:
Yeah. It makes regarding the shop, most I mean, there are a lot of ecommerce companies that that use micro front ends. Most of them, however, don't do client side, what we call client side composition. So where we already ship a JavaScript that acts as the orchestration layer and then brings together the the other script. Most of these companies actually do the server side composition here. The reason is that, first of all, their parts are not really so much about interactivity. Second, they care a lot about performance. So they really want to have something that can be precached and so on and they just send it out to the end user that as fast as possible, right? So they follow this 100 milliseconds of of additional loading time means that less revenue.

Florian Rappel [00:31:49]:
And so they always try to optimize here. But nevertheless, there are, of course, also ecommerce shops that are built using micro frontend using a micro frontend approach. And for that yeah. So what you would do usually, but there are, of course, lot of different approaches. But what I personally like as an approach is you that you follow here more domain driven approach. So what you would want to do is you identify, first of all, the grand theme of your application. Well, it's in the ecommerce space. Right? But then you start identifying subdomains here.

Florian Rappel [00:32:21]:
Right? So one subdomain could be, I don't know, a recommendation model. So you're on the product details page. You want to see a list of recommendations related product, I don't know, products that may only make sense for the for this particular user. And so there could be one team just working on, let's say, UI fragment for that. This team may also want to bring in, I don't know, something in our menu bar or some some menus here that we that we offer. And we may have another team that only works on maybe the product details page. There may be a search team working just on the product search, and product search is also interesting because while it may have a dedicated page, right, search results and so on, it also has, of course, maybe a search bar that's always visible and they own this bar. Right? So every input and so on that's owned by this one team.

Florian Rappel [00:33:06]:
And so on. So you would actually not just one screen and say this one screen belongs to this one team, but you would actually do it Well, I actually decompose every screen that I have and maybe I have some main content of the screen that goes into particular team. But then I see other components that may be on a lot of pages, maybe all pages, may only be in a few pages, but identify in what domain does this fragment of UI lie. And this is what microphone is about, that you can assign the the correct team that only, let's say, deals now with search, the search bar and the search page the search result page, and they will do everything with it. And then if there's an improvement for the page, they can ship it completely independently, and they are just responsible for for that. There there are also approaches out there. I mean, one that is certainly easier to implement, but in my opinion, will lead to, well, let's say, more frustration team where you divide the UI by what you see on the screen. So you just say, oh, there's a header.

Florian Rappel [00:34:04]:
That should be a microphone. And then the footer, should be another microphone. And there's a navigation bar. Should be a 3rd microphone. And, yeah, you see that there's a quite a lot of beginner tutorials. In my opinion, it's there because it, of course, makes sense visually, and it's easy to implement. I mean, easier maybe. But on the other hand, of course, it will have a lot of frustration points because suddenly, this team that's doing the navigation part is always, let's say, dragged and pulled by every other team.

Florian Rappel [00:34:31]:
We need something in here. Under this condition, we need it. Can you just update that? We have a new icon, and it will never work out smoothly. I mean, you just create it now. Yeah. I don't know if there's a word for it. Maybe spaghetti module store. I don't know.

TJ Van Toll [00:34:46]:
Yes. Spaghetti is good.

Florian Rappel [00:34:47]:
We can we can we can invent something now here. But but it's really it it will not be maintainable in my in my experience. And so I always advocate for him for the identifying domains and putting those into, let's say, Teams or micro front ends, which are then responsible or in charge yeah. Well, certain teams are in charge of them.

Paige Nedringhaus [00:35:06]:
That's what I was going to ask is how do you do you have any advice for how to know when a project has gotten so big or something a piece of a project is so complex that it should be broken out? Because it seems like that's a very that might be a very difficult thing to identify when when is the right time to to break this into its own separate front end.

Florian Rappel [00:35:30]:
It's a good question.

Paige Nedringhaus [00:35:32]:
It depends.

TJ Van Toll [00:35:33]:
No. No. That's okay. I

Florian Rappel [00:35:35]:
always say if you're happy with your monoliths, don't change it. I mean, there's a reason for it. Also, I mean, we started with with the monorepo. Right? And I said monorepo can also be something like a microphone and solution just now combines the different pieces of build time, which is also fine. Right? So if you start with a monorepo, for instance, if you say, I don't know if you ever need this microphone and stuff. But it would be nice to architecturally maybe group it. My my advice would always be, we'll start with a monolith, but do it in a monorepo because if you did that, it will be easy later on to just extract out certain modules and just put a little bit of with the right framework, debugging, etcetera, capabilities on it. And you can have your distributed micro front end solution.

Florian Rappel [00:36:18]:
But you don't need to start with it immediately because that adds just complexity at a stage where all you should care about is really bring out your stuff and see that it works. But nevertheless so when is the right time to, let's say, make the transition? Well, I would say if the majority of the team members are unhappy. That's always a good time because if frustration grows, I mean, you suddenly have a pain point and you need to solve the pain point. People wouldn't be, let's say, pain if they would say, oh, we ship features too fast. Well, it's too much fun. We can experiment around this new stuff. Well, that doesn't sound like pain to me. But if they say, oh, my poor request is hanging there for 2 weeks, and we were supposed to ship that feature a month ago, But suddenly, all the bills take so long, and then there was this conflict here and conflict there.

Florian Rappel [00:37:04]:
Well, it sounds like something need to change somewhere. I'm not sure if microphone is the solution here. Right? But I'm I'm sure that something needs to change. And maybe microphone is then a good solution. If you hear as pain points, especially things like, we need to go faster, particular features, so this is really where microphone is may hit the nail here. But make no mistake, migration of existing applications, I mean, if we have this case that I just described, monorepo all nicely grouped, this is this is the beauty. This will work. But usually, it's not as nice like this because the application is 5 years old.

Florian Rappel [00:37:39]:
It started nice, but then duct tape here duct tape here. There was a feature that never someone thought of, so we needed to work around for it. Oh, how can we now do that in this distributed world? It will not be a pretty journey. I mean, certainly, the architecture will be more sound afterwards, and most time will not be spent in this microphone in space, but rather in how can we distribute it because we made it as spaghetti before it. But, certainly, I think this is when you hear hear enough people complaining, it's a good point to think about it.

TJ Van Toll [00:38:08]:
Yeah. Honestly, the the productivity and the sort of flexibility around this seems like the biggest advantage to me because I've certainly been on teams and been in projects where it's like, you put it in terms of happiness, but it's it's almost in terms of just, like, how how able you are to get stuff done because countless times where, like, you you go to deploy something and it's like, oh, no. We can't put push this out because this is in the way or no. This is tied to this really. So that's not ready. We have to back this out. We have to bring in the person who's really good at Git to figure out how to reconcile all of these problems. Right? And you keep stepping on each other's toes, and nobody wants that to be their day at work.

TJ Van Toll [00:38:48]:
Like, you wanna be shipping things, doing things, and software just being a complicated topic. I think as projects grow, as we work on bigger and bigger things, there's something inherent about that sort of stuff getting in your way. So it it's an interesting way of breaking it out because as you described it, you're talking far more granular components than I had, like, pictured in my head. Because, again, like, I went I immediately went to, like, oh, my entire shopping experience, but you're talking, like, just even, like, individual widgets, like the search or the the products thing. And it's, it just goes to show how, like, my mind does does not work this way just because I I haven't been a Yeah. I haven't really considered this. So now, like, I have to, like, retrain my brain to, like, when I see things like that to think, oh, like, that's that's an option or that's a potential way that I can attack this.

Florian Rappel [00:39:38]:
Yeah. I mean, it takes I mean, I'm now working in this now for already more than 5 years in the microfinance space. So when I started with this, there was the term microfinance wasn't while existing yet. So they they later on the I think it first came up in the Thoughtworks radar. I don't even know. Someone taught me a while ago Redwall's first point. But, anyway, that was then coined afterwards. Just retrospectively, I was like, now that's what that's what I was doing.

Florian Rappel [00:40:05]:
Right? Either way, I mean, you you don't start with that right away and and still, of course, getting the right decomposition right on on this domain that I described is also not easy. Right? So you you need, of course, domain experts. You need to know, people, of course, that that really understands the requirement of your solution that you either want to build or that you have built and not want to, let's say, roll out this microphone then. And, yeah, you need, of course, to then train the the people. Ideally, of course, this is the at least experience I had in most projects. I mean, if the micro front end setup was done well, developers of individual modules don't even, let's say, know that they are doing micro front end. I mean, they're just developing I mean, you tell them, you'd now do the shopping basket. And they're like, okay.

Florian Rappel [00:40:52]:
And then they develop ideally at least on this client side paradigm, like for a single page application. They even have the debugging experience completely the same as if you would the back of the brand application, right? Only difference is in their view, they only see, let's say, a naked application, maybe a low head of food in there, some design elements, and they are they are saying that they are focusing on. And all the other microphones may not even be there. Maybe they are there. I don't know. They're fused in. But you can decide it in the setup for instance. And, so they don't even know they just developed there, and they they don't need to know the particularities of this kind of style.

Florian Rappel [00:41:27]:
And I think this is a good way because we are back at the black box, I guess, here. If you would now know a lot of stuff or need to know all this stuff what's what's happening below, I mean, certainly would be great. And in certain edge case and conditions, it would help you. No questions asked. But in the 90, 95% case. Right? I mean, if the platform, if the run time already takes away all of it for you, and all you need to do is focus on your problem and how you solve that. No technological questions asked. No.

Florian Rappel [00:41:56]:
Oh, oh, I need to wire up this with that. No. You just focus on your domain specific problem. This is where you want to be. Because at the end, I mean, this is also where, for instance, our case, we are getting the money from. Our customer doesn't say we are paying you to be back React. No. We are paying you to bring the the shopping cart to life for instance.

Florian Rappel [00:42:17]:
And I think this working in your problem, I think this is what makes some frameworks productive and great and others, well, technological interesting. But, otherwise, maybe not that productive.

Paige Nedringhaus [00:42:31]:
So are these the kinds of things, and I'm sure much more that you talk about in your your book that you just wrote?

Florian Rappel [00:42:38]:
Yeah. The book is, I would say well, let me just hand in the camera. It's called The Art of Microphone Lens. You can find it on Amazon. It's released from the Puckt, yeah, publishing company. And, half of the book is very practical. So the I mentioned, let's say, the 3 grand schemes that we have in finance space. Right? Build time integration, service side, client side.

Florian Rappel [00:43:02]:
These are, well, all covered in here plus, of course, a lot more patents. So there's a lot of also here, a lot of shades of gray. Right? So I think it has 7 patterns and all of these very practically, introduced. But most of the or let's say, the other half of the book really deals then with how do I choose the right domain How do I now work with designers, for instance, because they will still design a monolith, and you need to teach them what you are you're doing technically that they will, well, give you the the best experience. Because at the end of the day, you will you will create something that is in its nature flexible. So for instance, the navigation bar, it's not cut in stone. Someone can just write a new feature and have a new item. How does it behave under these conditions? Right? So suddenly, designers need to go beyond the static screen design and really think about these things.

Florian Rappel [00:43:54]:
But also about organizational changes because, yeah, if you really distribute a code, suddenly responsibility should be also distributed and things like that. So it's really half and half. So one half, very, very practical. The other half, I would still say practical, but maybe not for the, let's say, standard developer, more, let's say, for architects or decision makers than and people to say, oh, and I want to know what what is beyond the horizon if we go that way. Yeah. And, certainly, it's one of the the things I cover. Yeah.

TJ Van Toll [00:44:26]:
And it's got a 5 star average on Amazon. So, I mean

Paige Nedringhaus [00:44:30]:
All of it.

Florian Rappel [00:44:32]:
It's a law law of small numbers, so I wouldn't say it's it's that

TJ Van Toll [00:44:36]:
No. You gotta market it. Sell the book. 5 Star. It's on Amazon. Like, it's

Florian Rappel [00:44:40]:
falling off the shelves. Like, you better get it now. Sorry. Yeah. I I didn't want not to spoil your enthusiasm. No. I'm always as you said, I always try to be honest. So at the moment, I mean, the book is fresh.

Florian Rappel [00:44:52]:
1 month out there or so. I don't know how many reviews it now has on Amazon dot com. On the German side, it has, I think, 2 reviews or 3. I don't know. Anyway, all 5 stars at the moment. It will not stay that way. So I'm I'm I'm a realist in this case, but still we will be happy if any guy any any girl wants to have a look at that. Just also you can give me, let's say, a message on Twitter, for instance, because I still have, I think, 15 or 25% off the ebook.

Florian Rappel [00:45:21]:
There may be a chance I still have, I think, some physical copies. So hard copies of this. That's like the one I owe demand. But I could get you for free, actually, if you message me. But these are limited, actually. I think I have 5 or 6 left there. But, anyway, if you're interested, always just ping me. I'm very open, of course.

Florian Rappel [00:45:41]:
And, sorry. I I want to sell the book more. It's the best endeavor. It even discusses web development in general in the introduction. You should read it. If you if you don't know what CGI, SSI, and so on, it's in there. If we talked about tooling, Webpack, parcel, it's all discussed in here. Why? No.

Florian Rappel [00:45:59]:
That's too new. That's not in this book yet. I think but I even, have years building here. So you can't say I'm yeah. I there's still pretty new stuff in here. It could be it could be all the confusing stuff. But, anyway, any kind of criticism also to me. Right? So if there is something you like to see improved, I don't know if there will ever be a second edition, but just tell me.

Florian Rappel [00:46:20]:
I always also love to learn. And, yeah, I'm not saying the book is perfect, but I try to put everything I know about microformity in there. Even though as always. Right? You finish the book and you're like, there's this one cool thing I didn't mention. But then I just make a blog post about it and then Yeah. There you go. Yeah.

Paige Nedringhaus [00:46:41]:
Well, that's fantastic. So, Florian, as we were talking about, if people wanna get in touch with you about your book or about anything else, what are the best ways to reach you?

Florian Rappel [00:46:51]:
I guess the best way is Twitter. Then my handle is floran rubble, just one word. Maybe we'll have the address also in there. Otherwise, I'm, of course, on GitHub. Some of the projects I'm contributing there to on GitHub. So this is a chat room. For instance, I'm very active in the Pyral chat room. So if you're interested in in the microphone and framework, Pyral, I will also paste the address in there, would be would be one to check out, and, we have the public get the chat room.

Florian Rappel [00:47:19]:
I'm very active there. You will see me chatting around, giving answers to Pyral in in particular or microphones in general. And I think we have a great community. In our channel, we have, I don't know, 160, 170 people. Not all, of course, active all day, but there's always one good answer for for every question. And I will paste it in the chat room. Yep. There it is.

Florian Rappel [00:47:42]:
I guess, the the best way to to reach me. Otherwise, of course, email can give you this. And, otherwise, on my personal website, there are also all the I mean, I'm also in Skype and so on. All the messengers. Right? You can reach me to messenger. Which one? Yeah. It's like with this x k t d comic about all the the standards. Right? So there are certain standards.

Florian Rappel [00:48:09]:
We need to embrace them all. We need a new one. They're now 40. It's the same thing here. So we need a messenger to have all the messenger.

Paige Nedringhaus [00:48:17]:
Yeah. Very good. Excellent. Well, now is the portion of the show where we move into picks. So, TJ, would you like to start us off this week?

TJ Van Toll [00:48:26]:
Yeah. I'm gonna pick some Marvel stuff. So I went to the theater for the first time and since COVID, which honestly was probably the the best part of the experience. It was just really I I I didn't realize I'm not a big movie person. I didn't realize how much I sort of missed the atmosphere of this actually going seeing a movie in person. And we saw Black Widow. It was pretty good. I we we definitely enjoyed it, but it set off, now we have to watch all the Marvel things.

TJ Van Toll [00:48:54]:
So now we've been on Disney plus and started WandaVision, which was quite the trip. Like, very, very engaging and, very interesting show. So highly recommend, I guess, go to if you can safely go to a movie theater now, I'd I'd recommend getting back to that. And WandaVision's been a pretty good show.

Paige Nedringhaus [00:49:13]:
That sounds like a good reentrance to the movies. Marvel movies very rarely disappoint me.

TJ Van Toll [00:49:19]:
Yeah. They

Paige Nedringhaus [00:49:20]:
always Nice. Well, my pick this week is going to be totally unrelated. It is a a GitHub course that I found, or I guess GitHub documentation, and it's called IoT for beginners, and it's actually made by Microsoft. But if you've listened to the show with any regularity, you'll know that I I started in a new job about a month ago now. And the job, while it is web development, it is working for a company that specializes in Internet of technology enablement called Blues Wireless. And so we we make things called note cards that connect to Raspberry Pis or Arduinos or to just the cloud by themselves. And so I need to actually understand how the Internet of Things works because I've never really interacted with it before. So so I'm starting with some of the really basic online things that are available to to kind of learn how to use Raspberry Pis and and get into that that sort of space.

Paige Nedringhaus [00:50:23]:
And this IoT for beginners is very comprehensive. It's free. There's videos. There's build kits that they recommend. There's all kinds of really useful getting started from the very basics, and I'm really enjoying it. So I would recommend that for anybody who's kind of looking for an an a foray into it. So, Florian, do you have anything that you'd like to pick?

Florian Rappel [00:50:46]:
Well, I mean, first of all, well, those are all good picks. Yeah. Black Widow, I still want to see. I've seen I can also stream it. It's €20, quite expensive, actually, for the streaming access there. But, anyway, WandaVision, I yeah. I I've seen the first two episodes. It was too crazy for me.

Florian Rappel [00:51:05]:
I don't know. I actually

TJ Van Toll [00:51:07]:
like most.

Florian Rappel [00:51:07]:
But that's that's You

TJ Van Toll [00:51:08]:
have to stick with it because it starts absolutely insane, and then they start to somewhat explain it.

Florian Rappel [00:51:13]:
Yeah. But then it it got better. But I I mean, they lost me. Anyway, the the Microsoft syncs are always great. I remember when Microsoft released, for instance, the cloud pattern, that was really great. So they always do a great job at documentation and being really comprehensive, really accessible and approachable. So that that is certainly kick ass. I need to check that out.

Florian Rappel [00:51:32]:
So my pick would be a book. Old book, but, I mean, that's for me, it's like a hidden classic, which is called, I don't know, your code as a crime scene. It's, yeah, an interesting book in that fact that sometimes, I mean, already things like, for instance, we we heard about Git here, leaf trails where you can see where the problems are in your code base. So for instance, if you see that, let's say, a certain amount of commits is always in in a part of your, application with certain file, let's say, that usually doesn't carry any feature, but, you know, it's just, for instance, some orchestration there, then you know architecturally something isn't right because after a while, I mean, it should stabilize pretty much, and you should just see, for instance, changes in, well, new files being added, new features coming along. And if you see a pattern like that, well, you have a very healthy application. Congratulations. Usually, especially in my own applications, I see a lot of commits happening to files where, well, they should be already stable somehow. But either I'm just in refractory mode or really something is not is not really done right.

Florian Rappel [00:52:38]:
And I mean, this book goes into a lot of patterns of detecting such fishy things, what you can do then, and well, yeah, following then your crimes to detect what to improve. Because after all, we shouldn't just reflect the for yeah. Reflect the reinstake, but we should reflect it and make things more productive. But for that, we first need to recognize what's all making us not so productive. And this book is, I think, at least for me, it was and still is when I haven't opened it, a great guide to that. I will post an Amazon link for it.

Paige Nedringhaus [00:53:09]:
Excellent. That sounds like a really good read and something that I will definitely be looking into. I'm always looking for for new ways to improve my own coding practices. Well, Florian, it has been an absolute pleasure to have you on. Thank you so much for joining us today on React Roundup.

Florian Rappel [00:53:24]:
Thanks for having me, it was a pleasure.

Paige Nedringhaus [00:53:27]:
Alright. We will see everybody on the next episode.