Confirm dance, are what I call a representation of a piece of sub domain and we should differentiate them from components because components are solving technical problems. So, I want to reduce this specific functionality it in multiple places of my code base, but Mike from Texas that you're looking from that product side, you start to look at how you can create value can generate value in isolation for your users. Hey everyone. My name is Henry Surya Barragan.
And you're listening to the tekhelet Juno, the show will be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our Journal. Hello. This is Henry. It's great to be back here again with another new episode of the
tekhelet journal podcast. Thanks for spending your time with me today, listening to this episode. If you haven't, please subscribe to Tech. Did you know on your favorite podcast apps and also follow our social media channels on LinkedIn, Twitter and Instagram, you can also make some contribution to the show and support the creation of this podcast by subscribing, as a patron at technology. No, dot f / Patron, and help me to continue producing. Great content every week.
For today's episode. I am happy to share my conversation with Luca Meza. Lira, Luca is a principal architect at AWS an expert on micro front ends. And the author of the upcoming building micro front-ends book. Today's applications have become increasingly complex and often built by a combination of multiple teams working together in order to deliver. The best user experience for customers. While microservices has become a
popular architecture of choice. At the back end Services micro front ends also has started to offer similar benefits that can be applied when building complex front ends or web applications
in this episode. Luca describe the concept of microfinance in depth, along with the where and when companies should apply this concept for building the front ends, as well as sharing how he successfully implemented microfinance at the Zone. He also shared about the important principles behind microfinance why it Is important
to be technology agnostic. When building your microphone ants and how to design the CI CD pipelines to stitch the different microphone ends together and deliver it as a one unified product. Luca also mentioned some of the common pitfalls and anti patterns that we should avoid when using microphones as well as sharing his tips on how organizations can start adopting microfinance in their
architecture. I enjoyed learning micro front ends from Luca and I hope you will enjoy this episode as well. Consider helping the show by living it a rating review or comment on your podcast app or leave us some comments on our social media channels, those reviews and comments are one of the best ways to help me get this podcast to reach more listeners and hopefully they can also benefit from all the
contents in this podcast. So let's get this episode started right after our sponsor message. Are you looking for a new? Swag tackle, it Journal. Now offers you some swags that you can purchase online. These wax are printed on demand based on your preference and will be delivered safely to you all over the world where shipping is available. Check out all the cool tracks available by visiting technology, you know, dot, f / shop, and don't forget to break yourself.
Once you receive any of those tracks. Hey everyone, welcome back to another new episode of the tech lead, you know, today. I have another awesome guess. As for us to have a conversation, his name is Luca Meza. Lira is actually an expert in micro front ends. So for some of you who are into building ui/ux front and Technologies, but this is an episode that you don't want to miss. Luca is very expert in microphone. And since I think long time ago, maybe let's clarify later with
him. He's been working at dazzling, helping them to transform their platform into a global streaming platform. And now he's working at AWS Amazon web services as principal architect. Welcome to car to the show. Good to have you here and hope to have a great conversation about microfinance. Hey harry, thank you for having me. It's a pleasure being here and I'm very excited to have this episode video. So do come. Maybe in the beginning. Can you help to introduce
yourself? Maybe telling us about your highlights or turning points in your career? Yeah, absolutely. So I started working in it when I was 21. I must have thought person. So no University and I'm studying I learn Old school way. So coding every night every day, Sunday Saturdays. There wasn't a time where I stopped. I started with flash platform back in the days in 2004. And there, I hit a lot of success, to be honest, because the platform was great and allow me to unleash my creativity.
I work mainly outside the browser. So mobile devices, embedded devices. I work even on a motorbike with the creating, like a dashboard and digital dashboard instead of the mechanical one. And it was quite And to be honest, but after 10 years living in Italy, where I'm coming from, I decided to move to UK. First of all, as a lead developer in a startup called we describe.
And basically we were doing a software for creating these kind of videos where you have like hand that is writing and mimicking, real person, that is throwing after few months. I was cold in London and they moved as a senior developer in a gambling company. After a few months. I became Tech leader, there. I change the way how they've used to work. We Being software because we were used to develop gambling game, one every nine months.
And when I left we moved from nine to three months of delivery time where hundreds of people in my department we were doing 80 percent of the revenue. It was quite fun and very engaging. I was quite an interesting project for me because it wasn't touching only the tech part. But also the people side after that I moved to an agency called massive interactive. That was specialized on multi-platform core streaming platform.
I became Extremely passionate about that because I understood that the industry was in the middle of a revolution. And it was extremely interesting, developing on consoles, Smart TVs and set-top. Boxes had the opportunity to have my hands dirty in the code for a few set of boxes. It was extremely challenging but I have to say extremely rewarding as well. They are. I follow a project for a company called The Zone, where then a
transition to them. Basically, in 60 year, we move from not having a brand and not having a reputation. Into having a global distribution in over 200 countries and the think that was one of the key highlight of my career because I had the possibility to take the project basically day one. Since the Inception work closely with the product team and create a platform that raised a lot of success worldwide. I was able to travel a lot, the word. I was in Japanese launch.
I wasn't Italian launch. I follow basically all the key turning point of the company and I was slowly but steadily growing personally and also my career wise Because I became at the end, vice president of architecture there. And then after six years, I thought that was the time to see if this knowledge could be helpful for other companies. So then I moved to a WSS principal architect. So, look at what made you decide to go into microfinance because
hearing what you say. Just now about your career, it seems like a lot of variety things that you did. There is an early sign for you working in my digital dashboard and things like that. But you moved on into architecture Global streaming platforms and things like that. What me? Decide to go into microfinance. Yeah, that's a good question. So, back in the days, almost five years ago. We had the challenge. We just released the Zone platform in few countries.
Germany, Austria Switzerland, in Japan. We had a massive growth. We move from hundreds to thousands of people in a year and a half more or less. Obviously, we wanted to develop our solution and have certain flexibility and agility mean. Well, we were developing and the team was distributed across Europe.
So one challenge that I had to face was thinking how to move from a monolithic code base on the front-end and back-end to a distributed system that would allow a team to work at their own speed and reducing the communication of red across teams. Obviously, on the back end, we have Consolidated Partners like, microservices, but on the front end, we didn't have much to be honest with you. So what I have done, I started his journey on identify.
What are the Rules for making a successful distributed system architecture. And I took the principle of microservices and I try slowly but steady to apply on the front end because the reality was I couldn't have tens of developers, working on the same code base and coordinate across multiple offices. Also, with pandemic that situation could be even worse because you start to have people
working different time zones. So what we have done, basically taking those principles behind microservices, apply to the microphone tents and Came up with a bunch of principles that were our North Star and start to slice our application using a bit of domain-driven design. And looking at how our users, we're interacting with the platform. And based on those information. We sit down with the small team that we had back in the days. Looking at the platform.
We identify a bunch of bounded context, that could be splitted the platform and then suddenly we realized that it could be extended and to end at the front end but as well on the back end that was an extremely interesting. Journey. Because as you can imagine five six years ago, they wear and guidelines on how to do that for us. We had to reason find the right way for approaching this challenge. It turned out that in less than a month.
We were able to have a POC up and running and working on web and few TV devices. Performances were pretty good. Obviously back in the days. We had to figure out the right way to do this because we could end up very easily to have an overhead of creating a lot of tools for streamline the developer experience. So, So, one of the Mantra that we had is trying to keep our implementation as agnostic and close to vanilla JavaScript as possible.
That doesn't mean we couldn't use Frameworks or anything but we were smart enough back in the days to try to simplify the creation of all microphone 10th and compose them all together. Using paradigms that are already available like using HTML Dom for stitching, everything together and leveraging a solution like a pending the synchronous JavaScript. On the dorm and automatically the browser was taking care about loading and parsing and everything.
So we try to be as simple as possible in order to achieve our goal and split up the development of our tips. So maybe for people who are mostly familiar with microservices. Could you maybe describe what does it mean to have a micro front-ends architecture? Yeah. So usually when you take all microservices you start to look at your subdomain. So you take a complex process form and you did. Buy them in smaller problems. For instance.
Let's take Netflix that probably everyone knows you thinking Netflix. Obviously, you don't just watch some content. You have like customer support, you have a possibility to change subscription type. You can pay with PayPal or credit card and all these part contributes to the final platform. So, the final domain, obviously, you cannot take all that in one go. You need to start to slice those boundaries and divide them in subdomains.
And then inside the subdomains you have what is called bounded context-aware? Are you identified some areas that can be taken in isolation? The same thing happened on the front end. So if you look at the front and side imagine like the Netflix website, what do you usually do as a new user? You go to a landing page, then if you like the offering, you go to the signup journey and that during the signup flow, when you finish that, you go to the catalog and you start to watch content.
So just with this free, you can easily identify potentially free different user flows. The first one is for the users. That are going to Netflix and trying to understand what the service is. And maybe they stopped there and maybe they don't care because it's not fulfilling what they are looking for. And therefore they stopped. Their second step is signing up. Usually you have one part for your personal data and you share your email address, first name,
and last name. And then the second part for your subscription type and payment. So those things for instance can be bundled together because if I'm a user, what I'm doing is first understanding, if I like the offering if I go The offering and move forward. But when I have done this and I'm convinced about subscribing, I'm not indicated User. It's unlikely that I'm going to the landing page or to the sign up page. The reasoning behind that is try to create some context and some
experiences. If you want for the users, that will allow the user to download the code only for that specific experience. Obviously, if you want to download more happy days, you can do that. But that's the initial idea obviously later on. We discover that you can even go more.
Granular, so, there are situations where for large organization, especially, you start to have microphone tensing, the same view, because in reality, there are situations where you have multiple tips, or you have a microphone that can be reusable across multiple views. So, in both cases, having my contents that are smaller fine grain compared to a more larger drain. It solution is definitely a possibility.
So at the end of microphone tents are what I call a representation of a piece of sub domain and we should differentiate them from component. Those components are solving technical problems. So I want to reduce this specific functionality it in multiple places of my code base. But Mike from that, is that the, you're looking from that product side, you start to look at how you can create value can generate value in isolation for your users. And that's basically where we
stand at the moment. We make them tense. So in terms of applicability to technology, is it only for web-based? Front-end. Can you also apply to mobile devices? Native hybrid? Yeah, so, it's Anarchy. Textured. So therefore is not bounded to a specific technology. We applied on web and TV devices. Not all of them, but some of them therefore living room devices and the outcome was positive or mobile. We didn't because we were working with Native Technologies and the back in the days.
We didn't spend too much time on revamping that because application was running very well before. We didn't need to review that part. I would say yes, is applicable, so mobile. So if you're using react native or other solution, yes, you can definitely think about this. The only challenge that you have a mobile. That's a question. I had with quite a few people. Is that the nature of web usually is that you are online by Design? So, if you want to Consumer websites, you need to be online
on mobile. You need to think also on the offline experience. So, if you start with an empty package, if you want, and you have an empty application as the device that you are composing, everything that could be an idea. But if you think about creating a smooth user experience, potentially, you need also to think on downloading these microphones and During inside the device or maybe having just a bare minimum set that will allow the user to have a decent offline experience.
And then you have let's say something more to think about. I think it's totally doable. But at the same time you have more to think about because obviously the nature of the experience there is offline and online and sometimes offline. First personally. I'm quite annoying when I play games that you can only play online because maybe you are doing commute and you are in the tubule in London and you don't have connection for any given reason.
Therefore, I To play My Favourite game by a cannot. So we need to think also about this stuff. It's not just showing a nice page say, oh, please connect to the internet because sometimes you can. So if I hear about the history, just now when you mentioned the work that you did with microphone and you are actually taking some of the principles from the micro Services, which has been around for longer than microfinance. So, now that you have this both microservice and micro
front-ends, how does it work? Do they actually vertically share the same team. Same, Groups or they also still split between front-end and back-end. So there are different schools of thought. I personally think you can do both. And I explain why one way to endl to the team Communications. Usually it's through API contract.
Apis basically allows you to define a contract between two or multiple parties, as long as you respect the contract, everyone can work in isolation and can work in parallel. So therefore in our case that we had multiple devices mobile weapon. Room. We decided to have teams that were working on your front end and only or back in. Because otherwise if you think about cross-functional teams, we ended up with 15 people just on development side, without taking care about qas and everything.
Because the variety of languages and everything that we were working on, wouldn't allow us to have a smaller team. So if study, if we divided this by domain by Target, this could help us to achieve what we want to do. The way, how we take all that without having a first class. A citizen in one of the photon because potentially we could say, we have the back end developers together with the web developers and we can create a cross-functional team.
But in reality, web became the first class citizen because all the apis would be designed adopt for that. But in reality, we want to have a fair way to handle a cross-platform application. So you can work in both ways and I think apis are the key using techniques like back-end for front-end, or using graphql would allow you to decouple the to team. So if you are working with Once team says, they calling a child or cross-functional teams.
Either way, you can work with both also have want to extend this concept. Imagine that, for instance. You want to migrate your front end to microphone tense. But you need to remain with the monolithic code base on the back end, you can do in the same way as long as you work with a pi controller because at the end of the day, there is a nice separation between front-end and back-end. The apis are creating these loose. Couple Wars between the truth when we start with a very
tightly coupled words. Is where I start to be worried because then the evolution of either party could be compromised, speaking about different teams, different companies, these days, right? They are all in different situations. Some are still working on monolith either back-end and front-end, some are using single page, application back and for front-end and different devices,
and all that. When should we actually start thinking about microfinance is that turning point in a particular situation within the team or maybe challenges in terms of traffic or situational about the company? That we should stop thinking about micro front ends. Yeah. Absolutely. Let's start answering with one thing that I truly believe microphone tanks are not a silver bullet. I'm not here advocating that we should do by great.
Every workload make from tense because that's definitely is not suitable for many companies. I think there are some turning points where, for instance, you have large organizations with many teams that are working on the same code base. And you want to create independent teams that could work at their own piece. That is definitely the best case for or microphone tense. Another situation that I have
seen microphone tense working. Well, he's with multi-tier applications where for instance, you are offering as a service and you want to have multiple modules, you create similar infrastructure for all your customers, but at the end, you always have a part that you need to modularize. So therefore you can save it. Assume you have time microphone tens nine of them remain the same and one can be customizable
for specific customer. That is another thing that I have discover alongside this I have the fortune to interview and speak with people all over the world that are embracing this technique. That's also why I'm spending a lot of time advocating that in reality.
To be honest with you. I think in architecture, you always find trade-offs the recent best practices because best practices are based on the context and if you don't understand the context, you cannot replicate the best practice because it could work very well in one company but not in another. Therefore, in my opinion, microphone tents are a very interesting approach that we should work alongside. Go page.
Application Jam stack or server side rendering applications should be used with coaches because obviously is providing. Those are some pitfalls. You start to create multiple Ci City pipelines that you need to have a strong observability, a strategy behind that. So all the things that we have seen with micro services are also true core microphone times because the reality of the things is you have similar
things. You have distributed systems that have similar problems and see their benefits as well. Therefore, as long as your benefits into your specific. Are overcoming. The drawbacks definitely is a
good approach. But sometimes I saw people that currently are taking this wave of my contents and just using it is more a project and they are creating in my opinion, a lot of overhead for nothing because the reality, they won't be able to leverage the benefits provided by microphone tense because obviously the small team can achieve independence and
modularity. Also, we just good coding practices because encapsulation and everything that we have learned in the past with design patterns and Be applicable easily also, with two or three things working together in the
same code base. My contacts are moving that to the next level, especially when you have distributed teams, you want to reduce communication override across teams and you want to create independent teams, but obviously this has to be reflected also in the organization structure. So you the moment if you are using micro services and microphone 10th, you need also to decentralize the decision
making so the domain expert. Now the developers should take certain decisions and making certain code. East Side, certain boundaries, and the boundaries, usually are defined by that leadership, either platform team or Architects. Principal and so on, instead of dictating things, in my opinion, should enabling the teams to do their job properly, and they create the boundaries where they should operate, because they have a decent knowledge of the
big picture. Obviously, the other activity that those people should do is facing patterns that are happening inside the team. So, for instance, if a specific theme is solving a problem and that the architect of the tech leader, the principal knows that another team is facing similar problems. May be taking that pattern creating the opportunity for sharing and see if they can
reuse the same approach. I definitely could be a new activity that this kind of people should do because they should own the big picture and allow the team to make their own decision. Truly believe that the Box model where you build your own you run. It is the right way when you Embrace distributed systems, because otherwise, you create external bottlenecks that are basically frustrating the team and not allowing the company to
get. Main benefits of these architectures, you mentioned that you have met. A lot of people who try to implement this microphone stands apart from dozen who has done it properly. What are some of the maybe famous applications or systems around the world that I actually embracing microfinance? Yeah. Sure a publicly I can tell you there are quite a few companies that came out with that. So Ikea is the first one that using Edge side.
Include Salon do is another one. That is a fashion e-commerce and the de to implement. Creation of my contents and oppressors. The first one that Frameworks called Taylor JS. PayPal recently published quite a few post around that so if you're a user of people, definitely you're using Mac. So that's architecture. Same for American Express. They release an open source framework, all across, that is doing that. Other companies like Skyscanner is using them open table to a
certain extent. Also the Amazon Marketplace if you see the code, how is divided inside expecting the website? You can see there are some approaches similar to microphone 10th. Therefore at the moment many large organization has implemented that but also a smaller ones. We're looking for decentralisation of their organization and powering the team's because in reality those principles that we discussed so far are also affecting the engineering culture and
organization structure. Usually architecture goes hand in hand with that. We cannot forget about home with low. Therefore. We need to always bear in mind that our decisions are And not just technical but also affecting the organization, the communication flow between teens speaking about principles. And you mentioned early in the conversation that actually you borrow some of the microservice principles. Maybe for some people who are not familiar with micro service
and best practices. What are some of the principles that you took from micro services that are also good to implement in microfinance. Yeah. So using domain driven design, for understanding the bond context of your microphone test, at least one, the decentralization concepts and The strong one way of empowering the team. First of all, then another interesting one in my opinion, is a culture of automation, where microservices, especially nowadays with the rise of
serverless. Our business logic became reduced drastically. The cognitive load because our ways smaller the micro services that we are building, but at the same time you start to have a race instead on the operational side. So you need to create infrastructure as code. You need to create observability, monitoring logging tracing and Do the other stuff that goes around? So the same thing is happening
with microphone test. The moment that you Embrace this to be the system, you are going towards that, but I think microphone times are pretty new. If before we had the single page application. For instance. We had a binary situation where either your code is downloaded, or it's not loaded. The only thing that could fail is the backend now, especially on mobile website. You can have part of your application that is loaded and unloaded part. That is not.
And then I think this case we need to end, although situation. Gracefully, we cannot honestly, think about showing a 404 page because the user didn't download all the interface. So, we need to think about that. We need to also test these things because the reality is is not enough. Just relying on Frameworks. We need to have solid testing.
Strategies would allow us to make sure that when something happened to our application, everything would work anyway, and that's basically a few of the principles that I put together when I was working that, the other thing is trying, to be as technology agnostic as possible, because the moment that you have a very opinionated way, especially when you share code across, like from 10th, you may reach that, you are cornering yourself in an angle that would be complicated to get
away, and we require a lot of effort and maybe refactoring around code, the for being mindful of what you are sharing, what you are not sharing and sometimes thinking that duplication is not evil, sometimes could accelerate your team and add some speed because Angling dependencies We'll share dependencies across teams. Means that you are creating an external dependency for the team and maintaining that in the long run with tens of teams. It may be non-trivial.
So sometimes a bit of duplication doesn't hurt. Obviously. I'm not saying here that we should duplicate everything, but there are situation where you need to be pragmatic. And see that duplication is not going to affect the final result, too much. Speaking about technology, agnostic. I'm not very familiar with all this microphone and psychology. So if you allow me asking some basic fundamental, Fashion these days, take example, web Technologies.
People are using either like few JS react.js and all that. So when you say about technology, agnostic do you mean that we should not base our microphone and architecture using fundamental Frameworks like that, or is it something different? It's a slightly different point of view. So definitely you can use those Frameworks. It's very important obviously, for speeding up the development and it helps you to achieve your
goals. When I talk about technology, agnostic is when you have key point of your architecture, trying Help the team basically to don't close them self in a specific route. I don't have a very opinionated way, just to give you an example. Imagine that one of the main challenge when you deal with Mike from the answer is creating a UI consistency design system. Definitely fit inside the micro service vehicle from times
world. Now, for that, what I recommend more often than not is using web components, because web components are a technology agnostic. You can use them either that you're using view JS or angular or whatever. It's not a problem at all. So yes, maybe is an effort or for learning if you're not familiar with them, but in reality in the long run, you are creating a design system that can be reused in the future.
Despite. The turning point that the company will have in the business will have the for if today you have angular and tomorrow, you are moving to a newer version of angular or another framework. You won't have any problem because you can reuse the design
system. I would say and argue that could be different in the case that you start to have a design system for view because you're using View, and then you To another frame or a new different version of you and we require you to change everything that definitely would be additional effort that you want to do. When we did the zone. For instance. One thing that we did was how to load every Mac front end, inside. This thing called application shell.
Basically is the initial point where you have for the entire user session, this application. Shall what it does is parsing HTML page and appending the nodes that are related to a microphone that inside. As you can see here. We are not using Anything that was dedicated to react or view or angular. We're using web standards because we didn't want to preclude our self in the future from changing technology or anything.
So as long as you got a framework that is outputting HTML and JavaScript and potentially CSS is called work. It's not going to create any issue. So, that's the point where I think we need to be mindful and trying to beat the current diagnostic. There are other stuff that obviously doesn't make any sense. It's through is fine.
Using a specific framework. Especially when you're creating some views or other stuff, but for these kind of things, I believe it's kind of important that when you Stitch the things together and you share code trying to be as honest as possible. And sometimes you won't be able to do that because the context doesn't allow you to do that. And that's fine because this trade-off you optimize for your contest. You're not optimizing for the world. Speaking about the app shell.
I'm very interested in this concept because it's like a container, at the end of the day, right? It's like the starting point where the view will be stitched together and I That if you have a lot of microphones, maybe that say you have a user information, you have shopping confirmation or that all these different HTML fragments can be generated using different libraries, different dependencies, maybe different
Frameworks internally. How do you ensure that the app shell actually can make sure that everyone can work together without having some Clash? Or some kind of broken dependencies and things like that. Yeah, that's a good point. So currently there are Frameworks that helps you. The latest framers are helping you to achieve that for me. Some now, thinking module Federation with web Park that literally this week was announced also be implemented also in es build.
So it would be not only on web part that makes available lighter version of roll up. So it's getting a lot of traction and it will be exactly this problem. So you can use the technology you want. They take care about wrapping the scope of your dependencies. You can even share dependencies inside your system and everything is nicely handled by the motive Federation, plug-in that is available. When web talk about in the future right now, they're building systems.
That is Prince. One way, in our case. It was more coordination because obviously as you said, we have HTML fragments and we load one microscope a time. So we don't have clashes between teams for sure. If we have to do that you have different ways to do this. For instance. I know recipes, using framework or Luigi framework. That is based on iframes and then you wrap everything on an iPhone.
I know that many people could start to scream because I said the magic word iframe this Most effective sandbox that we got our web browser. So I know that maybe Is Not Great to use that for certain use cases, but if you think about the use case of software, you are an Enterprise environment, you are in B2B system, not be to see, extracting data from sub can be non-trivial.
So having a decent interface framework that handles with one or two iframes in the view, the final outcome for the users is probably less than a problem. Also, they can control the environment where they work is not a similar environment. So, overall I think, Think it could be a natural choice for and Link potential memory leaks and for angling strong boundaries between microphone test.
There is currently tc39. There is a proposal for one thing called basically would be a lighter iframes. If you want where the iframe is copying, the entire Dome object, with window. We arm will be lighter, but it's creating the sandbox of whatever content is there. Obviously, stealing second draft. So there is still a long time before we see them in JavaScript, if they come but they Idea sounds very appealing, and that could be a good fit for my current density.
Meanwhile, I would say, module Federation is a place where I would recommend to look at mainly because if you're familiar with web pocket, the developer experience became extremely familiar and simple for any developer to start with. There are other framework like single SP a another great framework in my opinion that solve similar problems in different ways and you can also mix and match with what federation. But in general.
I would say trying to understand your Context of what kind of problems you are solving before you pick a framework because it's not as simple as saying. Oh, I pick react if we can grow because I'm a fan of it. But let's try to understand what kind of problems you are solving. And how it's going to impact in your context. Speaking about building a system that has microfinance. I'm speaking in terms of continuous delivery, continuous
integration. How do you actually assemble this build and deployment pipeline? Do you actually create multiple artifacts for different microphones? And then you have another pipeline? Actually stitch them together. How does it work? Actually? Yeah, so usually what you do is creating multiple pipelines, 1 / microphone tent and then the stitching depends which composition you decide to have all my contacts. You can have a server-side composition. You can have an edge side composition.
You can have a client-side composition in the case of the client-side composition. We have the application shell. That is basically lazy loading, the different microphone pants. Usually you have a container that is loaded and knows how to display the Intense inside it. An example is much Federation is like that or single SK are doing this for Edge side. Composition. There is a language college
side. Include was released several years ago, a bunch of companies including Akamai and Oracle that created these markup language. Yes, I what it does is basically leveraging. The transclusion concept where you have a placeholder that is replaced by a microphone stand at the edge in this case is happening everything at the CDN. So great for static content. You can also use nginx. And varnish the problem that you have in all of these approach is
that the ASI. Markup language is not supported everywhere with the full specification. Therefore Akamai is the only one that is allowing to do that. And when you have Dynamic content, you need to supplement these with client-side, include that basically is the same Constable transclusion, but is happening on the client side, the developer experience is so so.
And you cannot definitely afford more TCT and strategy with that on the server side is that you basically have some potential templates that you will be. She hosts and you filled with data and then you server-side rendering everything on the client or you can use what is called isomorphic or Universal architecture, where you are basically having some code that is running on the server and on the client for dynamic content, for instance, and you can mix and match certain of those
options. In my opinion. It really depends what you need to achieve. If you want to have strong SEO, probably you're going with the server-side rendering approach and there are for instance, some interesting twists there. I know that also next JS is do.
Into module Federation and spread because it means that we are basically starting to get even more traction, with my phone tents, and the moment that you see ecosystem like web Park and so on, it means that really we were able to show the benefit that these approach could take. Now. The difficult part is understanding where the boundaries are in my opinion, but it would be fun to see the next few years speaking about implementing it correctly.
So what are some common challenges or anti patterns or pitfalls that you I've seen from the practice worldwide because you have spoken with many people. Yeah, many developers, when they have multiple microphone times in the same view and they need to communicate together.
The first thing that they think about is having a global State and that is 70 and 90 pattern because the moment that you have a global State causing coupling only on the code wise, but also the organization side, let's imagine we have three teams, working, three different microphone tents with the global State and you are basically creating design time coupling.
Because what you do is I need to add a new property, my Global state or I need to change a global State and then I need to coordinate and test or the other microphone that moreover. If you have a back-end team that is working on some apis and you consume multiple them and they change the contract.
Now you need to make sure that not only that the new Hunter is working but also that I would the other microphone pants are working and therefore, you are creating more communication overhead and you need to get it together with the teams and make sure nothing is working. And he said if you keep the state in, Inside the wreck front end and you implement a pub sub pattern. Where the communication is happening through. Am even Demeter or custom events or signal library, or reactive stream.
So you're basically decoupling go system where the only thing that you are exchanging is a contour the for an event. You are the coupling first of all the team.
So as long as you respect, you know, what are the input of your microphone dance and the output of your microphone that everyone can plug without even bothering the team that is developing the microphone dance but moreover in an evolutionary The architectural point of view you start to add you microphone tense in the same view and they just check. What are the events at the other are bubbling around and just
plug themselves. And if you think about that is the same difference between orchestration versus choreography. We need the microservices word. So you are trying to decouple that in that has a knockout effect. Also on the team organization where you maintain the boundaries of the team's, the team can work at their own speed testing and everything will be simplified. That is first of all, one of the
anti partner. I've seen the other thing that I have seen that the effective in my opinion, may be classified as an anti-pattern is having multiple Technologies in the same application. Many people are thinking. Oh, yeah, Mike from towns are a way to use View and angular and react, all together with Stitch all together. And off you go, you have your application, but what is important in single page application server side, rendering application, the performances are key.
Especially because now we saw a raise of the users that are consuming our content on mobile devices, that Or 4G connection 5G now or 3g connection. Even we need to be mindful of performance. My suggestion is Define. What are the boundaries? So the team can work with react 16 or 17 wrecked, 18, angular, whatever, version doesn't matter, but try to stick with the same thing. If there is a situation where having for a certain period of time multiple Frameworks can be helpful, it happen.
Those to us when we was working the Zone where we applied a Strangler pattern for microphones. And so we developed the first one, we push in production and that was living alongside with our single page application. Why that? Because we want to create an identity of mindset for developers where they start to push their coding production, not being in fear of having changes in production and then create the mechanism around that
for creating the confidence. So fast, see ICD creating Connery releases, so you can shape the traffic on when things are going toward Legacy application, and potentially the possibility to switch all the traffic to the Legacy application. That, you know, this could work. The 40s kind of mechanism created the confidence for developers to move faster in their development experience and also gaining real data and data points to compare and apply to
improve their microphone. That feed that is invaluable because the moment that you are capable to do this, you create the a flywheel that will allow developers to learn and be confident and create more code than the be faster in the release. At the end of the day. We saw that we move from few development per month, to tens
of development per month. Just because of It's because the developers has the possibility in a matter of seconds to turn off all the traffic or reduce the traffic on specific browsers or specific devices. And that for me was fantastic because basically we achieved after a long time one of the main goals that we had with this approach. So thanks for sharing the tips. For example, you start with small thing, right? Gain confidence, build the
flywheel, iterative mindset. So any other tips for people who are sold into this idea. Okay, microphone, and let's start it because for example, in microservice world breaking up Manolis, it's also not a easy thing. You would start probably by identifying seems or fracture planes or maybe Strangler pattern. What are some of the tips that you can give for people who want to try this on their monolith front end so to speak. So let's assume that a theme or company.
Finally, decide that microphone tenses, the right architecture for them because that is the first thing I would say, first, understand if you really can provide the benefits to your organization, but secondly, I would say if you identified, my contents can be helpful. Start with a nice session in front of the Whiteboard or digital whiteboard nowadays, where you are basically defining, what are your domains as trying to understand how they fit with the current
organization. If you need to make changes when you identified one, trying to take one vertical, one boundary that will allow you to test your assumptions. It doesn't have to be the most complex one and I would recommend not taking one with new features because otherwise there are too many. No moving Parts. I preferred starting with something. That is Consolidated. This they are you know, how it works. Deeply, you are a domain expert. You already developing another way.
So take that start small and create everything end-to-end and trust me. You're not going to have the perfect solution a first time but you will learn a lot during the journey and when you have done that share the knowledge back to the company and start to have contribution for other people and then when you have that, you continue this approach and start to improve slowly but steady one thing that I recommend And especially the beginning is having enough
bandwidth and keeping your backlog. A bit of time for reviewing the CI CD because that at the beginning, we will potentially slow you down. So you need to refine a string line, the key points, and definitely the team should be empowered to change its own CI CD because in reality, you need to build it only your code. The moment that you don't know how to build it how to operate, it is impossible to, you can maintain that code.
So it's very important also microphone 10th from the learning of We had on microservices that the team is responsible for that. If we do these I think they can start to achieve some great result in short iterations and then continue constantly to do that and accelerate as fast as you can because that would be contagious. Everyone would like to do that and when they see the benefit of it, the see that they are independent, they don't have to coordinate any more and they can deployed.
A small portion of their business logic without retesting the direct creation. Then I think we would be in a position where you start to see the If you took this approach Luka, you also wrote a book about microfinance, right? The title is building micro front ends. So, can you share a little bit about the book? What can people expect by reading the book? Yeah. Absolutely. So the book currently is in early release on the O'Reilly website. They will be ready by Q4 this
year. The book basically is a work of two years of my life where I not only learn a lot with the Zone, but I deliberately spend time talking with people and The standing there challenges and see if my thought process was applicable in other context, because in reality doesn't was one context. Obviously at the world is way more complex than having just one. I saw a lot of benefit I change and twist my thought.
Process several times. I have seen people applying what I was suggesting and being successful. Therefore if you expect a book where you find tons of code on how to implement different framework, is exactly what you want. Find inside. My book, what I'm sharing. More an approach for building. Mike, front-ends and learning the thought process.
Because when you learn that, if tomorrow, there is a new technology, you don't have to relearn the basics, you know, how to apply the core concept and that use. I was very inspired by some human book on building microservices. And I try to keep exactly a similar approach where you were more on the code side. Obviously up. There are some code snippet. There is a chapter where I showed implementation of a
microphone tense. A couple of different implementation, but the idea is talking about organization structure, how to sell my contents inside the company, how to migrate a monolith to microphone tense. What are the challenges were going to face how to integrate with back-end and showing different patterns to do that? The principles behind microphone tense and how to use them across
the entire time steps. And also, there is a chapter and finishing right now, that is a comparison of all the different microphone 10th approaches client-side server, side edge side, and the challenges that you He's in all of them. Basically, this two years for me was extremely helpful because I was able to see different companies approaching the
challenge that they face. I was able to speak with several conferences and sharing what I have learned and a different approach and talking with people that are doing microphone test before potentially longer than me and see their point of view and see how I was approaching similar problems in different angles. I think I'm very proud of that. That many of the thought that I shared, I create a mental model
for approaching. My contents called the decision framework that I saw the booze embracing several talks and by the community widely. Therefore, I'm very proud of this contribution, because obviously it's not easy creating a new architecture, nowadays because we have a lot of architectures out there that are not changing very often.
It's not like a frame of that. You just release a new framework and that reduction is there for sticking and creating the foundation for that is extremely complex seen. That these specific chunk of work that they have done. That basically is the result of six years of Work stick very well inside the community and was widely used and made me very proud of the Journey of Dawn. And makes me think that the thing that I'm reversing inside the book, that would be more
than 300 pages. Long will contain the size that the community is looking for sounds, very exciting. I'm looking forward to reading the book in queue for everyone who are really interested in learning more about micro front ends, the architecture, the decision Frameworks and things like that. Make sure to check that out. So Luca is been a pleasure talking to you. I have one last question. For my guests normally, which is to talk about your tree technical leadership.
Wisdom. Would you mind sharing some of the wisdom that you have learned from your career Journey? Absolutely. So one thing that many people are not familiar with, but for me was a key turning point in my career. I was reading a book called The Spirit of casein in Japanese. Kaizen means continuous Improvement. This is the practice that you
can apply your daily life. But also it can be applicable on your day-to-day work for me. It was fantastic because understanding We'd small things, you can really achieve great results. Have me to shape My Mind. Set an example for these, maybe seems very simple. But for me was extremely powerful. I started to read during commute time a chapter per day, and at the end of the year, you end up reading 20 books. So yes, it's literally 20 30 minutes of reading.
But is, every day is constant. You're creating a habit and at the end of the day, you have a big result and the same thing. I started to apply an everything I'm doing. So for instance. If I know that I have a large commitment, I start to break my commitment in small fixed.
Then they know that maybe, sometimes there are bitter pills that I don't want to take, but I have to therefore, if I'm able to split them in, multiple days and taking meaningful stuff to see a progress of what I'm doing. Definitely the end of the day, we see great result and these are also the same way how I take all my books. This one is the second book that I'm writing.
I started dividing chapters and that paragraphs, the try to take all small things because at the end of the day, I see that the end of the month of 40 pages because every day I wrote a small part that is the first one. The other thing is engaging with the community. Don't be afraid to speak with people. It doesn't matter the role. It doesn't matter what religion that they are. The reality is.
You can always learn from them because maybe they have an angle of the same thing that you are convinced is right in your head that you didn't explore for me. I've been having this open mind on approaching everyone and listening deeply on their point of view. It's extremely powerful because cuz then you gain a new inside your head and you start to elaborate that maybe you don't use tomorrow.
Maybe know you won't use this year if you using three years time, but your brain will pick it up and I would be extremely powerful. The last thing that I would say, I keep back to the community. That's how I greet. You, personally, I said, I myself thought person. Therefore what I did was learning from others and sharing back to others, and I think that was one of the coolest thing that I have ever done in my life. I constantly Do that try to write blog posts to record
videos. I try to do talks, not because I'm interesting about the name of because I have this forever tapped with the community that I try to feel it. Somehow all the time spending outside. My job doing external activities is more for trying to feel that because if it wasn't for the community, I wouldn't be in the place where I am right now and therefore I won't the next person that is trying to take this path will have a smoother path than I had back in the days.
Thanks for sharing. The wisdom. Speaking about giving back to community. Again. Thanks for being part of this podcast. So Luca, if people want to know more about you, they want to discuss about micro front ends, or maybe your book. Is there a place where they can reach you online. Absolutely. So LinkedIn or Twitter. I'm extremely active in both of them. So, feel free to add me. My first name surname in both of them?
So you can find me very quickly overall, if you search online or especially on YouTube, you find tons of books that they have done on that. So feel free to reach me out anytime. As you can see, I'm a very approachable person. I definitely reply to everyone.
There are a lot of nice stories that happen after opening to the community and say yes to everything that obviously we don't have time to tell, but I can tell you, that is extremely cool and therefore, feel free to reach me out anytime. I'm more than happy to answer all your questions. Thanks again. Look at. So it's really nice to have a chat with you. I wish you good luck with the book. Thank you very and have a nice day. Thank you for listening to this episode and for staying right
till the end. If you highly enjoyed, please share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you're new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It really really helps me a lot in order to grow this podcast better. You can also find the full show notes of this conversation on the episode page at technology.
Know the death website including The full transcript, interesting quotes and links to the resources and mentions from the conversation. And lastly, make sure to subscribe to the shows mailing list on package, you know, the deaf to get notified for any future episodes. Stay tuned for the next technique Journal episode. And until then. Goodbye.