When you visit a web page, the creator of that web page's intent is to present you a seamless experience that fills your browser's window. That web page or web application is generally divided up in some meaningful ways across navigation elements, content ads, headers, footers, and other components. Those components are probably the work of independent teams. Typically, a web app is built in a single code base, pulling together all of those independent components into a monolithic software application.
For back-end software development, these monoliths are often split up or refactored towards microservice architecture. Similar approaches are now appearing for front-end design. In this episode, I interview Luca Mezzarella, author of Building Micro Front Ends. Luca, welcome to Software Engineering Daily.
Thank you. Thank you for having me today. Well, to kick things off, can you tell me a little bit about how you got your first experience in software development? Oh, yeah.
So I myself thought that I started that way. I first worked in a factory for a few years, and in the evening, I was studying how to write code in Flash back in the days. I studied obviously HTML, CSS, that I still think is black magic, and JavaScript, but I think at the beginning of my career, I was devoted to build softwares with Flash and the Flash platform that led to, let's say, starting my journey on the web, but then moving to mobile desktop applications, embedded systems with Flash platform, that I know sounds unreasonable, but it was working pretty well back in the days. And I worked a lot in cross-platform applications.
I think the whole of my career, I developed a lot of cross-platform applications that could run in multiple devices, and yeah, that was the beginning of my career, basically. So I thought, studied every day, a bit every day, because that is my mantra, and I truly believe that is the way how we keep up with good things. There has been a lot of evolution of philosophy and thought on how to design software in the time period you described. Back when I got started, everything was monoliths, and then we've moved a little bit into microservices.
Could you share a few of your thoughts on how these things have evolved through time, and maybe what some best practices are that people should follow today? Yeah, so it's completely true. So software architecture evolved quite a lot, especially in the last few years, I would say. I think from the early days of model view control, we're talking about 70s, 80s, the things have changed a lot.
I have to say, recently, I'm quite passionate about distributed systems, mainly because there is an inherent complexity that you need to handle, you need to understand and master, and there are plenty of partners that you need to study, and in the meanwhile, I still don't think that the monolithic code bases are gone for good. I think they are still there, and they should be there, because there is a lot of good for, for instance, a three-layer software architecture. There are certain software that they might be developing that way without any problem, because in reality, what they are doing is just simplifying the infrastructure part, focusing effort around the development. And it doesn't mean that when you develop a software, then you should remain as it is for the rest of its lifespan, but it means only that for a certain period of time, for a specific result that you need to achieve, a monolithic code base is still working.
However, nowadays, building software, it means more often than not, a collaboration between teams, and in that case, I see that there is a lot of value in distributed architectures. I'm going to take for granted that most listeners are already familiar with microservice architecture, a very popular idea, but I don't know that they're going to be familiar with micro frontends. As the author of Building Micro Frontends, Scaling Teams and Projects, Empowering Developers, can you define what a micro frontend is? Sure.
Micro frontends are a technical representation of a business of the main, and they differ from components on the fact that your micro frontends should be independent. So you can deploy them independently, there isn't a container that is orchestrating the micro frontend, and the extensibility inside the micro frontend is not like a component that you can extend, compose, and do a lot of other things. So that is a key differentiator. The other thing is micro frontends could be developed with same or different technology choice.
It's completely up to the team to the side. Usually, I recommend to go with the same technology, but sometimes having multiple technologies could help, especially when you are migrating from a monolithic architecture towards micro frontends, and you want to immediately start to get the benefit of micro frontends, where you are deploying in production your first micro frontends that is living alongside the monolithic architecture. And finally, they tend, as any disability architecture, to avoid sharing too much code between micro frontends, because that will miss set of dependencies or coupling, that's even worse, for disability architectures, and they're owned by a single team. So a team should own end-to-end a micro frontend from writing the code a long way to production.
So they should maintain a micro frontend and also operate a micro frontend properly. And are these design practices and philosophies, or are there software tools and libraries that can assist in the process as well? Yeah, sure. Nowadays, I would say the ecosystem is getting, let's say, quite rich.
We have a client-side rendering framework or plugins. Like, for instance, in the terms of plugins, we think about Monch Federation that is available for Webpack. And in terms of client-side rendering framework, we can think about single SPA that has been a while that is available. We have also server-side rendering possibilities.
Like, for instance, recently, there was an announcement of the creator of Monch Federation that it was able to use Monch Federation for doing server-side rendering, and that basically means that we can apply my content there. But I would say that there are quite a few interesting other possibilities. For instance, SAP launched a Luigi framework that is a framework based on iframes for encapsulating different micro frontends altogether on the client side. We have quite a few companies back in the days that have done edge-side include before the composition of our micro frontends was happening at the CDN level.
So in reality, there is a variety of techniques, and those are just some of them that currently allows you to build micro frontends. But I think the effort, although more than on the implementation details that are definitely important, should be done upfront when we start to think how we are going to divide micro frontends and how we are going to think what the micro frontends represents for our context. Are there any examples of companies or sites that have done a pretty good job of embracing this approach that you can point to? Yeah, I think there are many nowadays that are out there that are implementing this architecture style.
For instance, if we think about PayPal, there is an interesting blog post describing how they have divided their user interface for the PayPal website. ThoughtWorks have several implementation of different customers, not only on web, but also on a native mobile application. Ionic recently launched a feature that would allow to mix and match web with native code for creating also a sort of micro frontends implementation. So there are plenty of resources out there or plenty of good implementations that are representing this architecture style.
Another one that was probably the first one that I've seen in my experience was made by Zalando. It's a fashion e-commerce. The company I was working before, it's called The Zone. It's a live streaming platform.
We implemented that not only on web, but also on certain giving room devices. So there is a variety of case studies that currently are available for the micro frontends implementation. So for a company that's doing a good job, I guess one of the key features is an independence between the teams. On a microservices architecture, I kind of get the framework for that, where different endpoints could actually be routed to different backend architectures and things like that.
But in my mind, when I think of a frontend, I'm expecting one bundle to arrive at my browser. Is it still the same experience or has that shifted? It shifted. Let's say we had also in the past some evolution around sending a unique bundle like single-case application architecture towards the client.
We started to have the possibility to lazy load a certain part of our JavaScript using Webpack, for instance, but you can also use in certain frameworks the possibility to lazy load and hire components. The interesting thing is this is evolving constantly, and often we are thinking about, let's say, implementing frontend only with single-case application, but we have now different architecture styles that are on the frontend. We have the gem stack. We have server-side rendering that will happen at runtime.
We can have isomorphic applications where you have code that is running on the client and on the server, and you have single-page application, and recently micro-frontends. And by embracing micro-frontends, am I gaining performance benefits in addition to sort of the organizational benefits? It depends how you develop your micro-frontends. There are some customers that I followed in the past that they decided to go with micro-frontends for enabling their team to use multiple frameworks.
It's not, let's say, one of the best approaches, in my opinion. I think the performances should be quite key for handling your application properly, therefore you cannot really avoid to or forget about them. One thing that, although I have seen that is very interesting, especially if we compare micro-frontends with a single-page application, is before you were downloading the entire bundle with all the SDKs, and despite you were an authenticated or not an authenticated user, you had all the application code. In this way, instead, with our micro-frontends, you can download only the code needed for a specific task.
So imagine, for instance, that we are slicing our application in multiple domains, and then we have, I don't know, for instance, a catalog that is under an authenticated area. So what you could do is serve in just a catalog or a portion of the catalog in micro-frontends, and then, let's say, meanwhile, the user is going through the entire UI, slowly was heading, loading only the parts that were needed. And that basically resulted in savings, a lot of kilobytes, potentially, because if you think, for instance, for, I don't know, a retail application or even a subscription service, the user subscribes just once, right? So when it's subscribed, then, unless it's going to change its payment method, it's not going to need, once again, to download the code for all the SDK, for a credit card, PayPal, and all the other payment methods that you want to apply.
So in that case, it also means that you can save that when the user is authenticated and just provide the code related to the authenticated area, and maybe also only a part of the authenticated area, because if you divide your authenticated area in multiple micro-frontends, then you might risk that it's even lighter than what the user is doing. So I have always been a big fan of allowing developers to pick their own tools. I guess maybe the danger to that is you end up with this Frankenstein monster of different technologies and no one knows the big picture. But at least in the back end, we have some nice approaches like microservices.
You know, it's just a JSON input with a REST interface. I don't really have to care what's behind the scenes. I have this kind of universal way of talking to that service. I'm having trouble picturing how that might work on the front end, like if we have a team that does React and another team that's invested in Ruby, how do we get them to collaborate?
So the collaboration could be in different ways. So it really depends from your context. I'll give you an example. Cross-functional teams are definitely a thing, and therefore you have to, let's say, think about micro-frontends that could work with cross-functional teams or with components teams, so just front-end developers, for instance, and you have another team of back-end developers.
The reality is it really depends on how your organization structure works, because in fact, if you have micro-frontends that are running cross-functional, for instance, you are going to have your team that is responsible maybe for one subdomain, piece of subdomain, and then you have the back-end working together. And you can, potentially, what could happen is that you have one team that is working with React and another with Angular. That, usually, there are ways to isolate those two code-based. For instance, if you have a team that is working with React and they're using, I don't know, much federation, you can have a different scope, or if you're using iFrame by design, you have these sandbox that basically is isolating your code from the rest of the application.
If you're using on the back-end, so you're doing set rendering, potentially, you can think on having more standards, or maybe you have HTML fragments. But usually, what I have seen so far, more than having, as you described, franchise-standard architecture, having a consistency on the UI, it makes me more sense, and also, it will allow you to really optimize your dependencies and the code that is shipped towards your users, because otherwise, the user is downloading more libraries than the business logic that has to be used inside your application. I don't see the benefit around there. A question that's forming in my mind, then, as I think about splitting up a front-end is how do we manage any shared state that's there?
Should I be thinking about that? Are there techniques for sharing state, or do we really want the subsystems to be independent? Yeah, so sharing the state usually is what I call an anti-pattern, because there is the having a global state across multiple micro-frontends in the same view. It's basically by the concept of independent artifacts.
Then you need to start to coordinate with other teams, and if someone introduced a bug, maybe it could affect other micro-frontends. It's not an easy thing to handle. My recommendation there is using publish-subscribe patterns that with microservices helped a lot back in the days, and still today is helping. So in the case of front-end, for instance, you can use an eventimeter, you can use reactive streams, you can use custom events that are native in JavaScript, and in this way, you are basically communicating what are the inputs and the outputs of your micro-frontends, so you know exactly that the micro-frontend is reswatching certain events or reacting to certain events.
And that is a good way for maintaining independence between the teams, but also maintaining loosely coupled your micro-frontends that can communicate easily through events. Usually, to be honest with you, if you slice properly the application, you're not going to have a gazillion of micro-frontends in the same view. And therefore, if that is true, and you have a few of them, there won't be many events that are bubbling around the application. So in terms of slicing up my front-end, then, what do we do in terms of layouts?
How can I assign different regions of my front-end to different teams? Yeah, so usually my suggestion is starting always from how the users are interacting with your application, so understanding that part, understanding then how many teams have to work inside the application, and how much reusability you're going to have inside your micro-frontends. When you start to see those dimensions, you start to follow also the concept of domain-driven design, where you identify the different domains. And probably, if you are working with micro-services, it's something that links very well with the front-end.
You can start to understand what are the different parts of your application. Personally, I found it very useful looking at domain-driven design in conjunction with how the users were interacting with the application, because I discovered quite a few interesting things. So, for instance, an authenticating user where was going, and which path we were following, how often it went, I don't know, in the my account area, for instance, more than logging out from the application. So those kind of things are information that are absolutely great, and you should take into account as an input for understanding how to slice your applications.
Can we dive a little deeper on domain-driven design? How do we start from, well, let's hope that the business has a good definition. How do we take that and start to shape our micro-frontends with respect to it? Yeah, sure.
So my suggestion there is starting from the business, right? So you want to first have an ubiquitous language, so everyone's talking in the same way, business and techies. And then you start to analyze how you compose your application. For instance, maybe you realize that your application has a payment domain, and then you have, I don't know, a user domain, a catalog domain.
And it depends how coarse-grained and fine-grained you want to go, because it depends how big is your company and how complex is your application to model. But there is usually a good starting point. And then from there, you start to understand, okay, I have this big domain, and how I'm going to translate that in microservices and micro-frontends. And that also depends on how you structure your teams, how many people are going to work in that domain, and so on and so forth.
Because personally, I have seen certain cross-functional teams that were going very, very granular, but there was just one, and they had to handle tens of microservices and micro-frontends, and it became very quickly unmanageable, despite you have a lot of flexibility. So sometimes you need really to rationalize on and realize if you really need to go that deep on dividing your application or not, and which benefits you are losing and what you're gaining. So I think it's quite important to trying to understand properly not only the application, but certain decisions should beat your organization. You mentioned iframes as one way to do this, which makes perfect sense to me.
You have, you know, a complete isolation. You can just kind of have a grid and populate it with different micro-frontends. But iframes always make me a little nervous for some reason. For one thing, SEO concerns, but also, and it just feels like something that's perhaps being phased out.
Maybe I'm wrong about that. Should I be concerned about using iframes? You should, and you're right. There are other techniques.
Iframes is one of the possibilities. I think if you think in the context of SAP, they are working mainly in enterprise applications that are must-order at a time internal and not external, therefore their SEO is less. important if you think about that on the other side if you have like a front-facing application that maybe is consumed by millions of customers going with other techniques that could be some side rendering for instance if SEO is really really important could be a possibility now there is if you want to talk about iframes there is currently a draft in the tc39 that is looking into javascript language around reals i think they changed recently the name i need to check that shadow something should be shadow real i think is it and they are basically providing the same benefits of iframes but without the heaviness of iframes so you have a real sandbox but in a very lightweight approach that is something very interesting it's not there yet but something to keep an eye on it but in general you can also scope your javascript in a way that doesn't clash race system js allows you to do so or in the inside rendering phase i'm talking right now or even much federations there are ways that you can mitigate that problem without using iframes let's say the iframes has another pass that is handling the memory for you because the moment that you are removing or changing the location of your iframe then everything that is inside there is disposal other approaches instead you need to request the microphone tends to remove all the listeners and maybe clean up a bit the variables and the things that were created inside the main memory for them leaving the garbage collector later on of the javascript engine to handle the disposal and ultimately in a micro front end am i transpiling or compiling or getting everything into javascript one way or another or is there an opportunity for other languages to be involved present for the user on the front end you are transpiling javascript as usual so as you are doing currently in single page applications you could do exactly the same way with micro contents i think the the big difference although is that instead of having like in a monolithic code base just once for everything you're going to have for multiple parts of your application therefore the automation part is kind of key for achieving let's say good results with micro content you cannot really think of micro contents or in general i would say distributed architectures without an investment on the automation part one advantage in sticking to strictly a single framework like view or react or angular is there's a pretty mature path for how it gets built and deployed and all these sorts of things i like it very much it's quick to start things up i feel like there's a layer or something else i need here to orchestrate or connect all my tools is there a solution to help me adopt micro frameworks or do i have to invent a few things along the way no that's true and once again this problem was was solved in different ways for instance if you think about single spa for client-side rendering you can do that very very easily because you can create an application shell as it's called and application shell is the container of microphone that should be completely unaware of the business domain therefore could be actually run in multiple contents despite that is a specific domain or another one because his role is mainly loading and unloading my contents based on the routes that currently the user wants to see and that is one way in the case of uh server-side rendering instead you have like a mapping between routes that is one page one set of my contents at the end it doesn't change much because the composition is handled at the server-side level and therefore what happens there is you're composing your microphone and serving the page to the customer so it depends what kind of approach you want to use if either server-side rendering so in that case for the customer at the end is downloading just the full page with like you would do on a normal server-side rendering application or if the user wants something else and therefore you want to create a inside rendering application with an application shell that is taking care of a portion of their orchestration that has to happen in the micro-contents world and how does this affect our release schedule if we have kind of these independent features where teams own different pieces of the front end can they also do totally independent release schedules yes indeed not always i would say in my experience there is always at some point during the year the moment that you need to change multiple micro-contents for delivering a feature but the idea is exactly that so you are independent team and you can deploy as many times you want and that's something that i have seen with my eyes in my previous company where we move from monolithic code base with a release schedule that was quite tight to micro-contents we could atomically deploy a portion of our application and then we could do multiple times then you can use also for enforcing this mechanism and minimizing the blast radio if a bug is introduced inside the code like feature flags or kind of releases that would allow you basically to shape the traffic on how many users will see the new feature and in that case you would be able to also minimize the risk that you are impacting multiple customers and that is usually a great way for encouraging developers to be more brave and start to ship more often sometimes there is a paralysis that is happening because developers are not feeling comfortable with their ci cd and automation strategy for deployment for deploying more often than i don't know a few times per month they're called instead if we are capable to create an environment where automation helps them to create confidence i think we will be in a great spot and distributed system really need that because they are doing already a big favors with developers reducing the cognitive load that they need to take care of therefore there is less reason they're going to introduce bugs like in a large code base and also the fact that there will be a knockout effect across multiple parts of application so we have already this so then that next part is having a strong automation pipeline that will help developers to build their solution with a fast feedback group when we have our application divided up then into these micro front ends of different components i can see where there's a lot of advantages in that they can independently manage dependencies and things like that perhaps we can reduce some bloat yet there are commonalities probably every micro front and needs logging or axios or something along those lines can we introduce it or do we end up with a new type of bloat where we have redundant things because of the independence not necessarily it depends how you want to structure that so in the case of a shared library is what we could do and i've seen in many occasions creating a repository just for shared libraries and in that case basically we'll have this own pipeline for deployment and all the micro front ends will basically externalize those dependencies and they will rely on the fact that the first will be loaded this vendor package that contains one what's called shared frameworks or libraries and then they will be loaded so they will rely that basically when my friend is loaded in the page they framework is really available so you can minimize that for this thing the challenge there is creating a solid governance that would allow the development teams to update the security account and then with a good structure the process for deploying a new version because at some point there will be a new version of angular react that they want to deploy and they need to make sure that every mac content is up to the game because otherwise they could have some runtime errors or issues for the user experience that really you don't want to have so we talked about just briefly some of the different ways of composing these pieces we could do it all client side which has some advantages we could do server side which has different pros and cons or even edge side as you mentioned could you just explore a little bit and compare and contrast why these different approaches would be right for different groups sure let's start with server side i would say that when you have seo requirements or for instance you are developing an application that doesn't require to have and if you want a native application feeling i'm thinking at the moment like when i was developing on smart tvs where you need to have this sort of feeling that the application is always there using some side rendering is a great approach and moreover there is also the fact that you can really optimize your code before the ship so often if you work with an application in countries where the infrastructure is not as great as it should be and you would really want to optimize at the bite so that rendering is definitely the good way to go website include or website development in this case is usually used so i've seen currently only with ikea there was an info queue and this article that was described in that part where they were describing basically how they have implemented using outside include and client side include the good thing of the creating content on the edge is the scalability because obviously point of presses in a cdn are way more than origins that you can have but the drawback there is the developer experience is not great at all and the other thing is outside include is not available in all the cdns providers and also the cdn that are embracing this market language they are not using the full specs so you can find them in akamai definitely but in other vendors they have a subset of the possibilities and finally you have the problem of dynamic content so imagine for instance you want to have a personalized catalog you risk that you need to implement that portion using client side includes that basically is the same technique of outside include but it's happening on the client side and it's basically starting to have a bit of code that is happening on on the outside and then some others that he's using on the client side there is nothing wrong with that but i would say it's slightly more complicated because if with some side or as a mortgage application it's to certain extent there are tools for handling that properly nowadays in the developer experience for outside include it's not that efficient and finally client side rendering is uh using all the use cases where you use a single page application so if you want to have very immersive experience for the user and all you want to create for instance a solution that is trying to mimic without too many reload of the application what you could have in a sort of native experience you can even think about that so what i'm going to see next is really my anecdotal personal bias i didn't really do a survey or anything but my impression is that microfrontends are a new contender idea maybe they will become the standard or the norm but they aren't that today most people currently still build these sort of monolithic maybe single page apps or things like that can you talk a little bit about the reason someone doing that traditional type of development might be motivated to migrate their application there are several for instance the fact that you are de-risking the deployment is a big one despite the size of the organization the other one is organizations are growing very fast nowadays and applications are developed by many teams so we have to find a way to scale your our development practices also the front and not only on the back end so i would say it's a quite key in my opinion thinking if we obviously i'm not saying that microfrontends are a bullet at all i know that there are some limitations and it became more complicated and there is some overhead behind them but in reality when you start to scale your organization i think are inevitable and having you can think on having some benefits of my content modularizing your code but it requires a lot of discipline a lot of coordination and it's something that you could do up to a certain extent when you're growing but then when you hit i don't know five seven ten fifteen teams working on the same code base it becomes more time working on three meetings than writing code so you really need to figure out a way for creating independent teams and therefore if uh scaling challenges and let's say reducing the last radio for deployment are some of the key benefits that are provided by this approach do you find that there's any learning curve for technology groups who decide to adopt this philosophy totally i think uh more on the technology side that i would say there are few concepts to be aware it depends which architecture side you are going to to go through uh so i said rendering or so i think the main challenge is a mindset challenge where you really need to understand how you should slice your application how you can get different parts of the microcontents should communicate together if it's a female data if it's a token for instance you want to share how to design the eyes for microcontents and so on and so forth so there are some shift of mindset that has to happen and sometimes also accepting that duplicating some code at the beginning is not that bad like both and we i know developers are really enjoying the fact to abstract code but unfortunately premature obstruction are definitely more expensive than the duplicated code so we really need to understand when to do that because we are moving away from a monolithic environment where everything is there and everything is under the eyes of everyone but we are moving more to a decentralized environment where you have everything that should operate inside certain boundaries and you cannot have eyes in every single part so that basically will lead to have more automation and thinking more globally about application well you've outlined a number of factors that make these ideas very appealing from a software engineer's point of view in terms of code maintainability the release cycle all of these positive aspects when i think beyond a software engineer who might be excited about this and think about what about graphic designers and ui ux people if i frame it in the most negative light maybe they would say oh now i have instead of one path to execute my work i have to interface with n teams and get them to all coordinate to achieve the design in the style of the interface i want is there going to be new challenges for ux ui and graphic designers and things like that and people like that i think they need to figure out what is the best way for communicating definitely there will be some communication challenges my usually my advice usually is starting with the basics so having a solid design system that can be embedded and then potentially start to collaborate closer with the teams i have seen many organizations where designers are completely detached from development team others that i've seen them collaborating more strictly and obviously having a different output and outcome from being detached so i would say definitely there will be some some changes but i don't think it is going to be a massive change that is going to be so disruptive i really think that you can with the right amount of people and having the right amount of governance around that you will be able to have a very consistent and cohesive experience for your users i think the governance here is the key when we talk about the ux and ui because the moment that you understand that you have distributed system and it requires some coordination when you want to apply certain things everywhere or in multiple parts of the application having a solid governance that has to be refined meanwhile obviously the developers are working and also uh the companies is evolving it is quite a strong requirement in my opinion when i was thinking about that and we were implementing i've seen that the fact that you have the communication flows that are going smoothly across multiple teams it was quite a requirement so that for me and it's only for ux and ui it's basically for entities shared across multiple teams you mentioned a couple of large organizations already embracing these ideas and i know there's a few more listed in the actual book that said so you know ideas definitely worth paying attention to where are we on the adoption slash hype cycle i would say that currently we started to ramp up the adoption there are many many organizations and the process especially that are looking into them they are doing the first pcs or they have already something let's say ready to be shipped over rating production so i have seen mainly enterprise customers mainly because if you think about that they already have maybe some some analytic architectures that have to migrate away and they want to scale the platform they want to even to create consistency across multiple portals that are handling multiple products that they're handling and therefore they want to create a unique experience for the user and they think that this approach my content could help them to a certain extent i i've also seen many customers that have a sort of my content implementation i'm pretty sure that if you're familiar with microservices you have heard at least once the concept of modular monolith where you are basically creating your code in a way that then migrating from a modular monolith to microservices could make sense and sometimes i think a modular monolith is more than enough oh it's exactly what you need and in this case it's the same i have seen people that were working with some concept of my content without using the full flesh of the architecture and it's already in production for several years and they divided their application in multiple parts so the team can be independent so this need is not something new it's something that it was there but no one trying to streamline in a way that could be replicable but by many well from our discussion i feel like i've gained a pretty clear idea on how i would take these ideas into developing some uh desktop application that runs in my web browser and of course i can make you know a mobile friendly web view version of that but there's also a certain amount of the web that runs on native applications and things like that can we bring these ideas into a native mobile setting as well yes indeed a interesting part i think at the moment the main implementation i have seen was made by thoughtwords that they use for an android application because you can they leverage the same the same concept you think about that so you can load some packages that represent certain features that basically represent certain domains and therefore you can lazy load portion of the application based on the user experience one thing although that we need to be aware is how you want to create this user experience for your customers because sometimes you can load an application but then you're not opening the app straight away you're opening maybe when you don't have enough connection or you don't have connection at all and therefore we need I think also that realistic edge case and try to handle in a nice way the user experience for the user. It could be as simple as suggesting that the application should be available only when a user is connected or in some other ways, maybe having prepackaged certain areas of the application that would allow a user at least to see something or have a partial experience.
But apart from that, yes, I have seen on Android implementation and on other frameworks, like I was mentioning before, Ionic, that is another framework that would allow you to achieve that. And it was released literally a few days ago, so I still have to put my head inside the whole concept, but it seems promising what they've seen. From the end user's perspective, if I'm not involved in the software, I'm just a consumer of some application, should I be able to tell that they've adopted these velocities? Ideally, no, because otherwise it means that we are failing.
The moment, as a user, I should have a crazy and coherent experience. The plus for me as a user, if a company is using microphone dance, is the fact that they can see more often changes and new features because developers are moving faster. And that for me is the main plus. You could argue that with certain engineering practices, you can have something similar, but sometimes, you know, especially in certain environments, you need not only engineering practices, but you need to have some architectural structure that would enable developers to use engineering practices to move faster.
And that is quite key. And I think for the final user, they should have exactly the same experience that they had before without any being penalized at all. If I ask you to speculate and think, I don't know, five, maybe 10 years out, what percentage of the web is going to be following these design principles? Oh, that's a good question.
I would say that not much. I don't say that it would be mainstream, like 50% of the website would be there, but I think there would be quite a lot of enterprise software that would be developing this way because I see a lot of value in large organizations. I've seen also smaller organizations using microphone dance for multi-tenant applications. That is another use case that I have seen, but it wasn't ramping up like I have seen with enterprise customers.
Well, circling back around on the book, building micro front ends, is this for an executive, like a C-level CTO, a developer, or who's the audience? The audience is for the code attack leadership that could include from a senior developer to a CTO. The reason behind that is I always thought that as an architect, my role is trying to create mental models that would allow anyone to understand from the C-suite to developers how we could write software. And more often than not, in many books, I have seen a lot of examples and people that were taking those examples and applying production without thinking what there was behind.
Instead, with the book, I wanted to do something different. I want to provide the mental models, the reasoning behind that, and then the implementation details I leave to the different frameworks that are mentioned inside the book because I'm pretty sure that they do better job than what I could do, especially because they are changing more often than the book. I have also some parts where I describe how the code is working and how we should be reasoning for providing an application and so on. But I have to say, it's not a book where you can find many lines of code for covering all the different practices because I truly believe first we need to understand the architecture, the principles, and how everything should work and then understanding the reasoning for migrating towards micro-contents.
That is another part that I dedicated a big part of the book. So the book is not covering only the technical aspect but also the organizational aspect, the practices on how to communicate between teams, how to design the API successfully for micro-contents and the different options that we have available, how to share the information between micro-contents and so on and so forth. So it's definitely a book that provides strong ideas that I've seen successfully implemented in multiple frameworks but going there and covering for every single framework it would be really sick. So for those tech leaders, senior developers, all the way up to C-levels who might be interested in the book, where can they find you online and where can they learn more about the book?
There is a website called buildingmicro-contents.com where you can see how the book is structured and there is also a newsletter that every now and then I try to send some updates on the book and what's happening and what people are thinking. Recently, O'Reilly shared for chapter three that is quite a key chapter for the book where I'm describing basically what micro-contents are, how to slice the application, the principles behind micro-contents because I think it's a quite key chapter for the entire book. Then also, if you look for my first name and last name, every social you can find me very easily and yeah, that's it. Awesome.
Well, Luca, thank you so much for coming on Software Engineering Daily. Thank you for inviting me. It was a pleasure being here.