Exploring Micro Frontend Architecture with Florian Rappel - RRU 283

If you know a company that needs more professionals to help with design and software development, that's u n void dot com and top end Davs helps you stay up to date with cutting edge technologies like JavaScript, Ruby, Elixir, and AI. Visit topandevs dot com to join their AIDV boot camp, weekly community meetups and access expert tutorials. I'm Lucas Paganini, founder of Onvoid and host of this podcast. Thank you for tuning in. Let's jump into the episode.

Then let's say of ceremony there it was always a full year and it's now i'd say in the mid of the years, so they always make it let's say four years. I don't know, but anyway, it should be ten 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. So a lot of work shouldn't be underestimated. And I'm very happy that

finally got released. I guess the 'll talk a little bit about that too, And yeah, decides that I'm contributing to open source and on my professional work, I always do well architecture review a lot of implementation work and working together which is a lot of different themes and a lot of different clients, and always having fun, just staying on top of the say, technology advancements. And it's quite some interesting time that you're living in. So let's me in a natcha so to speak.

I would say. Yeah. Sometimes. The rest, of course, let's called vacation is the vacation with kids' date, I guess, but at least so they're growing older. The vacation days are also, my experience, a little bit expanding, right, So starting with zero, now we are maybe a week of vacation per year, accumulated.

its API. And it's really just a black box. So you just throw something in and you expect it to work. Your components being efficient, re rendering just happening very fast. We have a lot of stuff going on, but you just expected to work, right, and there, of course pros and constant is approach there. I mean, there's a reason why react is successful, and one of that reasons is certainly that the black box. You don't need to care about what makes the decisions or 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 in terts you because you can't really see what's going on and debugging this can be I mean, I don't know how much time I spent debugging real 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. In the years, I'm a little bit torn apart. I think, I mean, the really great achievement and what makes functional programming also created that the run time is doing a lot of stuff for you, and you get a lot of guarantees and on your let's say programer side that you don't need to take care of, right, you just say, okay,

I always have my state here. I can be that no one else is filing the step because it's immutable for instance, and all that, and you just work with it and you say, well, all these that say what makes the decisions is under the hood and it just works. And I think there will always be this straight off so it shouldn't be too problematic in react case. And my personal point of view is, well, you can't have 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 educses and you will then of course pay the price in some debugging let's say, sessions that you would have wanted to avoid. But yeah, that's a surprice 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.

like Jquerry. I mean, obviously it's a bit of a black box, it's got APIs that abstract things for you, but you could sort of fundamentally know what JQuery's doing under the hood, Like the code get a little bit gnarly, but you know they're like abstracting browser APIs for you. They're doing some basic things. And if jQuery didn't do exactly what you wanted, it's like, okay, 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 Jquerry, like I could probably go into the domin at least get a high level over you

of what's going wrong. But if like reacts doesn't reconcile my JSX like correctly in some situations, I mean, I certainly ran into and this is rare, but sometimes I've 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 be.

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, but 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. 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. But everybody's like, oh, react, you can do anything with it. But 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 limited in that regard.

There may be some folks in the audience who completely disagree with me, but for me though, it felt wrong because they pretty much reinvented everything and you couldn't even use other stuff from you, I mean the plane JavaScript ecosystem, because I mean you first had to wrap it in some angle, a specific notion of a service or you know, following all their terminology and what they I mean that they made a great thing, but it was in my opinion always why do you need to re engineer that

that's already there? Browdlary ships? Is that why? But you need to wrap it just to bring it to your framework, and so I mean Angler maybe on the run time, people may disagree with me, less complex, and then what reacted. Certainly there are other areas like injection for instance of what it does with me that day, the reflection and song where it is certainly more complex. But if you look at the chorretit right, the reconciliation algorithm. Here what

really makes reacts special. So this is a lot of complexity that's completely hidden from you doing let's say your work. Usually whereas Reacted, Angler was always on this change detection algorithm and so in this case a little bit more

lads weight. But then it brought all these complexity also in form of all what you could call a black box, because it was also just throwing terminology at 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 two angles, and certainly in some perspective Reacted was very open and Angler 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, hey, already, I guess we gave enough things. I think the React way is quite good, even though, and this is great that you mentioned the model. React always tried to then, let's say find solutions. So they introduced from the portal API, which is a great API in my opinion. But in the last two three four years we got a lot

