Jack_Herrington:
Welcome to React Roundup, I'm your host for the day, Jack Harrington, and with me is TJ Ventole.
Tj_Vantoll:
Hey everybody.
Jack_Herrington:
And Paige Neateringhouse.
Paige_Niedringhaus:
Hello.
Jack_Herrington:
who just locked up on her video feed. Sorry about that. And our guest for today is Florian or Flo going to the Flo. How you doing Flo?
Florian_Rappl:
Thanks, I'm doing fine.
Jack_Herrington:
So what brings you on? Oh, yeah, actually, you know what? Let's just do it all again since pages need to be back. Okay. Sorry about that. One more time. Just, just for chits and grins. Okay. Cause this podcast is going so great today. Welcome to react roundup. I'm your host, Jack Harrington. And with me today is Paige Neateringhouse.
Paige_Niedringhaus:
Hey everyone.
Jack_Herrington:
And TJ Ventole.
Tj_Vantoll:
Hey everybody.
Jack_Herrington:
And our guest for today is Florian or Flow. We're going with the Flow. Hi Florian.
Florian_Rappl:
Hi.
Jack_Herrington:
So Florian, what makes you famous and what brings you on React Roundup?
Florian_Rappl:
I wouldn't say I'm famous today,
Jack_Herrington:
Nobody
Florian_Rappl:
I
Jack_Herrington:
ever
Florian_Rappl:
think
Jack_Herrington:
does.
Florian_Rappl:
I'm here to talk about Pyro, a framework for micro-front lens.
Jack_Herrington:
Oh wow, that's awesome. I'm really excited about that. So why can you give us a little bit of intro, assuming that let's say I don't know micro front ends or we don't know your friends. What is a micro front end and why shouldn't we use your micro front end framework?
Florian_Rappl:
Yeah, so MicroForens is all about scalability, that you give actually multiple teams the option to just develop parts of one application. and empower these teams, of course. So getting a little bit of similar benefits that you do get with microservices on the backend, if that says anything to you. And yeah, the challenge of course, with micro frontends is how do you make the UI consistent? How do you actually bring together those pieces? And this is actually a pirate comes into play. So it's figured that all out from the development aspect up to this composition layer, and it brings together things that, well, other approaches have, of course, also solved, but of course, only. soft for instance for a part of it and so this is the whole story.
Jack_Herrington:
Okay, so we think about a traditional web page, right? And we think about like there's the header and maybe, you know, some content section. And maybe if you're an e-commerce site, there's the area where you might add something to the cart. What part? And maybe a carousel showing like different products or whatever. What part of that page would be would you think would be a good micro for an end?
Florian_Rappl:
Of course, as mentioned, it's all about this team split. So what you would do if you take that example of your e-commerce application is that you would identify different subdomains of your site, right? And what has been proven successful, but it doesn't mean that it's the right approach now for your particular e-commerce site, right? Is that you, for instance, put everything related to the checkout into one team's responsibility and everything regarding products of another team and then you could have for instance a team that only cares about user accounts and maybe a fourth team that only cares about showing the right recommendations for this user etc etc. So and if there are new features coming up maybe it makes sense to scatter that feature into different teams maybe in one of the existing teams maybe do to create a new team about that feature and that's of course now architecture talk and going into
Jack_Herrington:
I love
Florian_Rappl:
now
Jack_Herrington:
it.
Florian_Rappl:
a specific application but yeah. gives you this ability to scatter that around and really have teams that take care of one of these subdomains and they are really the domain experts which is the difference to monoliths right where everyone of course needs to have a head on in all the aspects at least to some degree and that can be rather overwhelming of course at least in the big applications that I know of.
Tj_Vantoll:
So maybe you can help me paint a picture. Let's suppose that we have a team that's devoted to like related products, we'll just say, right? That's an e-commerce site. All they do is they try to, they write the algorithm for related products. That's their thing. So how would exactly a micro front end work like in terms of like the high level code, right? Cause I have my product page within my like react app or whatever. and I need to bring in this micro front end that's just for related products. Like what would the sort of structure of that actually look like?
Florian_Rappl:
Yeah, depending on the approach. So I of course will, will take the approach of PyREL. What you would do is think about what you would do in React when you create, let's say, a component library. Now component library only takes care about, let's say components that are rather generic, for instance, think about a button or maybe a generic panel, right? It doesn't know any, any data where it comes from and only knows, okay, there will be, for instance, in the button, there may, it will be maybe a label and someone will, will potentially attach an event. handler on clicking on this. But it doesn't know anything about the domain. Now the microphone operates on a different level. You would still write just a component in there and for instance you would write a component like a carousel. It just shows you a kind of a product and maybe it has a kind of a header on top of the carousel and it says customers who looked at the current product also were interested in and then maybe in the carousel all the other products are already deals with the data so it needs to know where to get the data from for instance the backend it knows of course the shape of the data and it of course then displays that data so it already merged the data part together with a component that was domain independent and it will show you now a domain dependent component so it really has all the domain knowledge in there and it it just is this component. Now, of course, someone needs to, let's say, integrate this component that that team wrote. And in Pyro, the approach is rather simple. You create so-called extension slots. So there's points on the page or on some content that is owned by any team. But it can say, oh, here, by the way, some other team can place something in there. And if that slot name is matched by now the component offered by, for instance, this recommendation team, then suddenly in this slot, the recommendations are showing up. no team is interested in bringing anything on that slot nothing will show up right and that's this decoupled approach that Pyro makes for instance unique other things you will always import explicitly which is of course for tutorials very nice but in practice will always break break because what you have there is a feature overlap And this is something you want to avoid also in microservice architectures, right? There's a good LACNOS test. If you can turn off some parts of your system and the system in general works and doesn't, you know, just throw exceptions everywhere and goes down, then it's a well-architectured system. And that's what Pyral always tries to aspire. So it loosely couples everything that you can just go ahead and release, turn on, turn off, and the whole application will always keep on working. Right, so this team can independently therefore release, they can update, they can change contracts and yeah, in the worst case that will happen is that their recommendations don't show up anymore but the applications will never go down by the changes that this team is doing.
Paige_Niedringhaus:
So that actually is a great intro, I think, into asking you to tell us more about Pyro because it's not a framework or a library that I'm familiar with. So I'd really like to hear more about how it, it sounds like it takes a lot of the issues or some of the complexity of maintaining a lot of micro front ends and makes it a lot easier.
Florian_Rappl:
Yeah, so Pyro was born out of, let's say, repetitive work that I did in architecture consulting.
Tj_Vantoll:
Hmph.
Florian_Rappl:
I think the first project I had in this space was around, let's say 2015-ish. We did their smart platform for a smart home product. And there the issue was exactly that we had different teams, they were all dealing with different devices. And they wanted, of course, their device to show up in the UI, right? And maybe tomorrow a new team is onboarding and they also deal with a new device. And you want to show, of course, in, for instance, a settings page or on the dashboard specialized controls for this device. As an example, right, a Philips Hue is a different kind of switch than you would expect from a standard light switch because it may have colors, for instance. And you want to have that too when you deal with that device on your dashboard. And so what we did there is that we created a kind of plugin architecture. Back then, of course, no one was talking about micro frontends. That just was then occurring to see or the terminology was born around 2016-17-ish. But it was exactly that. So different teams are creating these kinds of plugins, which were just libraries that were dynamically loaded. And over the next two, three years for different clients, Yeah, I would say rather a similar architecture. It wasn't clear from the beginning that the architecture will be the same, right? Because of course, clients come up with requirements and just say, nice, yeah,
Paige_Niedringhaus:
Hahaha
Florian_Rappl:
OK, noted. Let's see what we can do here. And then you start thinking about it. And in the end, you look at the sketched architecture and you say, wait a minute, there are some similarities to the project that beforehand, right? So what can I borrow here? And
Paige_Niedringhaus:
Mm-hmm.
Florian_Rappl:
the story, of course, evolved a bit. of the architecture, refined of course with every iteration. And in 2019, I joined a new company and there we thought, what should we do? And I said, micro-frontends
Jack_Herrington:
Hehehehehehe
Florian_Rappl:
is a good thing to go. And what I want to do is actually this architecture that I now implemented four times and each time a little bit better, try to make it generic, the more people can of course use it, make it open source that really a community benefits and have the full story figured out So I have the full ecosystem, things that if you would just do a single implementation, no one would of course invest in a browser extension or a VS Code extension or all these things which make a framework really. you know, live and quite awesome to use, no one would
Paige_Niedringhaus:
Mm-hmm.
Florian_Rappl:
invest in that. Of course, developer experience should always be high, but if you do an open source implementation and then really care about this thing, then you can make something that from the ecosystem perspective is really complete. And that is what we, what we tried with Pyro. And I think we are, of course, we are not the largest solution because MicroFrontends itself is, you know, rather specialized and we aim really have a lot of micro-frontends. So the largest customer we have, so knowing customer, right, not open source user, but really we are doing as a consultant. Consulting here is having around 140 micro-frontends here. So
Jack_Herrington:
Woo!
Florian_Rappl:
that's a really large
Paige_Niedringhaus:
Wow.
Florian_Rappl:
number, right? Of course not every user gets to 140. I think on average it's about 30 to 40-ish what a standard user gets, but they have this large number and so they support all the use cases. And if I would tell you about their solution, I mean, it's a portal. That's a little bit where the name also comes from. Pyro is a little bit like portal, right?
Paige_Niedringhaus:
Mm-hmm.
Florian_Rappl:
And it's a customer portal and they have different business segments. And depending on what kind of user you are, you are in a different, yeah, associated with a different segment of the offerings, right? And so of course you get different micro-frontends because someone was interested in their, I don't know, microscopy segment will get different things than if you would be interested in semiconductors. And some things may be the same. I don't know, like the feedback micro frontend where you can give feedback to the portal itself, that
Jack_Herrington:
Yeah.
Florian_Rappl:
will always be the same, right? But there are really a lot of things that will be just tailored for the end user. And that is again, one of the great use cases in my opinion, because really that's just composed on the fly. No one is saying, oh, there's an if now. And if it's that user, we now need to load this code. No, it's not like that. Each microphone has a feature flag. you are, different microphones are provisioned for you and that's a very dynamic system and it wouldn't scale of course if it wouldn't be loosely coupled, right? So that's a little bit the background story and where we are today. So I mean today I think at least in microphone and segment we are known to some degree but definitely not the most popular solution but I think a solid one.
Jack_Herrington:
So who would be some
Tj_Vantoll:
See
Jack_Herrington:
competitors
Tj_Vantoll:
you.
Jack_Herrington:
in this space? Would Single Spa be a competitor with you guys?
Florian_Rappl:
Yeah, I mean, let's say for a mindshare, definitely. They are of course always, let's say a factor 10 larger. Which is fine for us. Of course, he would also wouldn't mind getting getting some of that fraction here. But at the end of the day, I mean, they're also doing a great job. They are just for everyone who doesn't know what SingleSpice is. It's a little library that could be considered a meta router. So they take care of having your routes managed and depending on your routes, you load different micro front ends there. And the big advantage of SingleSpice or let's say what they in first was that you can happily use different frameworks which of course is one of the often announced advantages of micro frontends. I always say a good micro frontend framework needs to do that but it shouldn't fully embrace that because at the end of the day, you may want to do that. But if all you want to say, oh, we have such a great application because we use the most front end frameworks in it, that may not be the selling point of it. Right. Every additional framework makes your things, let's say slower, at least from bandwidth consumption also, but also memory consumption in the browser. And at the end of the day, developer experience may also not be the best Yes, it's great that this one other team you have is now experimenting with this frontend framework that came out yesterday, but someone needs to maintain that code, right? And it's, if the team goes away and no one knows what to do with that code, yes, you can argue micro frontends is great because you can just throw it away and start the new thing here because
Paige_Niedringhaus:
Ha ha
Florian_Rappl:
they're
Paige_Niedringhaus:
ha!
Florian_Rappl:
just so small. But on the other hand, it's also not much fun, right? Just to do things because you lack knowledge in, for instance, the framework that was used.
Jack_Herrington:
Yeah, I think that the practical aspect here is that, like, let's say you have an Angular app and you want to start moving over to React. This would allow you to like something like single spot would allow you to port pieces
Florian_Rappl:
Yes.
Jack_Herrington:
of the page, as opposed to, say, port an entire page across, which
Florian_Rappl:
Yes.
Jack_Herrington:
is pretty pretty standard. So, I mean, yeah, you're right. You don't want to use. You know, random framework X just because it's there, you know, you are going to be downloading an entire like view runtime onto the page
Florian_Rappl:
Yes,
Jack_Herrington:
in
Florian_Rappl:
yes.
Jack_Herrington:
addition to react or whatever. And that's not great. So, yeah, I mean, obviously use of care as with all this stuff, you know.
Tj_Vantoll:
Yeah, that was going to be one of my questions because in the past, uh, the term portal with me has not had a positive connotation. I would
Jack_Herrington:
Ha
Tj_Vantoll:
say
Jack_Herrington:
ha.
Tj_Vantoll:
to say the least, like when you
Paige_Niedringhaus:
Yeah.
Tj_Vantoll:
think those big, like enterprisey portals were a bunch of things that they're pretty usually awful experiences. And I think like the main reason they are is because they're just loading in a ton of crap because they're bringing in all sorts of stuff from all sorts of different systems and they don't share anything. So they're just completely almost loading like full web pages and little boxes. So this leads into my question is, what do you try to do to avoid that? Like is there, can your micro front-end like share dependencies? Because like I wouldn't want my little micro front-ends each to individually load their own version of React, right? Like because that seems very wasteful. So I'm curious
Paige_Niedringhaus:
useless
Tj_Vantoll:
what's your, yeah, like what is your
Florian_Rappl:
Yeah.
Tj_Vantoll:
approach for dealing with with that sort of scenario?
Florian_Rappl:
Yes, so sure, one of the things that... Front-end framework needs to do is share dependencies. Of course, there was always a huge debate Right, especially for people coming from the back end where they have really this share nothing attitude You share now dependencies but on the front end you need to do it because as I said, I mean it's it's different than on the Back end. It's not like different things now running on on different machines And you can just scale up if you say oh this one service is now slow for some reason Oh, just give it more memory there
Tj_Vantoll:
Hehehe.
Florian_Rappl:
and maybe someone renders your page in a Raspberry Pi or whatnot, right? And
Jack_Herrington:
Hehehehehehe
Florian_Rappl:
it just needs to work. So you really want to deliver the smallest bundle size possible despite micro-frontends. And yes, Pyro also does that. And of course, there are various mechanisms. Out of the box, Pyro uses, for instance, System.js and makes that... rather easy because in SystemJS you can just share things and you can even share them with Semver ranges and all of that which is quite great. So you can say oh keep react if it satisfies I don't know 17.x and so we were just looking that up and so things that you would otherwise do and that's the other mechanism you can use module federation for instance. The problem with module federation is which is why we don't let's say enforce it to the users, it's gets you into the Webpack ecosystem. And you need to do that, not only then on your application shell, your main application, but also with each microphone and drive. So in order to really leverage that, you need to have Webpack 5, which is one of the options you can use with Pyro. You can use any bundle. Right now, out of the box, we support ES build, Webpack, any version, right? 4 and 5, we have official ports, Parcel version 1, version 2, Vite, Rollup, you name it, right? They all just work. And they work with dependency sharing, all of that. which is quite great because you get then the least bundle size and you can do all those those tricks you can do with with module federation. On the other hand of course what I also want to throw in just also because I gave a talk on that dependency management is of course one one side the tooling that enables that like let's let's take module federation which is great but on the other hand you still need to understand the libraries that you want to share because there are some libraries that you know You may not even need to or want to share them for whatever reason. They are really good tree shakeable, etc. And... They don't have any global, so just use these fragments that they come with. That's all good. And then there are maybe libraries which have global objects somewhere, and they would conflict if you would just load them in twice. So that wouldn't be good. Style components may be a good example, because they hash the style sheets and they use a global for that. That may have changed in one of the recent versions, but at least a year ago, it was still an issue. So you needed to share style components. It wouldn't have worked if you would have you know, two micro frontends, and they bring their own version of sty components. That would have conflicted. And another good example is React. React doesn't have a global, but it has what I call a singleton. And that's a dispatcher. The problem is, you see that already if you have even non-microfront end solution, but you bundle for whatever reason React in there twice. And there you see it doesn't work in the same render tree. And the thing is that it needs to know for the hooks to work, the dispatcher, that's set by React DOM. And if you have two versions of React in there, only one version gets set. And so when components that are bundled rendered, this patcher is still undefined and the thing crashes. And so you would always need to respawn a new render tree that is consistent there. But then again we are back at knowing the internals of these libraries at least to some degree and understanding that. So there are some decision making aspects here like what's the size of the library etc etc that will end up with you deciding is it worth sharing the library or not. But in
Jack_Herrington:
Alright,
Paige_Niedringhaus:
So...
Jack_Herrington:
so let's say that I've got... Oops, sorry. Go ahead.
Paige_Niedringhaus:
Well... I just have a question of how easy or difficult is it to, to make something into a micro fronted architecture that uses Pyro? Because you've talked a lot about how when you start out gathering client requirements and putting together an architecture, you know, it, it seems like a pretty good idea. But if you're building one of those applications that just kind of starts mushrooming as many of them do. you know, is there a certain point where you realize, hey, we really should not continue to build this monolithic application, but we should split it into micro front ends? And is that something that can be done? Or is it really like, oh, we need to just rebuild this from the ground up with that idea in mind?
Florian_Rappl:
Yeah. So I mean, if, let's say, really starting at zero and making the decision microphone it or not. I mean, it all depends, of course, on the envision size of that application. If you say we are making, let's say, a simple landing page for something and, you know, we work a week on it and maybe we'll then update maybe a little bit of the styling or add a little bit of content here or there. Micro-front-end architectures, of course, like
Paige_Niedringhaus:
Overkill.
Florian_Rappl:
shooting with a bazooka on a tiny bug, it's really out of the question. But of course then, let's say we take, going back to that e-commerce side, make sense here, right? E-commerce of course are always a very good example to also show the domain decomposition and then how you could assign different teams. But at the end of the day, of course, it's the same story. I mean, for instance, if you're taken out of the box e-commerce solution and you now as the vendor, you only care about selling t-shirts, then yeah. Maybe you don't even have a development team or just the smallest team to set up that site, then of course microphones are not for you. But of course, if you're now one of these vendors who... You know, in Germany we have, for instance, Zalando, if you heard of them, they're also one of the pioneers in that space. They made a server-side composition solution quite early on called Mosaic. And they really care about their tech. And so they're really tech driven. And what they have is they have different teams already. So they are already prepared from the organization point of view to work in that mode. Then of course, it makes a lot of sense for them to start already with MicroFundance because they already empowered all these teams. Why now move it back to one monolith? On the other hand, of course, if you at the moment have an organizational structure that only supports a monolith, it will be very hard to move to to do both, right? On the technical side, move to micro frontends, but on the other side, I mean, empower these teams. Because at the end of the day, the worst thing you can create with, I mean, that's not specific to micro frontends, the same for microservice, is a hidden monolith, where, well, you have now technically all these things floating around, but they require so much alignment and so much overhead in the organizational point of view. It's not worth it. So don't go there. Make sure first that you really can have these independent pieces and I mean with Pyro of course what you can do and what I usually recommend when people say yeah we identified that we may be ready and I say okay good. Don't put too much in microfrontends from the beginning. Yes I said that example was the 140 microfrontends but if you don't know yet if there's a certain signal in your application, don't know yet that it should be in this one team or so or you know that it changes often. Just leave it in the application shell, leave it in that same underneath that still wires together these different pieces. You can later on still put it in a micro frontend. One example I mean I mentioned that this for instance the feedback micro frontend in the larger portal solution that was in the beginning in this monolith monolithic layer right and it was good there it stayed the same for I don't know half a year almost a year and then suddenly they came up with requirements for that they said oh Wait a minute, we now want to have different layout here and a different question if the users gave before a dead answer. I was like, okay, great. Maybe that's a good point now to move it out because I have a feeling now that you started with requirements so that there will be more incoming. And so we put it in a, in a, in a micro front end. And that was good because a week later after the deployment, they came up again with some requirements. And suddenly
Paige_Niedringhaus:
I'm going to go
Florian_Rappl:
from
Paige_Niedringhaus:
to bed.
Florian_Rappl:
that on, right. Each month you can count the clock. It's there. They make new requirements. And so
Paige_Niedringhaus:
Mm-hmm.
Florian_Rappl:
this thing moves now it's its own pace and that's good. They can just update it independently. It doesn't require a full application. or anything, right? I mean, it's just the application shell, but still. And so it was moved out, but they didn't start right away with that. And that's the crucial point, right? Don't start already with all the complexity and start already with a list of, I don't know, we identified these 200 microfrondens that make sense,
Paige_Niedringhaus:
Mm-hmm.
Florian_Rappl:
but really just first see, does it make sense? Is there a team already or should we first start with it in this application shell layer? And then when we get some advantage, because, you know, it's moving at its own pace, there are more updates here incoming, maybe then move it out, right? And it makes sense. And that's great that you can move here or cut it as you want it according to your needs.
Jack_Herrington:
So,
Tj_Vantoll:
See you then.
Jack_Herrington:
okay, is there a nice half step here with this? I mean, we talked about this before we got on the air about the islands architecture. How does that relate to this?
Florian_Rappl:
Yeah, I mean there's island architecture, the thing that now becomes more and more popular with I would say this new hype of frameworks. I mean, I know 10 years ago people were always joking about, oh, while the talk is happening, a new JavaScript framework was born. But frankly then... the last two or three years not so much happened. Yes, of course, some frameworks came up, but also things that we consider maybe hot these days, like Sveld for instance, I love Sveld, it's great, or Solid Jazz, they have also been born already four or five years ago, they just now get some traction. But now in the last, I think, since Remix was there, we've seen this growth of frameworks again, partially of course as, I wouldn't call it PR stunts, but of course... nicely together like Dino is there for a while now and didn't get so much traction I think as they hoped. It's I think maybe too radical move but anyway it's cool technology but it of
Jack_Herrington:
It
Florian_Rappl:
course
Jack_Herrington:
is.
Florian_Rappl:
has the burden of. starting without an ecosystem, right? Against something with ecosystem. Always difficult. Anyway, they now try to get it from the other side, right? And they came up with Fresh. But maybe that Fresh is now burned through BUN, because now there's a different runtime at the end that's compatible to Node.js. Anyway, so there's now all these, let's say, new movement of frameworks. And I love that because... I mean at the end of the day it really doesn't matter which one is, let's say, the winner or is there a winner, but There are new ideas in here and new approaches. I think in the end, everyone will win through that, right? So we will all advance with a little bit more knowledge. And one of the things these new frameworks, of course, try to do is, yeah, make it as fast as possible. So performance is what they always claim is their key part. And to do that, of course, it needs to be somewhat pre-rendered, server-side rendered, you name it. So don't ship too much JavaScript to the browser. And to really make still interactivity work, you still want this hydration mode, right? Where you say, oh, I delivered pretty much everything pre-rendered, but now this one button that I don't know just counts something that now suddenly works also in the client, right? And the problem with React is pretty much all established frameworks, they usually require the full information to be resumed again or to hydrate. So in React you may have created, I don't know, a state container that you use and you may touch other things, you have maybe style components and now you render now different... Yeah, or the same component, but with a different style. But in order to know all that, you need to have all the code now in the browser again. So if you want to hydrate, you pretty much hydrate the full thing again. That's one of the issues, of course, that Next.js always faces, and they also try always to come up with something cool and new. And this is where the, where this island architecture is often the new. So what they are after is that you only need to hydrate now certain island in your inner site, an island of interactivity, let's say, the minimalistic JavaScript to make this little island work. If the little island didn't require, for instance, your state container, or didn't need to know about sti components, why should all these things be loaded for this little island to be active? One of the cool frameworks that brought up this concept of resumability is QUIC. One of the frameworks from Builder.io, so they came up with a lot of cool JavaScript, a lot for instance, Party Town, anyone was listening, didn't check it out, check it
Paige_Niedringhaus:
Thank
Florian_Rappl:
out
Paige_Niedringhaus:
you.
Florian_Rappl:
because it's a cool solution for, let's say, isolate third party scripts. In any case, so what QUIC is about is really having your state always serializable and making it therefore fully resumable, pausable, and really just transport in the... little fragments that really are needed for your interactivity part, right? So it really embraces island architecture and other of course, frameworks also try similar things. For instance, we have Astro, a static site generator that tries to play happily with other frameworks and they also then say, well, in this, I have some kind of an island, but yeah, if the island is React, it still transports the whole React part in there, right? So it's not full island. I don't think at this point, full island, meaning a cross kind of framework is really figured out. But all these frameworks that try to come up with some kind of island architecture and fresh and quick at the moment I think to really great choices in that regard. So it's always about this island of interactivity and Yeah, part of it certainly goes a little bit in the direction of microfronance because there you could also say, oh, yeah, if I let's say, I compose my website. Now I have, of course, these components coming from different parts, right from different teams from this different microfronance. Are they the same then are these also islands and I would say in some regard, yes, but in another regard, no, right, because the microfronancing is really about the domains, whereas the island architecture is about this interactivity. But yeah, they can, of course, And that's I think maybe the sweet spot here, right? If you hit that, you have what I would call maximum performance and maximum scalability. But achieving that of course is at least at this point difficult with what we have.
Tj_Vantoll:
So I have a question about workflow. And when you have, like, let's suppose we're in one of these companies that has 30, 40 micro front ends deployed. Are the micro front ends able to update themselves like automatically outside of the main app? Like if I work on the carousel team, can I? Is it common to let people push that carousel to production without the main app or is the main app always in control? Is the main app saying, okay, there's a new version of the carousel, so let me update to the new version and push it live. And what workflow do people use? What workflow makes sense? I'm kind of curious what you've seen works for that sort of thing.
Florian_Rappl:
Yeah, I mean, the most successful workflow is definitely just, you know, empower the teams, let them publish. But, uh, I mean, we have, for instance, some solutions in the healthcare space. And, uh. If these industries are one thing, they are rather conservative. So even though
Tj_Vantoll:
Yeah.
Florian_Rappl:
they said, right, that makes sense to have this architecture and we believe in that and we want to have these different pieces because we ship into this region and the following, let's say functionality needs to be available and they are created by these teams and we ship into a different region and it's a different set of functionalities maybe created by different teams. They still want to control, of course, what is shipped exactly. So they don't just say to a team, it will be fine, right? It will go through regulatory, not an issue here. They will always say, are the documents ready? Have quality management signed off on this? Where I need to
Tj_Vantoll:
Yeah.
Florian_Rappl:
see that? So, of course, to, I don't know, a development environment, that's all not a problem. But once it comes into production environments, especially in those industries that are regulated, it becomes, of course, process driven again, which is not something I like. And my personal opinion is I think, I'm not saying they're wrong with regulatory, so there are these regulations and they need to follow it. I'm just saying they sometimes if it's on the boundary, is this a thing that needs to be, you know, fall into regulatory aspects and they're not sure about it, they always say, okay, it's regulated, so we need to have processes on this. And if you then argue, well, but that's the front end part, right? It's not the crucial thing. The crucial thing is where the data is handled and everything that that's correctly handled. there's no discussion for these guys. But that's a personal opinion. Again, the most, let's say, powerful aspect is when teams can just go ahead. And this is, for instance, again, referencing that one with a lot of micro-frontends. That wouldn't work, of course, if there would be someone there cherry picking all the application and determining what's there for micro-frontends. That only works really if a micro-frontend can be graded just by a team that now says, oh, we need a frontend for it and they just create it. There's no interaction needed with the full application. They can just push it and then it's online, right? So, and for that, of course, the organization needs to trust their teams that they can just create new things and can publish it and that they are empowered. But again, that's, I think, one of the aspects that comes with going micro anything because, yeah, I mean, if you don't just get more complexity with that. So
Tj_Vantoll:
Yeah.
Florian_Rappl:
you need to empower
Jack_Herrington:
Yep.
Florian_Rappl:
them. And at this point, it's really, yeah. I think maybe you could say, if you go micro something, then you stop micromanaging because at this point,
Jack_Herrington:
Hahaha
Florian_Rappl:
really the team should
Tj_Vantoll:
I'm going
Florian_Rappl:
manage
Tj_Vantoll:
to go to
Florian_Rappl:
themselves,
Tj_Vantoll:
bed.
Florian_Rappl:
right? So you do microservice that you don't need to do micromanagement. And it's the same, of course, with the Microfrog. And so
Paige_Niedringhaus:
It's a great
Florian_Rappl:
it's,
Paige_Niedringhaus:
tagline.
Florian_Rappl:
yeah.
Jack_Herrington:
Yeah.
Tj_Vantoll:
And honestly, it sounds like a decision, like it probably could help you decide too, because all of us here on this call have worked at companies like the one you're describing. And like I could see being very hesitant to adopt this sort of approach. So. It's probably something that if you're considering this for like a large organization, something to keep in mind whether you can actually fully take advantage of the architecture or not.
Florian_Rappl:
Yeah, sometimes it's a little bit hard to know from the beginning. I mean, some of the projects we are in, they always, they started promising, right? They come to us and say, oh, we evaluated different approaches, different frameworks, different
Tj_Vantoll:
Yeah.
Florian_Rappl:
architectures, and we think Pyro might be the best fit so that they tell us what they want to do. we have this problem and then we look at it and say oh yeah I mean it really fits then you're in this project and you start well it's all seems to be working and then at some point in time you hear from someone you've never heard of beforehand oh but by the way this thing also needs to be covered and say okay it's not ideal but let's do it But then at some point, right, you realize, well, I mean, there are now more and more of these requirements coming in. And yeah, up to the point, I mean, not in all projects, but some really end up like that where you say, okay, I mean, now it's really getting crazy, right? If you would have known all that from the start, just state your monolith, but because now you're just making things complex for no reason, right? And
Jack_Herrington:
Yeah.
Florian_Rappl:
you bring in again, all these processes that require all this alignment. not the deal, right? Sometimes they hear but many times it's just no, no, but we wanted that. Yeah, it's difficult, right? It's an organizational problem and this is where, let's say, their dream of going micro-something then clashes with really some
Tj_Vantoll:
Yep.
Florian_Rappl:
middle class or more top managers suddenly realizing that, oh, we're losing control here of this thing. And
Tj_Vantoll:
Hehehe
Florian_Rappl:
that's, of course, something that... maybe distinguishes really great companies from companies that are maybe doing all right still, maybe because of the industry, maybe for I don't know whatever reason, but yeah hopefully they also will change at some point in time or they will be let's say beaten by the companies that that learned that lesson right. I know a lot of especially in Germany we have a lot of these companies especially car industry right. I mean they are successful just what they are doing and And that's why they believe what they're doing is right. And even though they recognize, for instance, there's a problem, they will just change the last second. Really, when it hits the fan, right? Then they will say, oh, now we need to do something. Let's just create some new subcompany with new minds and they will just figure out all our problems. And then when they figure it out, we bring them back into our organizational structure. That's what they usually do. And unfortunately they are still successful with that. I mean, or fortunately, you can say of course, happy that all the people keep their jobs there, but they could do so much better, right? If they would just let go, because they have usually really good people working there, which always surprises me. But it's not the people, the people are not the problem there. It's really an organizational issue. It's a management issue at the end.
Jack_Herrington:
Yeah, you have to be completely bought into at every, not just the engineers, but also product managers and engineering managers. Everybody has to be bought in to MicroFrontEnds
Florian_Rappl:
Yes.
Jack_Herrington:
and you have to because there is a price, right? And you have to be able to realize that price, right? If you have a MicroFrontEnds architecture and they don't use it. you know, or whatever you use. Yeah, it's just not great. So
Paige_Niedringhaus:
Yeah.
Jack_Herrington:
is there anything that we've missed in our conversation here before we wrap up and go to our pick segment?
Florian_Rappl:
Not from my side.
Jack_Herrington:
Not from your
Florian_Rappl:
If
Jack_Herrington:
side,
Florian_Rappl:
you
Jack_Herrington:
huh?
Florian_Rappl:
have more questions, of course.
Tj_Vantoll:
I would be curious if people want to get started, what's the best place?
Jack_Herrington:
Oh yeah.
Tj_Vantoll:
Where should we
Paige_Niedringhaus:
That's
Tj_Vantoll:
send
Paige_Niedringhaus:
a great
Tj_Vantoll:
them?
Paige_Niedringhaus:
one.
Tj_Vantoll:
Are there any tutorials you'd recommend? People that are interested, what should they do? Where should they go?
Florian_Rappl:
Yeah. Yeah, our page is pyrel.io. Pyrel is written like pi, the natural number. R-A-L, pyrel.io. There you find documentation page that has a huge list of tutorials, right? Guiding you from creating your first app shell, creating microfrontends, updating these things. And there's the concepts that are involved in there which make pyrel unique. Like for instance, the emulator, which is I think a quite cool approach You just develop micro-frontends without having to, you know, somewhat taking care of to, hey, I need that app shell, I need to run that micro-frontend now in some context. It just makes all that for you. It's a one-stop happy solution and it guides you through all of these things. And I think that would be the best place to go. Also, of course, there we have a lot of reference materials, some articles out there, et cetera. And... I think that's the one stop that you should use if you're interested in at least checking out Pyral. All these tutorials by the way are also available on YouTube. So
Tj_Vantoll:
Cool.
Florian_Rappl:
each page as a video has the same content. If you prefer video instead of reading and want to see it instead of digesting yourself, that's a fine approach and you can just follow it there too.
Jack_Herrington:
Nice. Alright, well sounds like we're gonna jump into some pics. Sounds like fun. Paige, you want to start us off?
Paige_Niedringhaus:
Sure. So my pick for this week is going to be an add-on if you have a smoker or some kind of a barbecue grill. And it's called the Grill Grate. It's something that my husband recently asked for for his birthday. And basically you put it on top of your smoker and it heats up even further so that you can use it as a regular grill as well. So you can sear, you know, sear meat and it just makes it... even hotter so that the you know the idea of the smoker is low and slow kind of cooking but if you want to try and be able to do both with your smoker and have it also function as a grill this makes it possible and you just put it on half it fits over like half the grill or something and then it just heats up even further. So we haven't tried it out very much yet but the few times that we have it's done steaks really well
Jack_Herrington:
Hmmm
Paige_Niedringhaus:
so if you Yeah,
Jack_Herrington:
Nice.
Paige_Niedringhaus:
so if you're looking for something like this where you just want to have one piece of outdoor cooking equipment, but you want to get both the best of the smoker and a grill, I would definitely say this is a good one to look into because it's relatively inexpensive compared to a brand new one and it'll save you a lot of space. So that's going to be my pick for this week.
Jack_Herrington:
I love how we wonder in North American or North hemisphere summer, like we become half react and half like grilling outdoor,
Paige_Niedringhaus:
I know.
Jack_Herrington:
you know, show. It's awesome.
Paige_Niedringhaus:
Ha ha ha ha
Jack_Herrington:
OK. OK, T.J., what's yours this week?
Tj_Vantoll:
So I'm gonna pick Stranger Things, which
Jack_Herrington:
Ah!
Tj_Vantoll:
pretty popular show. I think most people have seen it before, but if you have not, I thought the last season was quite good, definitely worth watching. It's a bit long. Yeah, you have to like, we had a weekend without the kids here and we just marathoned it and it was quite the marathon, but it was good, it was enjoyable. So if you haven't checked out the last season yet, I recommend it.
Jack_Herrington:
Yeah, that we tried the first episode and I'm like, there are so many characters now. There's like
Paige_Niedringhaus:
Ha ha
Jack_Herrington:
I can't
Tj_Vantoll:
Yes.
Paige_Niedringhaus:
ha!
Jack_Herrington:
I really I wanted like a guy that was like, who wait, who is this person like?
Paige_Niedringhaus:
Ha
Jack_Herrington:
And they're
Paige_Niedringhaus:
ha
Jack_Herrington:
all
Paige_Niedringhaus:
ha.
Jack_Herrington:
older.
Tj_Vantoll:
That's actually the show's biggest problem. I feel like there's a few that they could cast off the island at
Jack_Herrington:
Yeah.
Tj_Vantoll:
this point, just to keep it a little
Jack_Herrington:
Yeah.
Tj_Vantoll:
more trimmed down. Some
Jack_Herrington:
Yeah.
Tj_Vantoll:
of them too, the plots seem to have these kind of pointless plots just to make the character feel like they're still doing something. And I don't know. But
Jack_Herrington:
Like the
Tj_Vantoll:
overall,
Jack_Herrington:
Hobbit.
Tj_Vantoll:
I still enjoyed it.
Jack_Herrington:
I mean, there's
Tj_Vantoll:
So
Jack_Herrington:
just too many dang hobbits. Like just,
Tj_Vantoll:
yeah.
Jack_Herrington:
just,
Paige_Niedringhaus:
There's
Florian_Rappl:
I'm
Jack_Herrington:
just
Paige_Niedringhaus:
a
Florian_Rappl:
sorry.
Paige_Niedringhaus:
lot.
Jack_Herrington:
get us down to like three, you know, and a monster.
Tj_Vantoll:
Hehehe
Jack_Herrington:
All right, Flo, you wanna give us a pick?
Florian_Rappl:
Yeah, I mean first of all I also want to say Stranger Things and especially because I didn't let's say watched it... I started I think three weeks ago so my wife was always recommending it to me and I mean I don't know why I didn't check it out earlier I know I heard it a few years ago but I never checked it out and... Then I just binged it, it was great. I really just went over it. And then luckily they just released us the last two episodes of season four and I gotta agree, it was really lengthy. I mean, the last episode, I looked 150 minutes or something like that, it was like, holy shit, that's a, I mean, it's more than a movie, right?
Paige_Niedringhaus:
It's
Florian_Rappl:
It's
Paige_Niedringhaus:
movie
Tj_Vantoll:
Yeah.
Paige_Niedringhaus:
length, yeah.
Florian_Rappl:
back in the days when I was young, you had to pay extra on the cinema if a movie
Jack_Herrington:
You're
Florian_Rappl:
was
Jack_Herrington:
right.
Florian_Rappl:
beyond two hours, right?
Jack_Herrington:
Oh really
Florian_Rappl:
And that was, yeah, you had
Jack_Herrington:
Wow,
Florian_Rappl:
to,
Jack_Herrington:
Germany
Florian_Rappl:
right?
Jack_Herrington:
man
Florian_Rappl:
So...
Tj_Vantoll:
Mmm.
Florian_Rappl:
Germany, right? You gotta pay here.
Tj_Vantoll:
Ha ha ha
Jack_Herrington:
Ha ha ha ha!
Florian_Rappl:
Hey, this is two hours, five minutes. You gotta pay now two euros more. So it was really the case and it's crazy, right? I mean not so long ago we also had to pay extra for 3D, now 3D is I think just gone.
Jack_Herrington:
Oh yeah.
Florian_Rappl:
Maybe it comes back with you know Avatar 2 or something.
Jack_Herrington:
Oh, okay.
Tj_Vantoll:
Hehehe
Florian_Rappl:
But who knows, I mean Avatar was maybe best example. But I'm getting off topic here, so recommendation.
Jack_Herrington:
Oh yeah.
Florian_Rappl:
So tech wise I would say BUN. if it wasn't mentioned
Jack_Herrington:
Ah,
Florian_Rappl:
yet on the show,
Jack_Herrington:
I was
Florian_Rappl:
sorry
Jack_Herrington:
gonna recommend that,
Florian_Rappl:
if I took
Jack_Herrington:
dang
Florian_Rappl:
that
Jack_Herrington:
it.
Florian_Rappl:
away.
Tj_Vantoll:
Eh.
Florian_Rappl:
I mean it's still really early but I'm so excited, I wasn't excited about a tech like that since a while ago because yeah in my opinion... it's maybe the right, wouldn't call it a successor, but maybe follow up after Node.js, right? That's just some things right and it really embraces still the ecosystem, which is great and therefore it may have higher adoption than Deno. So just check that out and give them a star because that always encourages further development. I think they are anyway so hyped right now because
Jack_Herrington:
There's
Florian_Rappl:
everyone
Jack_Herrington:
a lot of
Florian_Rappl:
was
Jack_Herrington:
hype
Florian_Rappl:
jumping
Jack_Herrington:
around
Florian_Rappl:
on
Jack_Herrington:
bun,
Florian_Rappl:
it.
Jack_Herrington:
that's for
Florian_Rappl:
Yeah,
Jack_Herrington:
sure.
Florian_Rappl:
it's so much hype
Paige_Niedringhaus:
Mm-hmm.
Florian_Rappl:
already
Jack_Herrington:
Yeah.
Florian_Rappl:
So I don't think it can get even bigger than that So if you still have some hype left and put it
Paige_Niedringhaus:
Yeah.
Florian_Rappl:
on pyro by the way anyway so now non tech maybe half tech recommendation would be a book. The God Equation, Michio Kaku, one of my favorite science writers. Since I have a background in physics, I always love reading about such things. And yeah, it's a great book. If you're interested a little bit in particle physics and a lot into, you know, science, what we achieved the last 150 years and where we might be heading here, that's a good read.
Jack_Herrington:
Awesome.
Tj_Vantoll:
Awesome.
Jack_Herrington:
Okay. Well, I will recommend something we've already talked about on this episode and that's fresh. Which I guess you could line up against, but in a way, because it is based on Denno. Anyway, it is a new, it's a new web framework, but based on Preact. So if you are familiar with Next, it'll feel very... Common, you know, it will feel very easy for you to get into. But holy moly is it fast. And it creates very fast pages. It deploys very fast if you use demo deploy. And it really fully embraces this islands architecture that we talked about for a hot second there, and that can make for very fast pages as well, because you're basically. spotting the pieces of the page that require interactivity and not downloading all the rest of it. And so you're very, very fast, even for interactive pages. So yeah, all right. Yeah, this has been great. Thank you, Flo, for showing up. And what a great talk.
Florian_Rappl:
Thanks for having me, it was
Jack_Herrington:
Yeah,
Florian_Rappl:
a pleasure.
Jack_Herrington:
our pleasure. All right.
Tj_Vantoll:
Cool? Good.
Jack_Herrington:
Well, we'll see you all next week.
Florian_Rappl:
Bye.
Jack_Herrington:
Okay, since she left, who can hit the recording stop button?
Florian_Rappl:
I hope
Tj_Vantoll:
Um,
Florian_Rappl:
she.
Tj_Vantoll:
I'm going to send her a message because yeah.
Jack_Herrington:
Yeah, whoops. This has been a technical train wreck of a show,
Tj_Vantoll:
Riverside
Jack_Herrington:
but
Tj_Vantoll:
will
Jack_Herrington:
great.
Tj_Vantoll:
keep it though, so we're fine in the recording, but we might need her in to officially,
Florian_Rappl:
Até a gente!
Tj_Vantoll:
oh.
Jack_Herrington:
Yeah, actually literally hit the stop button.
Florian_Rappl:
Hehehehe
Jack_Herrington:
Sorry, Paige.
Paige_Niedringhaus:
I mean, I made it to the end, so.
Florian_Rappl:
Yes.
Tj_Vantoll:
Did
Jack_Herrington:
You
Tj_Vantoll:
you,
Jack_Herrington:
did!
Tj_Vantoll:
were you able to stop? Hit the button.
Jack_Herrington:
Oh, but now
Paige_Niedringhaus:
didn't.
Jack_Herrington:
it's not a thing?
Paige_Niedringhaus:
So I don't know what's going to happen.
Florian_Rappl:
It should stop when we all leave, I guess.
Jack_Herrington:
Yeah, let's just leave and there you go.
Tj_Vantoll:
But still.