Paul: Hi there, and welcome to PodRocket. I'm your host, Paul, and today, we are very fortunate to have Florian Rappl, otherwise known as Flo, with us today. Flo is a solutions architect at smapiot, and more importantly, what we're going to be talking about today, he's the creator of Piral, which is a very interesting framework for creating... I mean, how is it stated on the mission statement? It's portal applications at a large scale. So, welcome to the podcast, Flo. It's great to have you. Florian Rappl: Thanks for having me. Paul: Yeah. I'm excited to get into like some of your background in this interesting framework. There's been a lot of interesting or, different, I'll say, verbiage, that's thrown around when I'm reading the Piral docs and looking at some of the talks that exist on YouTube. So I'm looking forward to getting into that. So what background are you coming from? Server side world, the front end world. Florian Rappl: Yeah. Mostly, server side world. Actually, the last, let's say four to five years, more and more front end work. I mean, it's not that I never did front end work. Right? Always... It's a little bit like, you know, the old Apple saying, if you love hardware, you also need to do the software or vise versa. Right? It can be said like that. And of course, if you like web applications, you can say the same. So, if you really love the back end, you also should care about your front end and vice versa. Right? So, everyone who loves front end should also care about the backend side. So, I was never, let's say completely out of the front end way, but for many years, I mean, I consider myself more backend guy. Though, of course, my whole let's say background story starts a little bit earlier. I guess you would be surprised, actually, I haven't majored in computer science or anything like that. I actually did a PhD in particle physics. So, something not related to software, at least, directly. Even though I would always argue that physics and the internet, that's something that fits together, if you look at the history of the worldwide web, at least. Right? Paul: That's interesting because I know more people that go into physics get their master's, their PhD, and then, they end up in the tech field. You know, I feel like... because if you do that sort of progression, your brain is trained to think like a computer scientist. You're trained to think discreetly and precisely. So... Florian Rappl: Yeah, I mean there's a lot of problem solving skills that are built up in studying physics. That really goes to how to dissect a problem and how to really think about it, let's say, in a nutshell, and then, try to come up with solutions, feasible solutions. Right? Also, yeah, I mean, even though it's theoretical particle physics, I mean, the solutions still need to be somewhat practical, right? So, you need to be able to conduct them either on paper or in engineering perspectives. And so, I think from, let's say, foundational perspective, quite good field to study if you want to crack today's problems in computer science, or just standard problems that arise when you develop something. Paul: Really quick side note, are you following, or excited about the recent energy production, like advancements that have come out for the fusion? Is that something you follow and... Florian Rappl: There is the old joke, right? At every, let's say, couple of years, every decade, there is the question, when will we have fusion? And it's always 50 years away. It's an old joke. I don't know if we are getting closer. There are always these success stories. But at the end of the day, what would really, is meaningful is are there already reactors out there that are not just for experimental purposes, but really, build to give a city power, or at least, a smaller village. And at this point in time, right? All we have is experimental success here and there. Or ITER was built in quite a large facility. Yeah. Let's see. It's all good success stories, but so far, nothing has come out where you say, this is it. On the other side, of course, we also have radioactivity. It was nuclear reactors coming up again, sponsored by Bill Gates, for instance. But also, here, I haven't heard so much in the last four to five years. I mean, in general, we have an energy problem, and I hope that one of these solutions comes soon because, otherwise, it will not look so bright in 15 to 20 years from now and we need solutions. Paul: Yeah. It's enticing conversation to talk about because there's some private sector guys out there that are saying they're going to have a small village powered in five years, which is, I'm just like, I don't know how that's possible, but power to you, guys. But anyway, bring it back to the reason why we're here today. So, you're coming from a backend server world, but yeah, everything's important. Of course, you got to care about the whole stack, because in the end, the whole stack is what the end product's being delivered to the user. And so, you created Piral. Did you see a need for this framework, or you probably did, and what was that need in this holistic picture of delivering a product? Florian Rappl: Yeah. Six years ago, I was working on a platform for smart home products, and that was already, let's say, living. Right? So, it had a lot of users and they were working on the next version of the front end of the whole UI. Of course, picked a nice native applications, and they also wanted to have a web application out there. And the problem that they had was quite simple, right? So, you now have this smart home platform, but there are all these kind of different devices that are there. And even though some of them may look, let's say, for standard user, quite similar lights, which, for instance, is quite similar to a light switch that operates, for instance, with Philips Hue, these things, other that [inaudible 00:06:32] are quite different. For instance, in the Philips Hue, you may have different colors, right? So, in your UI that you want to present for the user, these capabilities, these extra capabilities also need to be modeled somehow. Now, if you take all the different device types that this platform supported, right? Quite many. Sure, you can bring them all together in some monolith, and you will be happy for, let's say, a week. But then, a new device type comes out, or an existing device type, something just changes. There is a new capability, or an update that needs to have also, or needs to be reflected on the back end, and that also needs to be reflected somewhat on the front end. And therefore, this front end application would ever be changing, which is, yeah, just deadly, because you spend a lot of time maintaining that. So, what we did was kind of a plugin system and every kind of, yeah, device type was to model as a plugin, and was then just consumed by this application. Not only did it make the application much smaller because it only had to take care of how screens are ran, et cetera, a lot of the different device types. Also, the maintenance was much simpler, because you could give now these plugins to different teams. So the team that made already, let's say, the backend integration of, let's bring up Philips Hue again, was also then responsible of just updating the front end part of it. Right? And that was quite powerful because that enabled just onboarding new device types without ever touching the application, updating device types just on the fly. And so, yeah, we composed it together like that, that was quite successful. And after that, I had two or three other projects. Some of them were still in, let's say, some IoT field, but others are more portal-focused. And for some reason, always, when I look back, it was some kind of plugin architecture that was, in the end, the solution for the requirements that we had. So, with the smart home platform, it was quite simple, but spinning a little bit forward to some kind of a portal application that we did, they also- Paul: And what do you mean by portal? Florian Rappl: Good question. So, a portal in this case was like a customer portal. So, that was a single point where a standard user of this company would go in to, for instance, create a service ticket, see all the machines that they bought, interacted with the company in a digital way, right? It was your one-stop digital service portal so to speak. And portal, let's say, it offered now all these different services that were, yes, scattered in the company, right? There were lots of different owners of all the functionality. So, there was not a single entity. I mean, sure, there was the company, but underneath, right, quite some umbrella. Again, the solution was to have this as a kind of a shell here on the web application, and that every team then, you know, give, well, their own window to that and enhance the application with whatever they want to offer. And of course, make that consistent. So, that the same team that offers now the menu link for their functionality, of course, presents the content. And the big win here was that everything could be feature flagged at the end of the day. So, there's company that operated in many different industries, and if you have been customer of one industry, you've got a set of, let's say, a functionality that fits to your industry. But a user with a different background would get different functionality. Maybe some functionality would be the same, I don't know, like a generic feedback functionality. But for instance, one industry is really software-driven. So, they would have, I don't know, software downloads as a section. Whereas, another industry, they were really, let's say, machine-driven, and so, you had like a machine overview in the portal of that industry. Right? But it was still the same application. It was just composed of different pieces. And so, again, even though in the beginning, when I started the project, it looked very different than, for instance, the smart home one, at the end of the day, what was underneath was essentially the same architecture, right? So, you could just compose together something dynamically and teams could just contribute. And around that time, I think it was 2017 or start of '18, that term micro frontend somewhat became popular for such patterns where you compose frontend together. And when I joined smapiot, the company that I'm currently a solution architect in, we had an initial meeting, what should we do? What clients, well, should I consult? And I said, what we definitely need to do is to bring this kind of architecture that are now implemented three or four times already, and every time, a little bit different, but, you know, improved from my point of view, to make a generic and make it an open source solution. And that's how Piral came to be. So, it was actually the solution that we used already in a couple of projects that we've seen, makes developers fast, makes teams go really fast, bring features to market in basically no time, remain consistent, and well, practically, check boxes or check all the boxes, essentially. What micro frontends are supposed to do, right, what advantages you expect from them without, of course, much of the trouble. Because most of the trouble in micro frontend comes from the fact that you need to build everything from the ground up, all the def tooling, everything, how do the things come together. Essentially, deriving a bulletproof architecture. And I saw, well, since I did that now a couple of times, and I made my mistakes, of course, and I refined them over time, now, that's a good time to bring something out where the community now can benefit from. Right? And that was how Piral was born. And since then, we, as a company, smapiot are supporting Piral, and yeah, of course, are investing in Piral too. Paul: And join the podcast, consider hitting that follow button for more great episodes. So, it sounds like it's application building framework, as well as like a process. There's some CI/CD flavors built into like what you come out with about how do we organize the process of development and the maintenance and the deploying of these pieces. One word you mentioned was a micro frontend. Like, what is that? How do we define a micro frontend? Florian Rappl: A micro frontend can, of course, have a technical, let's say, definition, but I much rather preferred a more abstract one, which says a micro frontend is really concerned with the frontend representation of a business sub domain, which means you look at your whole application, and you try to identify a smaller part of it where you say this could be handled, for instance, by a single team. Or this makes sense, maybe, from a technical point of view, because, I don't know, it changes much more often the business requirements, and this thing maybe are still in flux, so they really change regularly. That this is handled, let's say, separately. That it can be deployed independently at the end of the day. So, what you want to achieve with a micro frontend is independence, essentially, that you don't have to create everything, let's say, like a monolith, a big thing already, your full application consisting of your whole business logic, but you just cut out a sub domain of it, a part of it. And that you just make an isolation essentially. And then, you can ship it, you can update it and it will always be composed together to the big part in your whole application. Right? But your concern is only now creating this one smaller part, and you do that in isolation, essentially. That's why it's usually called micro. It doesn't need to be micro from, let's say, a technical point of view. Even though it's good if it is, but micro in terms of it is really focused on one aspect of your whole business domain. Right? Paul: Okay. I catch your drip. That sounds like a great definition. The one sub domain, or one business objective really stuck with me. Thank you for that. Florian Rappl: Right. Paul: So, what do you say to the folks who come and maybe they're like, well, this is all great, but component terrorizing, or like sectorizing piece of functionality, that's literally what React is. It's like all about modulary, modular development and putting in your components. Of course, yeah, we're still in one framework, but what are the benefits you would try to, or problems that you ran into following those paradigms that you saw at Piral that you'd want to communicate? Florian Rappl: So, with React, I mean, React is great. For instance, Piral is using React as the primary framework. I say primary because, I mean, you may still be wanting, or needing to go to other frameworks, at least, for sub parts, it's fine. But let's say to define your application from a layer perspective, et cetera, we also use [inaudible 00:15:57] So, [inaudible 00:15:57] gives you a great component model, and components are still, of course, important, because... I mean, components are the building blocks that you reuse, of course. But they're generic, they're not domain bound. Think of a button, for instance, right? I mean, a button, you can define the label, you can define what it does on click, but that's it, right? There's nothing preset on that one button. Now, if that would be now a component from the micro frontend, that wouldn't be the generic button. It would be a button that already triggers something. I don't know, goes to your backend and already puts the item into a shopping cart or something. Right? So, that thing would have the main knowledge. It would already be bound, for instance, to your backend. It would already have all that logic behind it. So, if you import a button, let's say, from a micro frontend, it wouldn't just be a button, because then, it wouldn't be a micro frontend, but a component library. But if you import it, it would be a button with functionality already. So again, it's that domain focus that must be there. And that's important, because quite often, what micro frontends bring or should bring is really just domain consistency. Now, for instance, I mentioned the portal beforehand, and of course, if you had a page in the portal, that's good. But how do you reach the page? So, every micro frontend that also brings your page needs to give you, for instance, the link to the page. If it doesn't, then, you have a problem, because now, for instance, some other micro frontend would need to know that link, but that link is already domain knowledge, right? If now, another micro frontend knows that link, that will be quite deadly, because how can you now change that link? Micro frontends would need to align on that. And so, of course, in order to stay consistent, that link also needs to come from the micro frontend that gives you the content for that link. And then, it stays always consistent, because now, that micro frontend can just change the link, and yeah, it changed. It's fine. It's the same micro frontend registers it. It's good. Right? And now, it owns settling, it owns that knowledge. So, this is what it is all about. Now, even if you have, let's say, React's component model, and you create a domain-specific component in React, how do you update it in a large application? So, this is where Piral now comes in, right? It solves this. It gives you the ability now to publish these independent pieces. And by default, it does that we are a backend component. This is where we touch the backend part again. And we call it a feed service. It's not required for Piral, but of course, since, you know, you will need it at some point. Otherwise, I mean, you will need to somewhat work around it. You could always embed your micro frontends direct in your application, but what's the point of that, right? I mean, then, it's just like a monolith again. So, you can do that at... For instance, a build step, if you want to. Or what you could, of course, also do is you have some JSON fragment somewhere and you just update that. But then, you also need to solve how do you update that JSON fragment when you push a new micro frontend et cetera. So, that feed service takes away all of that for you. You can just push to it, a new micro frontend, an existing micro frontend, you name it, and the feed service will make sure that when you connect your application to it, it just delivers these micro frontends, that are currently there, enabled, and in the latest version, at least, the latest selected version and that it just works. It also has things like feature flags, et cetera in there. So, you can feature flag micro frontends and say, okay, in this region, we are not deploying that micro frontend or this micro frontend, we want to AB test, or this micro frontend, oh, there was a buck we need to roll back. And you can do all of these things. I think this backend component is what makes the micro frontends really great because this brings now this dynamic part to, well, composing the application just together on the fly, which, in my opinion, is the big benefit, technically, of course. And potentially, even from business perspective. Because, quite often, businesses are saying, okay, in some region, we need to have this. In another region, we need to have that. Or think about the example with the portal application. Okay. For users of that industry, we want to have that kind of functionality, and for the other industry, the different one. And you can just do that very easily. And without writing any ifs and elifs, et cetera, in your code. So, everything is already there on the module level, which is great. Because it can... Even be operated by someone without code knowledge, goes in there and just sets a different feature flag that, at least, was, for instance, the portal project, the big win, product owners just in selecting their target regions and everything from there on was quite good. Yeah. Paul: That's almost like a infrastructure's code sort of thing coming from a Terraform point of view. You can put which users you want, in which scopes, and which organizations. And that's a really nice thing to give to like your DevOps team or product owner. Florian Rappl: Yeah. It made things just a lot easier. I mean, you can think, of course, then, for instance, some, let's say authorization requirements that you know, for instance, you know already what backend services your micro frontend communicates to the backend service already. Exposes, for instance, the required scopes for that. And then, you can just match that also in the feed service, for instance. And you just deliver the micro frontends that could also be then used by the end user, which is just great, because no longer do you need to have in your code some guards that, oh, don't show that button if you know that that scope isn't there. Then, that goes, yeah, out of alignment, for some reason. That will always be aligned and you will never then hit some error codes in your frontend that says, oh, backend just told me you cannot do that. Because, yeah, it's just, by default, always in sync. Without someone worrying during development, right? I mean, that just is automatically there. So, in my opinion, that gives development a great boost, and it makes just things so much easier. Yeah. But it all, of course, comes at the cost of having the right architecture in the beginning and having something to sustain that. And again, that, I think, is where Piral can come in very, very handy. At least, for someone who already sort it a couple of times, living up to that story. And so, it was always quite good to see. Emily: Hey, this is Emily. One of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcasts. And because of that, it would really help if you could follow us on Apple Podcasts, so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So, check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right. Back to the show. Paul: Would you compare the potential of Piral and like the type of things people are building with Piral to like a dash, a very like in depth dashboard builder, where the widgets within the dashboard or functionality are like... You know, I've also used portals where it's like, you know, Citrix and it's, you log in and it's like a bunch of awful little widgets that you can click on. They boot up VMs and... Because when you go to the Piral website, there's a lot of very enticing dashboard-looking demos, and the modularity really looks great, so... Florian Rappl: Yeah. Yeah. I mean, if you choose Piral... So, we have... Piral a little bit block layered, right? So, you can, for instance, go with piral-core. That's what we recommend for every, let's say, production application. Because these kind of applications, what they usually want is really full control what they use, and, yeah, how it looks like. What version of React, I don't know, is used. But if you just want to get started, what you usually get this Piral library called Piral that just selects a version of React for you, and all that makes it really easy to get started. And in Piral, there's a plugin already included that's called Piral dashboard. That's exactly what you said. You get with this Piral dashboard, already an API for your micro frontends, they can just register, then, tiles on a dashboard. Of course, one of the reason is, it's very to grasp already with micro frontends can give you because that's a page where every micro frontend usually wants a share in, so, you get really on one page already, very visible, very striking, all the different, or let's say, a window into all the offerings of the different micro frontends. Right? Which is great. And on the other hand, it's something that... At least, these portal applications, quite often user want, right? So, you need to start somewhere. So, what's your starting page? And quite often, that's a dashboard or... Yeah. Something very similar to it. Yeah. We've seen also applications that don't start with a dashboard, and that's also fine. But yeah, dashboard pages are definitely among the most popular ones, thinking, at least, of these portal applications. So, yeah, we wanted to make that as easy as possible. You can make that therefore quite simple with Piral, because yeah, we just, as mentioned, have this plugin... Plugins, all what they do is they just enhance the so-called Pilot API. So that's an API that your micro frontends can use to bring their stuff to the full application. Right? So, they can reduce the pages, for instance, or very generically, so-called extension components. So, that is actually what makes Piral very useful. But in this case, they also get an API to reduce their tile. These tiles, they could have been solved also with extension components. So, there is no need actually for the plugin. But the plugin always makes that strongly typed in that sense that you get auto completion. You can see already, oh, I can reduce the tile here. And, oh, by the way, I got a second option to define, for instance, the initial size of that tile, whatever that is. I mean, design is always left to the end user in Piral. We never make a design for you. Sure, of course, our templates, they have some design, but it's all open. Right? So there's just an... A SaaS file, for instance, included, so you can just edit it in there. So, it's never hidden or something. It really leaves it, then, up to the end user to apply some styling. In styling terms, it's never opinionated. But anyway. Yeah. And therefore, sure, dashboards are one of the things you don't need to use them. I would always say you potentially want to use them, but it fully, of course, depends on use case. We've seen use cases that just don't require a dashboard. Paul: Yeah. The dashboard's cool too, because it's like a simpler... It's palatable for like coming into... Like, I can look at a dashboard and say, oh, I can see this functionality and that functionality, versus like... I don't know. Another phenotype would be more difficult to talk about what Piral can offer, I feel like. Going off of the dashboards, I would assume some of the more entry level applications that people would create are from dashboards. We could talk about all the things Piral can do and the amazing apps people make out of it, but I always like to hear about the simplest use cases and the stupid things people make. Because it kind of makes you think like, oh wow, like somebody just used it for that. Well, I could use it for this. Are there any examples that you've seen in the community of people making something silly, or very simple that you're like, wow, that was a good use of our technology, even though it was small. Florian Rappl: Yeah. I mean, I wouldn't call it simple, but at least, it's what I would call the most... Presumably, most successful demo or example that we have is actually a Netflix clone. Of course, it isn't the full Netflix from the backend perspective. But what you get there and... I mean, we can also call maybe a dashboard, but it is specifically not a dashboard. It's this overview of the movies. Right? So, like in Netflix or categories there, and then, just a selection of movies in the category. And that page runs, it doesn't use dashboard and... Sure, because not every movie is a different micro frontend. I mean, this is just data at the end. Right? But what was done there is it still consists a [inaudible 00:28:48] or six micro frontends and they still come together in some places, but not how, let's say, you potentially would see them. Because, again, micro frontends are domain-driven, so they're not technically-driven. Shouldn't be. So they come together, for instance, in the menu above, because there, you've got, I don't know, four or five menu points and they already come from, I think, at least, three or four of micro frontends. So there, you already see something on the page that comes from the different micro frontends. And the second part is that, for instance, as a micro frontend, responsible for showing these previews of the movies, right? So, the thumbnail, and if you would have all over it, it would also start playing. And they offer then a slot in their tree. And so, what another micro frontend, like, for instance, favorites can do, they can project in that slot a known component, like, for instance, a heart, where you can say, oh, I like that. It's a button now. If I press it, that's added to my favorites. And so, that already shows then the power. Because if I just turn off the favorites, for instance, the menu item and the menu bar just disappears with favorites, right? Because no favorites page anymore means no link to it. But also, the heart just disappeared. Right? So, it really consistently goes away. And if I enable it again, it just shows up at wherever it makes sense design-wise and you got the functionality again. And that already shows what it is about. Right? So, you split your domain in this case, you said, okay, it makes sense. Favorites is a different team. They do their own thing. And then, it all comes together for the end user invisibly. Right? I mean, the end user would just say, that's Netflix. No idea that there is Piral behind. And that's a little bit the idea, right? So, there's a technology that goes away. I mean, all good technologies, in some sense, go away because it's all about the value delivered for the end user, that end user just sees, oh, it's a lot of movies. That's the one I know. That's Netflix and that's great. So, in terms of, let's say, stupid examples, I don't know. Paul: I guess that's not a good way to start out, like calling out some of your awesome open source users and contributors, as, you have the best stupid example. Florian Rappl: No. I don't think we have any actually. I mean, because with this technology, specifically, people are usually creating... They're not using that for fun. Right? It's something that will only be used in larger context, which means, if I just do a weakened project, it will be the last thing that I care about to say, oh, now, I do the domain, the composition, and I just create, I don't know, seven micro frontends just for the fun of it. No one will do that. Right? It's really all about, and therefore, about enterprise users, which is good and bad. The good thing is we have to have quite some nice users. Always great to be in touch with them. And their projects, they're really long lasting and quite reliable. And so, that's great. But on the other side, of course, enterprise users are not known to be, let's say, going out all the time and just writing blog posts and being on Twitter, et cetera. So these guys, they want to have the job done nine to five, and yeah, that's how they use it. So, there are no, let's say, stupid examples from that side. The stupid examples will come from me. Right? Doing just some Piral examples. And, of course, we did some where you wouldn't use it directly for micro frontends. And so, we did, for instance, a game studio where then different kind of games in form of micro frontends are loaded in. I'm not sure if that's a stupid example, but at least, it's not a productive one from the perspective of an enterprise user. Paul: No. That's a good way to say it, not a productive example. I like that. I'm going to use that moving forward. Yeah. I mean, you're saying this is for enterprise customers, but your example of the favorites was really cool. Like that's... I mean, I can turn off this feature from my application, and everything's going to render correctly. It's like nothing of the core functionality is going to be lost, and maybe like, there's a piece from there that I'm using somewhere else. But you know, you can choose to use that piece or not. Would you say that this is a way that people should think about developing from the ground up? Or are you like, no, this is for enterprise customers? Florian Rappl: The answer would be depends, and generally, I would say yes. But of course, I mean, not every code needs to be written in a way that you say, oh, this must be, I don't know, in some kind of a museum in a hundred years. Right? So some code is just, I need to get the job done, I need to have it fast. So, yeah, let's just tie things together. Let's not follow best practice, and that's not right, tests for it. Let's just get it done. Right? And I mean, there's nothing wrong with that. But if you're right, let's say code where you say, this is where my infrastructure is based on, or this is something I care a lot about, this is where we make the money, this is our business, yes, I think it should be done like that. In some sense also, right? A question that also comes very often to me is when should I write a micro frontend? And what I can always say is, well, I mean, what you can always do is you can start in your application shell with the feature too. There is nothing wrong with that. If anyway, the application shell, I don't know, needs to support that feature in some way, it just would make it easy to get started. And then, you can still evaluate if you just leave it there, or if you put it in a micro frontend. I give you an example, that one portal application I talked earlier about, we had this shared functionality of a feedback. So, it was just a little button. You click on it, a model dialogue comes up, and then, couple of questions in there. And then, you can give some or write some feedback and just send it. And we integrated that in the applications shell, so, in that monolithic layer underneath. And it was just happy there for a couple of months. And then, we got some new requirements in there, oh, can you put in, now, a couple more questions. If the user gives it less than, I don't know, three stars, do that, et cetera. And I said, okay, that's now a good point in time. Let's put that in its own micro frontend. Because I have a feeling that will not be the last time that they come with the requirements for that, it changes. And luckily, I was right there, because we just implemented their changes, and maybe a week has passed, then, they come up with some new requirements that say, oh yeah, it's good. But now, we need to have something, if it's above seven stars, can you also do something here? And then, two weeks later, oh, we also need a consent for that. Can you end on it? It continued. And then, I don't know, every week or so, there was a change in wording or a change in a little bit the logic, et cetera, et cetera. And so, it was really great to have it then in the micro frontend because we could just independently deploy that test, and really, also, steer that. And we were never worried about the whole application again. Which was, of course, much more tests, running the whole smoke test suite, et cetera. So, deployments there took just longer, and it was always just annoying to release a new version just because something in this little functionality changed. What I think would make it really good, if you would think in terms of this modules, and again, you don't need to cut them out right away. But at least, with something like Piral, it makes it possible to cut it out and put it its own place. And therefore, also bury, it may maybe in the future, right? If there is a new successor for, for instance, this feedback thing, you just need to disable the old one, and create a new one, it's there. And that's really good, because no one now needs to throw away the code explicitly. I mean, the module is still there. It's just disabled now in that feed service, and that's fine. So, no worries somewhere, oh, I now need to restore that. Do we still have the repository? Don't need to do anything there. It just works. And therefore, I think, yes, in general thinking, in terms of these modules and about the functionality, I think it is a good way to think about applications. At least, once they reach a certain size or a certain level of importance, then, always think about composition. Think about how you can deploy individual parts, and touch just to speed that up. At the end of the day, I mean, it just will... I think it have great benefit on multiple areas. It will speed up development of the smaller ones. It will speed up build times. It will therefore, of course, lead to more satisfied users because you can, when they have a request, much faster react to it. And I think it's all about this reaction time at the end of the day. Paul: I wanted to ask this question, because it's another like abstraction layer for your brain to learn and to understand how to walk with, to really abstract correctly. Because you can just equally abstract wrong. You could draw the wrong circles and lines around your functional pieces and dig yourself into a hole. So, it's something that requires practice, and it's a question of like when do you start to deem that practice necessary. But I guess, hey, go check it out, have fun with it. See if you want to be that guy one weekend that will sub domain your components for no reason and... Florian Rappl: Yeah, why not? I mean, you need to start somewhere, as I said. I mean, also, for me... So when we introduced this, I mean, power headed from the ground up, but that pattern of these extension slots, right? So, this is what makes it really dynamic. Extension slots are maybe a little bit difficult to describe without seeing it live, but you can think about it like events, but just for UI. And now, you say, but in the UI, I can emit events. But these events are just data flowing around. But really, this is rendering of components so to speak. It's a little bit like, you know, a web component, for instance. You can have a web component that gives you already a slot, because you can just name anything you can in your document object model, in your HTML, right? My dash awesome minus component and close that. And now, you got some, what I would call a slot there. And when you now register a component with exactly that name, my awesome component, in this case, then, it will show up at this point. Now, that's great, but it has, of course, some limitations. How do you now know that nothing was resisted reactively, right? How do you know if that fails? What if, let's say, multiple things want to show up in that slot? You can't do that with web components. So, it can only be the first step. Now, Piral has this thing, and it has, of course, all of these questions figured out. So, you can define how they render, what is a fallback, for instance. How many can render in there? You can do all of that. And that is quite powerful, because there is now this, like with events, this contract between, I got this slot here. I maybe give some data in, and hey, I got something for this slot. I can fill it. I can render at this position something, given some data maybe. And it's like an event. There's this button, and it emits a click event. It will put in, I don't know, was it a mouse? What was the position of the mouse? Was it left or right button of the mouse? Things like that. And then, you say, oh, now, I got something. I got a handler for this event. And that's the same now on the UI level. Now, I got something on this slot, on this position on the screen to show. When we started with this pattern, it was... Quite often, you recognize yourself going back to events again. You're like, ah, now, I need to use data. So, how do I do that? I need to emit an event. But then, wait a minute. We have now this slot. What if the owner of that slot, by the way, is the owner of the data, just puts in the data, and I just can have a component. I don't need to have an event now. Always listening to, whenever data changes because I can just have my component. It would just get now that data from the respectful owner of that data. And that's quite powerful. But as you said, you need just to train your brain for that, because you've never used a pattern like that. You're not used to mechanism like that. And that's the learning curve the Piral has, in my opinion. It's not that Piral is firstly, complicated, but it's really that these new kind of ways that you can now use your application, that you can compose it, that's the new thing. And that, of course, was new to me as well. It's new for everyone, because we're not used to such patterns. These extension, component, extension slots, components working together. We always are just used to, oh, we got to share data container. Oh, we got events. That's it. We are not used to... there's maybe something that, in most cases, makes more sense for UI, because we are in UI. Our end goal is always to show something, right? And sometimes, sure, an event is great. I don't know. Also, it make lockout events or something, because yeah, there may not be something... That just interest have shown there, but still, most of the time, what you really want for, and what will solve your problem, make it much simple in your code too is using these extension components, for instance. But that requires training and thinking about it. Paul: Yeah. And practicing, flexing those muscles. It's almost like, you know, you're working with another DOM layer here. Just passing of events and organizing of components and code and runtime logic, and it's just a whole other environment that you need to get familiar with. But I mean, this is the answer, like this is how the common person can build their own enterprise level plugable, which is now, like, I have this word in my head after our podcast portal. Like, it makes sense, because all our lives, it's like, oh, I log into the municipality portal. That makes sense. That is what it is. Some big glomerate. Florian Rappl: It's a funny thing. So quite often, we get approached by some customers or potential customer, saying, okay, so, we now made this comparison, all there. And Piral was one of the things, and we think Piral is the one. And then, they tell us what problem they want to solve, and we say, yeah, we also think Piral is the solution. Because quite often, I mean, it really fits. They tell us, oh, and then, we got different functionality. This is already an existing application, and this. But this, we don't want for this kind of user group. And we are saying, okay, yeah, already makes sense. At some point in time, they then even say, oh, it shown on a dashboard. And we are like, yeah, yeah. Okay. Don't say no more. It's exactly was developed for this purpose. It's definitely not use case that fits for everyone, but it's surprising how many application it really covers. It covers certainly more than it's currently used for. Yeah. Let's see how much traction that can get. But anyway, it's really surprising that when people tell you their use case and they say, okay, yeah, sure, a little bit of your domain. But in the end of the day, it's really, it just fits one to one what it was made for. Paul: Hey, you should feel really proud of that, because you obviously really targeted a niche in need, and it's coming to fruition. Flo, we're coming up on time here, unfortunately. I have more questions about where you want to take this framework and the type of customers, but we are run out of time here. Maybe we could, at least, point our listeners to A, the website, which is piral.io. Where can people find you on the socials, like the Twitter? Florian Rappl: Yes. I have a Twitter, just with my name, Florian Rappl. Yeah. Google it, it's should be there. Also, of course, I'm on GitHub, same name. It's always the same handle. Maybe I should get a simpler name, but... Paul: Well, Rappl, it's R-A-P-P-L, right? Florian Rappl: Yeah, that's right. Paul: Okay. Florian Rappl: But you can always go with [inaudible 00:45:14] so it's... you know, Florian is also... Yeah. I don't know. Maybe German brand name. I don't know. So it's... Yeah. Maybe I will come up as a simpler name in the future. Paul: No, no. Come on, your name's great. And then, if people want to see Piral in action, there's YouTube videos that you're actually narrating. So, you can hear more of Flo's voice, right? Yeah. Go on YouTube, and there's like a Super Mario example on there. There's a seven or eight-minute intro. Any other resources that you'd want to point people at before we close out? Florian Rappl: Yeah. No. I think Piral is the best because it aggregates also all other articles and talks I've given over the years. Right? So there's, in the reference section, quite some links. But just go on piral.io. Check out the docs, and there's a long tutorial with, as you've mentioned, videos and everything and lots of references. If nothing helps, go to our community, gitter chat, that's gitter.im/piral. I don't know. It's also mentioned on the website, gitter.im/piral-io/community. But don't worry about that. Just, you'll find the link also on our website. Paul: Well, thank you for your time, Flo. And hopefully, some people will come and check up Piral very soon. Florian Rappl: Thanks a lot. Take care. Bye, everyone. Kate: Thanks for listening to PodRocket. You can find us at PodRocketpod on Twitter, and don't forget to subscribe, rate and review on Apple Podcasts. Thanks.