of new APIs. I mean, starting with hooks. You've got all these things that you certainly now use from Reactor. Previously we're only using i mean create elements unknowingly, but the class component 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're awesome, even though highly debated. And so now you have this whole zoo and I'm not even starting the strict mode and all

that stuff, so that they also should know. So also here, I mean suddenly complexity goes into the API comes that the user and you now need to make decisions. So it's it's not as severe as the Angular but it starts also to shift. Here are the worst cases. Of course, if you have the API complexity like angular class, 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, oh, I don't know. I mean, let's hope it doesn't go in that way. If it goes X will not be as successful anymore. I suppose, I don't know.

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 bloaded frameworks, I mean React. It is certainly not in that when when Angler started, I don't really want to that they bash Angler, and please forgive me for always mentioning it. I'm just an Angler, and you always think of theven I thought so anyway,

I was always shipping. I saw at least the guy shipping for Hello worlds six hundred and seven and eight hundred kilobytes of JavaScript Mini Fight. Of course, jesuits a little bit less, but nevertheless, it's nearly a megabyte. And all you did was I don't know, using HTP service in there, and it really some elementary stuff but not really a lot of pages, just you know, one one

simple page. It was just fetching something. And of course in reactually could have that a lot more lightweight, but you still would ship I don't know, one hundred fifty one hundred and twenty something. That's that still three digits amount of javascripts for all you do is catch maybe one resource and display a little string on the on the screen. Now, of course, one could argue, I mean

this is not what REEC was built for. You should then build a real single page application, and suddenly if you have I don't know, one of the half megabytes of javascripts, hopefully lazy loaded in chunks and so on, then it suddenly makes sense you can afford bringing React and React on, especially react on. I mean, React is still white weights to the end user. But then we have now these other frameworks like solid and they're really

aim for let's pick this 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 a community, also enough documentation,

and maybe also being efficient and white weight. If you say you're building a full single page application, a tool like experience I always call it, we'll say you're building the next Photoshop in the browser something I mean, React is certainly a good choice. You can certainly afford shifting this one hundred one hundred twenty kilobytes. Additionally, which Jesus, Jesus, maybe I don't know fifty forty KO pipes. I don't know something in that range, so that certainly doesn't make

a great difference, but that would be my recommendation. There are a lot of great frameworks, and I mean the principles and the parading that reacts to the table you can find now in a multitude of frameworks, and there are really some great ones. Just because they don't have so many stars or not take by by Facebook doesn't mean they're worse. Just look around, make sure that they are properly maintained, and not just stop tomorrow.

But if you're solving a much simpler problem, you could probably reach for a much simpler tool at least to start with.

learn all these things too, right. So it firstly starts simple, oh, well, just one obstruction, I can save these three linns. But suddenly, oh, oh, which obstruction did I use to abstract these three lines? I need to find it? And suddenly you're more concerned about finding the right function that you extracted formally than just to do the coding right. And so there's always this straight off and there's certainly no one site fits

some all solutions here, like with everything right. So this is one of the things that are always criticize many art because only say oh this is good or everything else is bad. Yeah, I mean there's always a reason why. For instance, why exists, even though why is now bad and excess the new thing to do, right, there was

a reason for that and we shouldn't forget that reason. 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 tradeoffs and what other things exist and 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 great and you need to find which shade of prey you fits to your particular problem. And I guess, yeah, we can discuss it in the REACT context, but I just said it's all in soft I mean, I guess also generations of what we knew that and we also learn

it again, at least I do. And it's always a little bit of this cycle that that goes around, and we just need to see right where we end up, is 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 really go forward, to reflect a bit and to find let's say, a better way forward, and to not forget why we picked that one. The why is quite often really crucial.

some of these JavaScript frameworks. And I almost feel like this is true in the bill 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, and now it's like cool to be like counter webpack and to be using all these hip, new, strangely named tools that are like different and smaller and faster, and it's like we can just as an industry, we can't make up our mind, Like as soon as we go too far in one direction, we come.

was totally good with it. It was just have a reason for why do you think to do it this way?

to the project, or to software development in general. Right, And so I always think that quite often we are not asking the why or answering the why good enough, at least I know that for myself. So I think this is always something where we can be also, yeah, full of critics of ourselves and always try to improve.

And yeah, I think 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 again, you're interacting with something where the system is completely hidden from you, so you don't see why things might end up in that state. Yeah, and microphonance, if we also good why questions? Why are you doing microphoneance?

This is something I can ask a lot these days because believe it or not, I don't know how you feel about microphonance if you heard a lot about it, or on what side of the pandulum you are. But this is again like the guys are saying, we just that Microsoft didn't work or was used for everything and shouldn't be used for everything, totally agreed. Then the other guys will say, oh, Microsoft was so great, now we

need to do microfondance. We don't know why because of front and is working great, but we want to do it. And so I mean also here I have the full spectrum, would really be eager to know what your opinions are on this one.

that up that would possibly be useful. But I'd love to hear more about how this came about and your experiences with it. And TJ, I don't know if you've ever worked with microfrinends.

order to let they have it's still all together. We have them in a MONORAPO, and we have one large build that could certainly justify let's say, or it could be counted as a micro front them. But then we still have maybe large or longer bill times. Let's say, we still have maybe conflicting full requests, and we still need to give everyone access to this. Plus of course,

yeah cd I already mentioned along build times. Now everyone of course shares the same build pipeline, which means this is always let's say the one bottle neck potentially, and so there are of course other ways. So one way is to say, okay, instead of having real micro services, we now have micro web servers so to speak, so servers that still are there, but instead of serving for instance, Jason,

they may still do, they now serve also HTML. And then we combine these things, for instance on a reverse proxy, so we have one 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 debuct this? You're responsible of one of these fragments, how do you get that? And who's responsible for let's say, maintaining that reverse proxy or this?

That's good, call it microfront and 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 lips, but instead of needing a build process with tooling like webpag or another bundler, you deploy them independently in form of still javascripts for instance, and now you combine them in the front and are There

are a couple of popular approaches. Usually what you do here is, of course you have in a single page eptic and sometimes people call it in a single page application of 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 ends 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 models, if you want the true isolation, only way to do it is an eye frame, 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 se great. My opinion is for a partier, but we still have from the scripting perspective a lot of potential conflicts. And then we can also do something like yeah, standard script injection with ESMs or UMD modules and hear things like single spar or the framework where eye contribute to which is called viral. They help you

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 CD pipeline right, which allows to ship new updates off their code or a new feature in really seconds to minutes depending how it is all set up, instead of waiting longer and maybe having more loaded processes sharing things. So this is what it is about, a little bit

like in the micro service department. Also here you often here hear one argument you can now use independent technology. So one team uses React, another users Anglar. Well, let's not go there, right. Personally, I would say you should try to have a set of core technologies because it's the front and if you combine it in the front and in the browser, right, you ship all that to

users browser. And if you suddenly run ten frameworks in this yeah, maybe on a mobile device, it will not be a great experience, right, So you should maybe try to limit it to one. Or maybe there's this other 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 micro services that the goal was also never to have a patchwork of technology. It was always to just you know,

allow using different technologies. That then the best thing, the best tool for the job. If you have their service that deals a lot with it, 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, should do something else, and you have a team that only knows I don't know, c sharp dot net, they 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. But yeah, it gives you a little bit more freedom. And this is what microphone is about, giving you this freeedom to actually, yeah, I have distributed developments possible and be a little both or flexible and agent as we are. But there are, of course, maybe that's a good transition. There of course counter arguments too, right, So complexity rises just that two and you need somehow to Yeah, I

have this orchestration there under control. You also need new processes because yeah, now teams can maybe deploy independently. Maybe you don't want that, maybe you want that. It always depends, and so you always of course also hear shift complexity, right, So you gain something, but then something else is maybe a little bit worse or challenging for no silver bubllets.

But I would still my gut would still be like, oh, well, of course i'd keep that apart 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. 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 off. So I guess, first of all, is my understanding of this correct, Is that use case sort of makes sense?

about interactivity. Second, they care a lot about performance, so that they really want to have something that can be pre cash and so on, and they just send it out to the end user that it's as fast as possible, right, so they followed this, one hundred million seconds of additional loading time means that less revenue, and so they always

try to optimize here. But nevertheless, there are of course also e commerce shops that are built using microfundant, using a microphonat approach, and for that, yeah, so what you would do usually, but there'll of course a lot of different approaches, but what I personally like as an approach is that you follow here a more domain chrythm approach. So what you would want to do is you identify first of all the grand theme of your applications. Well it's in the e commerce space, right, But then you

start identifying subdomains here, right. So one subdomain could be I don't know a recommendation model. So you're on a product detailt page. You want to see a list of recommendations related products I don't know, products that may only make sense for this particular user, and so there could be one team just working on let's say you I

fragment for that. This team may also want to bring in I don't know something now menu bar or in some menus here that that we offer, and we may have another team that only works on maybe the product details page. There may be a third team working just

on the product search. And product search is also interesting because while it may have a dedicated page right search resultants on, it also has of course maybe a search that's always visible and they own this spar right, so every input and so on that's owned by this one team, and 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 the main content of this 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 I identify in what's the main

does this fragment of your eye lie? And this is what microphons are about, that you cannot find the correct team that only let's say, ear is now the search the search bar and the search page, the search without page, and they will do everything with it, and then if there have an improvement for the page, they can ship it completely independently and they are just responsible for that.

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 head up, that should be a microphonet, there's a food, should be another microphone in, there's a navigation bars should be a third microphoneant, Yeah, you see that. It are 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 in navigation bar is always let's say, dragged and pulled by every other team. 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 created now Yeah.

I don't know if there's a word for it, maybe spaghetti modulet I don't know. Yes, we can, we can, we can invent something now here, but but it's really it will not be maintainable in my experience, and so I always advocate going for the identifying domains and putting those into let's say teams or microphondance, which are then responsible or in charge. Yeah, certain teams are in charge of them.

which is also fine. Right, So if you start with a monorepple, for instance, if you say, I don't know if they ever need this micro front and stuff, but it would be nice to architecturally maybe group it, my advice would always be, well, start with a monolith, but do it as a mono report, 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 and seedra capabilities on it, and

you then have your distributed microphone and solution. 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 it's 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 that pain point. People wouldn't be let's say, in 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 death doesn't sound like pain to me. But if they say, oh, my poor regress is hanging there for two weeks and we were supposed to shift that feature a month ago, but suddenly all the bills take so long,

and then there was this conflict here. In conflict there, well, it sounds like some things he needs to change somewhere. I'm not sure if microphone is is a solution here, right, but I'm sure that something needs to change, and maybe microphone isn't a good solution if you hear as pain points, especially things like it needs to go faster particular features. So this is really where microphones may hit the nailia.

But make no mistake, migration of existing applications I mean, if we have this case that it just describes monoapo all nicely grouped this, this is the beauty. This will work. But usually it's not as nice like this because the application is five years old. It started nice, but then duct taper duc Tapier there was a feature that never someone thought us, so we needed to work around for it. How can we now do that in this distecret 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 distributed? Because we've made it a smucketti before it. But certainly I think this is when you hear enough people complaining, it's a good point to think about it.

So it's an interesting way of bringing 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 products thing, and it's it just goes to show how like my mind does not work this way just because I haven't been

a I haven't really considered this. So now like I used 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.

that's what That's what I was doing. Right either way, I mean that you don't start with that right away. And still, of course getting the rights decomposition right on this domain that I described is also not easy, right, so you need, of course do main experts. You need to know people of course that really understands the requirements of your solution that you either want to build or that you have built and I want to let's say roll out as microphone then and yeah, you need of

course to then train the people. Ideally, of course, this is the experience I had in most projects. I mean, if the micro frontum setup was done well, developers of individual modules don't even let's say, know that they are doing micro fundams. I mean they're just developing. I mean you tell them you now do the shopping basket, okay, and then they develop ideally at least now this client

site perdigon like for a single page application. They even have the debugging experience the same as you know, as if you would debug the grand application right on. The difference is in their view, they only see let's say, naked application. Maybe I don't know how to food are in there, some design elements and they're they're 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've used in but you can decide it in

the setup for instance. And so they don't even know. They're just developed there and they don't need to know the particularities of this kind of style. And I think this is a good way, because we're 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 happening below, I mean certainly would be great and in certain edge case conditions it would help you.

No questions are But in the ninety ninety five percent case, right, I mean if the platform with the run time or it takes away all that for you, and all you need to do is focus on your problem and how you solve that. No technological questions asked, No, oh oh ah, I need to wire up this with that. No, you

just focus on your domain specific problem. This is where I 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're paying you to debuct react. No, we're paying you to bring the shopping cards to life, for instance. And I think this is working in your problem. I think this is what makes some frameworks productive and great, and others well technological interesting, but otherwise maybe not the productive.

Class of course, a lot more patterns, so there's a lot of also here a lot of shades of prey, right, so I think it has seven patterns and all of these very practically introduced. But most of the or let's say, the other half of the book really deals that with

how do I choose the right to maintain composition? How do I now work with designers for instance, because they will still design a monolith and you need to teach them what are you doing technically that they will well give you the best experience because at the end of the day you will design, you will create something that is in its mature flexible. So for instance, the navigation bar, it's not cut in stone. Someone can just write a new feature and they have a new item. How does

it behave in under these conditions? Right, So suddenly designers need to go beyond the static screen design and really think about these things, but also about organizational changes, because yeah, if you really distribute the 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, I now want to know what what is beyond the horizon if we go that way. Yeah, and certainly is one of the things I covered.

well look at that. Just also you can give me, let's say, a message on Twitter for instance, because I still have I think fifteen or twenty five percent of the ebook, and there may be a chance. I still have I think some physical copies, so hard copies of this that's like the one I old man that I could get you for free actually if you message me. But these are limited. Actually I think I have five or six left there. But anyway, if you're interested, always

just taking me. I'm very open, of course, and sorry, I want to sell the book more. It's the best together. It even discusses west development in general in the introduction. You should read it. If you don't know what cgi SSI and so on, it's in there. If we talked about tooling web peg parcel, it's all disgusting here. Why that's to new? That's not in this book at I think. But I even have ees building here, so you can't say, I'm yeah, there's still pretty new stuff in here. Could

be on the computing stuff. But anyway, any kind of criticism also to me, right, So if there is something you like to improved, I don't know if there will ever be a second edition, but just tell me. 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 my performance in there, even though as always right, you finish the book when you're like, hmm,

this is one cool thing. I didn't mention it, but then I just make a blog post about it and then.

have their public guitar chatroom. I'm very active there. You will see me chatting around giving answers to Pyrol in particular or microphones in general. And I think we have a great community in our channel. We have I don't know, one hundred and sixty one hundred and seventy people, not all of course active all day, but there's always one good answer for every question. And I will paste it in the chatroom. But that's either I guess that's the best way to reach me. Otherwise, of course email can

give you this and otherwise on my personal website. They're also all the I mean, I'm also in Skype and so on. All the messengers rights in a Richmond which one. Yeah, it's like it this comic about all the stand ups, right, So there are certain stand ups we need to imprace them all. We need a new one. It's the same thing, so we need a messenger to have all the messengers.

it's actually made by Microsoft. But if you've listened to the show with any regularity, you'll know that I started 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 make things called note cards that connect to Raspberry pies or are we knows, 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 I'm starting with some of the really basic online things that are available to kind of learn how to use raspberry pies and get into that sort of space. 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 a foray into it. So, Florian, do you have anything that you'd like to pick?

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 heard about GIT here leave 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 commit is always in a part of your application with a certain file, let's say that usually doesn't carry any feature, but you know it's just

for instance, some orchestration lays. Then you know architecturally something isn't dry 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 our 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 refectory mood or really something is not really done right. 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 reflector for the refectory sake, but we

should reflect them and make things more productive. But for that's the first to recognize what's all making us not so abductive. This book is I think, at least for me it was and still is when I haven't opened it a great guide. Today I will post an Amazon link for it.