Loosely Coupled - Interoperability in Micro-frontends

Good morning, good afternoon, and good evening, everybody, and welcome to another episode of Loosely Coupled by Bridging the Gap.

My name is Karol Skrzymowski, and I'll be your host tonight.

Hopefully, all of you have a lovely cup of something to drink for this session.

I don't know if you noticed, if you're coming back to the stream, maybe you have, but we actually have a jingle today.

That's made by my co-researcher at Bridging the Gap, Filip Kostyra.

Thank you, Filip, for that.

It's a work in progress, but it's already pretty nice.

Filip doesn't want to say that this is a ready thing.

He said he'll work on it in January, so maybe there will be a different version, maybe a longer one.

But that's not the topic for today.

This is actually the last stream this year, and here today, we have a lovely topic of interoperability, so actually something we do at Bridging the Gap, and today, a different angle.

We're going to be talking about interoperability in front-ends, and specifically micro front-ends.

Who better to talk about interoperability in micro front-ends than the author of the book Building Micro Front-ends, Luca Mezzalira.

Luca, welcome to the show.

Hi, everyone.

Thank you for the invite, Karol.

Happy to have you.

Luca, you've been at it for the last, what, 21 years?

Yeah.

Doing IT stuff, architecture, and whatnot?

Yes, more or less, I think 24 in January.

24?

Whoa, okay.

24 in January.

Wow.

You wrote me in the bio since 2004, so I'm like, 21 years since I've been here.

No, I did also something before that.

Ah, so that's in architecture.

If we want to start on the very beginning, yes.

2004 was the first line of code, if you want, but I did also some stuff before that.

Fair enough, fair enough.

Luca, micro front-ends, how old is this topic?

Because you've been at it for a while already.

Yeah, I'm ranting about micro front-ends for almost 10 years.

So next year, if I remember well, is in May.

That will be the first decade of the term micro front-ends that was coined by ThoughtWorks.

One of the developers in ThoughtWorks came up with this idea, Mr. Jackson, if I remember correctly.

And then it was advertised inside the tech radar that they usually do twice per year.

It was the first half of the year, if I remember correctly.

Therefore, I started before this term was coined in 2015, thinking about micro front-ends and how I can apply the principle behind microservices in a way that makes sense for front-ends.

And then suddenly in 2016, we started the development.

It took me a good amount of time having the buy-in inside the company.

Because as you can imagine, if you go to a CTO and you say, OK, we are going to do this in this architecture.

And the question, how many companies are doing that?

And the answer was probably one or two in the world.

It wasn't, let's say, the most sustainable things that you can say to a CTO.

So we need to prove that.

So I had a team of a few engineers that work with me in order to create a POC that would show how we solve the challenges we were facing in our monolith.

And that basically was the beginning of the story of micro front-ends.

I mean, 2015 in Poland at that time, I think people barely heard about virtualisation.

They started hearing.

I remember going to a session with Microsoft somewhere in Warsaw.

They were showing off their Hyper-V servers.

That was the pinnacle of virtualisation back then.

In T-Mobile, we were still running some servers on bare metal.

But these were just huge monolithic servers in that sense.

So we had like separate servers to have higher availability.

So that's quite a long run already.

Yes.

Ten years.

Yeah, you started early, basically.

I started for a necessity.

The problem that I had to solve back in the days was being part of a startup that turned out to be a unicorn based in London.

And we moved from 50 people to 3,500 in something like a couple of years.

Because the challenge was we worked with a lot of partners.

The first iteration was working with partners.

I was working for one of the partners.

And I followed basically the integration with different tools that we were using.

Because we were the company responsible for the front-end as well as the middleware that was aggregating all the data and generating also other data.

And then after that, after the first release, I've been asked if I would be interested to join this company that I was working for.

And the answer for me was like, yes, without any doubt.

Because the idea was scaling the way how we were doing the first release of the software.

But most importantly, revolutionised the way how people were consuming the sport.

And at the time, Netflix was starting to boom properly.

And if you think about that, it was like a perfect storm where you have like sport that you don't have to explain to anyone what sport means.

And you have like streaming, on-demand streaming that was starting to grow.

And I found myself in a situation where I was the second tech person hired in that company.

And they told me, okay, now we need to internalise all the things that we have done with partners.

So we need to create all the hiring process, all the architecture, all the team structure, all the engineering practises and so on.

And I was basically the second person that had a lot of say on all these topics and looking holistically on the social technical system that we were building.

And we started to introduce things way before certain things came out.

Like the idea of team topologies, for instance, was something that the book came out in 2019.

We were doing that in 2017 internally.

We didn't have a name.

We were just, let's say, leveraging domain-driven design for splitting up, let's say, our application, find the boundaries and subdomains.

And then co-locating, because it was pre-pandemic, co-locating the people working on the same subdomain in the same hub.

Because we have four different hubs.

There's one in Poland, in Katowice, one in Amsterdam, one in Leeds, and one in London.

And basically aggregated these subdomains in a way that the worst-case scenario, you solve the problem with a person that is like 10 feet from your desk and not on a one-hour difference or in another city or even in another country.

So therefore, that idea accelerated basically the storming and forming of the teams.

And also, we know upfront that in order to solve the problem of, let's say, communication across different hubs, it was just working properly with the API contract first and having, let's say, strong governance around, I need to change an API, perfect, write an RFC and start working to that.

So we started to create a lot of practises that I recognise nowadays that I'm in AWS, that many companies currently are still at the beginning of the journey that they did, let's say, almost 10 years ago.

So it's very interesting because it seems that we were extremely futuristic to a certain extent.

I'm pretty sure other companies have done what we have done at the time.

But for many enterprises I'm dealing with right now, a lot of learnings that I have went through over the past decade are definitely helpful for them to, let's say, embrace this new world of modernised software, modernised architecture.

Now, okay, that's a handful.

I'm like sitting there, it's like the light bulbs switching on in my head.

Okay, Conway's Law, team topologies, cognitive load, so many of those topics.

There's so much to unpack here.

So basically you were at the forefront of developing new approaches in tech and then actually have practical experience when they already were named and went out with specific names.

So you already have experience in dealing with that in practise.

Yeah.

That's a rare thing.

It was because it was, you know, the cool thing for me was I was, let's say, a person that loves to work in bleeding edge context, where things you don't know if they are going to work or not.

Because we need to bear in mind that in 2015, when we launched the first release of the zone, there wasn't this idea of live sports streaming.

Many people were telling us there is no way you can succeed.

No one did that before.

There is the cable providers.

That is the normal way how to consume sport back in the days from Sky and many others where the way how people were consuming, they were working perfectly fine.

We believe that we can democratise even further sport and reduce the cost.

And in fact, the first few years, the cost of our subscription was less than 10 euros per month.

And you can consume everything that was available in your country.

Obviously, we started with four countries.

The first release was Japan and DAC, that basically is Germany, Austria and Switzerland.

And in Japan, for instance, we acquired for 10 years exclusive rights for the J-League, that is the football or soccer for our friends in America.

That leagues for what we put like the first one, second one and the third one.

And after that, in 18 months, we became almost the only sport broadcaster.

The only thing we didn't have was sumo.

But we had everything else.

We brought, let's say, all the other sports from U.S., a lot of sports from Europe, the Champions League and all the other things.

So it became extremely popular in Japan.

And I remember when I was working there, because obviously I was used, let's say, more or less in every single launch, staying in the war rooms and seeing how the things were panning out from our first Datadog and the New Relic dashboards.

Quite fun.

But I've seen, let's say, the power of these things.

If you were, let's say, walking through Shibuya, that was one of the key areas of Tokyo.

In the Shibuya station, the station was completely packed with our advertising.

You can see, let's say, our brand everywhere.

When we launched in Italy, in Milan, we have near the San Siro stadium, that is the AC Milan stadium.

That was like, the stadium was called the Zone Stop.

So it was like, we started to grow like crazy.

And obviously the way how we were designing things and implementing things at the piece that we were doing everything was quite monumental.

At the end of the day, after a couple of years, we reached like 550 techies across the tech department spreading for dev centres.

That's a lot.

That's a lot of stuff in a very short period of time then.

So not only were you at the forefront of developing new approaches, you also had the organisational challenges of extremely fast growing company.

Which I can imagine that was for some people, not all of them, but for some people that must have been extremely stressful to get through that.

The growing pains of a company growing that fast, this can be really great or can be really, really tragic for certain companies if they don't adapt and adopt in a very fast manner.

I think our strength was, let's say, trying different things, analyse what we were doing and see where we were failing and adapt as soon as fast as possible.

And I found myself having, let's say, every other week a brand new team of beginning contractors then replaced with internals to onboard these teams every other week, explaining the architecture, explaining what we were trying to do and all the other things.

And that's why back in the days, because we had to support, the idea was supporting roughly 40 different targets on the front end.

So set-top boxes and living room devices or console, web, mobile.

So if you start to put everything together across the world, you have devices that were as powerful as a Nokia phone back in the days that were set-top boxes.

But the penetration of a set-top box or a smart TV is by far larger than the newest one.

Because if you think about how often we change the TV or set-top box, it's not happening very often.

So there were devices that were quite obsolete technologically speaking, but in order to make them cheap, they didn't have an amazing chipset or crazy codec or whatever.

You need to adapt yourself in the way that the things that you want to, you need to develop.

Therefore, also one of the ideas behind Micron Tenths was, that was also one of the key aspects, is trying to reduce and optimise the memory management in JavaScript.

Not loading everything in one go like you could do with a single page application.

And therefore, lazy loading, what is needed, when was needed.

And I think we did a pretty good job overall on doing that.

And that basically not only enabled the performance, but enables us to have teams that were working independently.

Because now with the good segregation of concern and division about domains, we were capable to say, okay, so this team is responsible for this part and that team is responsible for that part.

We had to iterate for more or less a year and a half to figure out the right split.

And understanding and fixing all the different problems.

Because obviously, as you can imagine, because it was so novel, this approach, there wasn't documentation.

There weren't, let's say, any book that could tell you, oh, this is the way you should do.

Or someone that you can say, oh, let's call a consultant to help us to do this.

Completely.

So all the meetings that they organised with 10, 15 developers for trying to analyse the problem, trying to see the patterns we can apply, trying to see what fit, what didn't.

After, let's say, a couple of years when we started to launch on the web first, I thought that we were sitting in something extremely interesting.

Because it was a journey of two years gathering feedback from different developers, from junior to senior and principal, etc.

And then I remember the first talk very vividly that I did in Dublin, where I went on purpose and the conference was not too big, but was big enough with hundreds of people.

They gave me like 35 minutes for delivering the talk.

And I spent roughly four hours answering questions after.

It was like I couldn't have lunch because people literally assault me on asking, OK, how do you manage the design system?

How do you do this?

How do you do that?

And it was extremely funny on one side and extremely rewarding on the other side.

Because, you know, we work for something that probably no one has explored at that depth like we did.

And then suddenly there is an interest that is out, but all companies that were huge compared to what we were at back in the days.

And so for me, it was a great reward and great moment overall, despite there were other lows later on during the journey.

But, you know, here we are.

We have the same microphone that is used everywhere from all the enterprise, largest enterprise in the world probably are using some shape or form of microphone.

Well, now, luckily, we have people that actually specialise in microfrontends.

There is some reference to go with.

So one of the reference here on screen, that's Lucas' book, Building Microfrontends, second edition.

That's very fresh, right?

That was this year?

Yes.

So it was released in early November 2025.

And the cool thing is that basically it was a complete rewrite.

I kept like half of the book and update every single chapter with the latest and greatest.

But then I basically gather all the feedback from the first edition where they were asking, can you share more code?

Can you do more of this?

Can you do more of that?

And then gathering the thing that shift basically the gear between the first and second edition is that I joined AWS right after I publish almost the first edition.

I was about to publish.

I wait a few months more for gathering more information.

But since then, basically the last five years in AWS, I work with hundreds of teams, internal teams from Amazon, AWS, etc.

And customers from Silicon Valley to New Zealand in different industries, finance, entertainment, retailers, etc., healthcare.

And we started to, I started to collect all the patterns that I was seeing and mistakes that were happening in the trenches.

But I think that was, let's say, a great effort for the community because what I was thinking is, okay, let's validate what we wrote in the first edition.

And let's add other new approaches that were surfacing there and generating the vocabulary like I did in the first edition.

Because the vocabulary, as you know, naming convention and ideas that you need to convey require a certain type of language.

So for me, you know, now I'm working certain engagement with customers where they are talking the language that I created back in the days.

That is insane on one side, but it's extremely helpful because everyone is on the same page.

And that doesn't matter if they are in the UK, in the US or in New Zealand.

We will talk exactly the same thing.

So we are on the same page.

We start to discuss what kind of challenges they have.

It's a completely different way.

And I have to say, one day I will document properly how to create a vocabulary for an architecture.

Because I realised that there is a lot of thought process behind that and why certain things were described and designed in a certain way.

And, you know, after 10 years, I have a lot of data points that I can say, okay, I can identify what are anti-patterns and what are patterns that you should embrace.

And how the influence of other architectures helped me to reach the maturity level that we have currently.

You said a word that triggers me into asking.

Because I did plenty of research in terms of patterns and anti-patterns.

When I was designing a course on integration architecture some time ago, I struggled with finding a decent definition of an anti-pattern.

What's your definition of an anti-pattern?

So it's the opposite of a pattern.

What I would define is an approach that when taken, it will generate more friction than benefit for a company.

It doesn't mean that it will always generate that friction, but it's likely to generate friction.

There is this concept that I truly believe in where a pattern is a solution for a common problem.

But not always you want to embrace best practises or patterns or you want to embrace anti-patterns sometimes.

Because the reality is, and that is me becoming more mature and having more experience and more years under my belt.

The fact that in the past as a developer, you are dogmatic.

You say, okay, this is MVC.

You implement MVC by the book.

You implemented the pattern by the book.

And if someone is trying to convince you that this is a bad way to implement a specific part, you say, oh, no, no, but you don't understand.

Because in reality, this is a part that is documented here, the Gang of Four, so see it.

And now instead, I'm more into the trade-off analysis like Neil Ford and Mark Richard recommends.

Okay, so let's try first to analyse what we need to express inside the system or inside the future.

And then after that, when I have like the business capabilities crystal and clear in my head, I have the architecture characteristics.

I hate non-functional requirements, so don't ask me to say that.

I subscribe to that.

Architecture characteristics that I need to express inside the system because some of them I need to apply across the entire system.

Some of them I need to apply maybe in a specific domain, generic or core or supporting.

And therefore, if you start to work in this way, you start to have, let's say, clarity of what you can and what you cannot do at least.

And then you can challenge, obviously, this specific implementation because maybe it's a snowflake or maybe you discover that it's not.

But unless you start to have, let's say, a conversation that you first understand these two layers, basically as business and what architecture would like to see.

For obvious reasons, sometimes you're working in regulated environment or industry.

Sometimes it's, let's say, something that is a decision made by the company or by the CTO for maintaining high availability.

So these kind of things matters and affect your design.

And therefore, for me, when I have those, I can start to drill down into, okay, now that we know this and we know the specs, we know what we need to aim, we should for, okay, how we design this thing.

This is one thing that I believe now we are losing because we are rushing towards the implementation phase due to time commitments that are not, let's say, managed by us.

But I believe that the architects that are still useful should enable teams to, let's say, reframe these things in a way that they will enable to quickly have this information, key business characteristics, key architecture characteristics in a digestible way.

And they can, let's say, incorporate in their design when time comes.

So for those not having the frame of reference for all the terms that Luca just used, which are the terms we've been using on this live stream for quite a while already, because I do subscribe to all the terms described by Mark Richards and Neil Ford.

I absolutely love their rhetoric around building architecture and doing trade-off analysis.

But while you were describing this, I took the liberty of grabbing some links from O'Reilly.

So if you need a reference to all those lovely terms that Luca just mentioned, Head First Software Architecture is a great book to start with.

Very light read with exercises, with lots of fun for the brain.

And if you need more of a concrete read than Fundamentals of Software Architecture, the second edition was also published this year, earlier in the year, as far as I remember.

O'Reilly says March 2025.

So these are really great books to find all the definitions of the terms around architectural characteristics, doing trade-off analysis, looking at all the different factors that come into the design of your architecture so that it actually is fit for purpose rather than art.

Exactly.

So that's the biggest value.

Being dogmatic, I was dogmatic as well.

I used to have that approach a few years back.

Learned the hard way that being dogmatic is not exactly the best approach because at a certain point with one of my clients, I actually looked at it and it's like, oh, this will completely not fit the case.

And I've been proposing that.

It's like, no, that's just going to be a huge failure.

Luckily, realised on the design phase, not in implementation.

But basically, after that, I started looking more into trade-off analysis and actually analysing the context and spending more time in the problem space, analysing what the main problem is, and then diving into details of design and picking the right tools for the job.

And while your short answer for the anti-pattern, I was instantly like, oh, no.

And then you elaborated on that.

And I was like, oh, yes, exactly.

I'm joking with Mark a bit.

Mark actually introduced a third term to the mix.

Pattern, anti-pattern, and a pitfall.

So now we have pattern, which is a common solution for a common problem.

Anti-pattern, which is something that usually leads to problems when misused.

But it's also a pattern.

So it also solves some problems in a very specific context, niche context, usually.

And then pitfall is something that is definitely not wise to do.

So that's their classification of different aspects.

And that goes on all levels of abstraction.

There are patterns and anti-patterns everywhere.

I have my own specific integration patterns and anti-patterns and pitfalls.

Always a fun discussion.

But not today.

So having all that amazing background, because that's been quite an interesting story.

Maybe we should dive into those frontends.

So starting with what are micro frontends?

Because that's the interesting definition then, after 10 years of working with them.

Let me more than just sharing the core definition.

Let's say walking through my reasoning when back in the days I started to think about that.

So the idea was very simple.

On the backend, we knew exactly what to do.

So we knew that we needed a distributed system.

At the time, cell-based architecture was still fuzzy, very far, far away.

And we were just starting.

It didn't make any sense using a cell-based architecture.

But a microservice one definitely made sense.

Because we were moving from a monolith to this distributed system with a lot of engineers.

So when I started to think about what characteristics should I apply on the frontend, the majority of the time and all the different implementations I've done in the past were in a monolithic space where literally you start with all the good intentions.

You start to scale the teams, because usually you start with one team, start to build a small POC, then start to grow.

And slowly but steadily you have five teams, six teams, whatever.

When we were working on this specific project, we were roughly 40, 50 people end-to-end in my previous company.

And we were working with a monolith in the front and a monolith on the back.

At some point, the problem we were facing is, A, and that's something I've seen in other companies when I was working as tech lead, A, we started to slow down with new features implementation, because now the code is larger and more complicated.

People were stretched a lot.

When you were on call, you needed to take care about, I don't know, sign-in, as well as payment, as well as catalogue, as well as any other part of the application.

And you cannot squeeze everything inside your head.

So the cognitive load that we were discussing at the beginning.

The other challenge is that because there were some features that were easy to implement, we couldn't deploy them quickly because we need to retest due to, let's say, issues that happen or bugs that were happening when we started to build stuff and deploy stuff.

We were more careful on what we wanted to deploy.

So there were more tests, either automation or with manual QAs.

And so if you start to put everything together, you see that there is an inherited complexity when you reach a certain point, not on the code side that I would say in every company I work for, there are some times that you have spaghetti code.

But majority of the time, you have, let's say, people that really care about their craft and they want to do the best, and that's why it takes longer, but also helps to optimise certain things that could be refactoring on performance and that stuff.

But the problem we had is now we have a completely different ballpark.

We know up front that we are going to scale.

We know up front that we need some teams that are going to take into account different domains.

Therefore, it was stupid for me starting with saying, let's use the same approach, because otherwise we arrive to a bottleneck where the back end starts to have microservices.

The front end has a monolith.

They start to have bazillion of feature flags spread across the code base, and we are not going to have time for fixing that.

So we need to think about a different approach and looking into the characteristics of microservices.

So you know that there are defined units that have strong boundaries, not only on the code level, but also on the infrastructure level, and that is one key aspect of micro frontends.

Therefore, we need to have an artefact, in the case of microservices, was a container back in the days, or a VM, that is strong enough that I deploy this chunk independently from the rest.

That is not only code that they build at compile time, but it's something that they do at run time in the case of the front end.

So I load a chunk of the system, and I lazy load a chunk of JavaScript.

And that was the first assumption.

The second one is, I want to have the team independence.

Therefore, shareability, we need to be careful.

We need to rewrite the game where in front end, when you have three lines of code that repeats twice, immediately you create a library.

And that is evil, because when you have, let's say, a lot of external dependency, we need to reduce them.

So we need to try to be extremely careful on what we want to, let's say, reuse, and how, and having a strong governance into that.

And governance is not easy, because it involves people.

And therefore, we were thinking of something that it didn't involve people, but maintain the boundaries of a team.

And the idea is, let's start with duplication, because definitely duplicating is far cheaper than the wrong abstraction.

So, like Sandy Metz said several times.

And the idea is, okay, so if we start to do that, we need to be intentional what is available and shareable between teams.

And the other thing is, we need to create an artefact that makes my team independent.

Because the reality is the distributed system is not designed only for technology, where, yes, you have, let's say, the possibility to, let's say, deploy something, there is a bug in an area, and only that chunk is affected, the rest of the application works perfectly, but it's mainly designed for your organisation, for your people.

Therefore, when you are designing this, you need to think about, okay, so if I have a team that is responsible for the catalogue, I think about the catalogue of Netflix, where you have, like, a lot of rails with all the different shows and different things.

Then you select one, you have the details, and when you're happy, you click play, and the video player starts.

Think about that, that could be a nicely encapsulated chunk of the system for an authenticated user that enables the people to, let's say, consume and can assign to the team because it's not too complex, it can be incorporated very well, and that basically, for me, was the first microphone that we built.

But then suddenly, when we look into the video player, we saw a lot of complexity.

We had two teams only dedicated on video players, where these teams were responsible for creating the heuristics and tweaking the heuristics on existing video players.

For live content, it was completely different from on-demand, and every browser has its own codec, and therefore, we had to change the way how we were working.

So now we had a microphone tag that lives inside another one, so the catalogue basically was one microphone tag that was loaded, and the other one was a video player.

So in order to communicate, we need to think about how we are going to define this contract in an API contract first.

So you start to see a lot of similarities on microservices.

What I'm describing basically is the application of the practises that we are used to doing in a distributed system into front-end that before, it didn't happen, and today, people are still struggling because you need to have the experience on the other side in order to understand what fits on this side.

So you need to understand deeply both in order to see, okay, this practise, I can use it.

This one, it will never work because there is no constraint and no need on front-end to do certain things.

And therefore, it's super fascinating for me that period of my life where I started to bring, let's say, patterns and mechanisms that were applying software engineering and see how I could shape them for front-end, if it makes sense.

Unpacking that in my brain will take a moment, but basically, to put a little summary on top of this.

So the problem space is basically the difference between we do IT now and do IT 20 years ago is the scale and the speed, right?

So if you look at this, this is no longer a technical problem.

It's a socio-technical problem.

And this is not a problem of writing good code.

It's a problem of writing good code in cohesion of responsibility and accountability for said code distributed among several teams.

So we're basically definitely hitting Conway's Law as a problem, right?

So we need to design in a reverse Conway manoeuvre so that we change our organisation towards the functionalities that we're building, split in domains, subdomains, and pieces of code being microservices assigned specifically.

So the distribution of that system is a socio-technical distribution rather than purely technical.

And of course, if we do it purely technical, yeah, we have a chunk of code.

It's easier to change, easier to isolate.

Only that part is, and the closest dependents are impacted by a bug.

Fine.

But in a software lifecycle, that's a lot more to tackle in that sense.

Yeah, there's plenty more.

If we were doing this on a monolith, then we would have not only the whole system impacted by a bug, we would have also plenty of other teams impacted by the same bug.

Where if we distribute that, we have less teams impacted, but that requires more organisational work and governance between those teams.

And this is also where coupling kicks in, in communication between modules, microservices, and communication between teams.

We have different types of coupling between them now.

And now the question is, what's going on in that coupling?

Because that's interoperability on two different scales, one being technical interoperability and the other one being the human-to-human interoperability.

Because I just finished a course from Vlad Kolonov this Monday.

The course was on Friday, but I watched the recording because I couldn't join.

I'll pop one interesting slide, if I can find it.

I think this is, yeah, this is the one.

I'll pop it on screen.

There we go.

So I had quite some fun looking at this table.

Vlad describes three distinct axes of qualities of coupling, two of them being distance and knowledge.

And the interesting part in this is that I have never really considered looking, without looking at this table, is that low distance and low knowledge is actually something of a problem.

It's problematic.

I think this is something that you probably did tackle in the early days of microfrontends as well, that you had low distance between the specific microfrontends, but the teams didn't understand and know what those specific microfrontends did, which created lots of extraneous cognitive load in trying to figure out what the hell is going on.

Correct.

And then, of course, if we look at it from my perspective of an integration architect, I'm usually in high distance, high knowledge being the problem, because that's the tight coupling between various domain systems, which is something you probably do not experience that much in microfrontends per se.

But if you communicate microfrontends with the rest of the ecosystem, that's probably something that also may happen at times.

Yeah.

The challenge I face multiple times is shifting the way how people were thinking about this, let's say, interoperability between microfrontends, because there is a different dimension when you think about that.

You can have multiple microfrontends in the same view, and that basically means that at some point they need to communicate.

99% of the time, because since 2015, frontend was, let's say, working with the state management system, people were creating this thing called global state management that everyone can get access, write, read, whatever.

But it's more or less like having a single database for multiple microservices.

What happens if I change the schema?

Everything will have a ripple apart effect, and I need to retest everything, and I need to redeploy everything together, and it's going to be a colossal problem where people then point the finger towards, oh, microservices sucks.

That is not true.

They are just a specific challenge.

And that's also similar if you apply orchestration.

That's also a single point of tighter coupling in microservices in that sense, because the orchestrator needs to know a lot more about state.

By the way, the next slide from this deck is this, which is basically showing what these lead to.

We have complexity and complexity, which is the things we tackle at different areas.

You tackle that in frontend.

I tackle that in system-to-system interoperability.

The anecdote here that Vlad shared over his course is that when he asked this over a conference where people would like to be, would they want to be in the green or the red zone or the orange zone, actually quite a number of people pointed that they would rather be in the orange zone.

And we're going back to sociotechnical problems.

Job stability, job safety being the answer, why would they remain in the orange zone, which is interesting, because if they overcomplicate and make complexity, then they are secure for a job because nobody can figure out what's going on.

And that's not the aim of neither proper integration architecture nor building microfrontends in that sense, because we want these things to be, let's say, somewhat simpler so that we actually can figure out what's going on and not have that additional cognitive load that makes us just horrendously tired over figuring out what's going on in our systems, right?

So looking at microservices, okay, microservices being, sorry, microfrontends being a specific, very specific specialised version of microservices that expose frontends.

They expose frontends in various ways.

We'll probably dig into that in a minute.

Now, if you could outline, what are the key differences of microfrontends to the traditional approach to frontends, the monolithic approach?

You can share the screen that I'm sharing.

I can show you and walk you through something concrete.

Yeah, perfect.

Let's do this, of course.

Okay, this one is an example.

I imagine that this is an e-commerce.

I'm not a designer, so don't expect great things from this e-commerce.

I'm sorry about that, but I prefer to code.

But the idea is very simple.

So usually microfrontends, in some shape or form, you have what is called an application shell.

This is as simple as a container.

So if you type www.mysite.com, first thing that you are going to have as responses is an application shell.

That generates something that lives for the entire user session.

So it would be there for the entire time and takes care about common things that you need to do with microfrontends.

So routing, composing microfrontends.

It takes care about retrieving the first, let's say, configuration that is read-only for microfrontends.

That's another thing that's important.

So you cannot tamper it.

There are techniques in JavaScript, like if you use object.freeze as a method, basically makes that object readable, but not writable.

And that's one technique that you can use.

I used it for almost 20 years when I was working on this stuff.

And it's a good technique for saying, OK, I have this object.

I created and manipulated it in a certain way.

You bound to the contract.

You cannot change the contract, because in JavaScript, that is dynamic language.

You can change whatever you want in the way that you want.

And that's why you have often errors that are bubbling up here and there.

And then in this part, usually what you want to have, it's the most stable part of the application that change context by context.

I'll give you an example.

This header, for instance, is as a navigation with another.

And that doesn't change in this example.

There are companies instead that requires to have a team dedicated to a header because of the size of the complexity of that specific header when they work globally.

Think about the large e-commerce that they use to buy stuff.

And that is so complex because different services in different countries with different languages, all the permutation is making that very, very complicated.

So that could be a microphone tent.

But the reality, majority of the time, 99% of the time, I would say it's not one of them.

It's the simple components, OK?

So it's just an element that you want to have, reuse, have the same look and feel, because components compared to microphone tents, one is microphone tents, as we said before, they are aiming for independence between teams.

The other one is aiming for reusability.

And as Neil Ford says, reusability is a form of coupling.

Therefore, we don't want to have components, but we want to have distinction between these two elements.

So this one is basically baked into, it's a component baked into the application shell.

At that point, when I'm basically going to these localhost 2000, I'm loading the first microphone tent, this home page.

As you can see here, I also, let's say, highlighted, which is the version of the microphone tent, this is React 17, because I want to show you one thing in a second.

This one is composed by a bunch of things.

Marketing hero, banner, bunch of products.

When I select one product, click the product.

At this stage, for you, it was instantaneous.

You didn't feel it, not because it's localhost, it would be instantaneous also on the web.

What happens is basically loading a new microphone tent and possibly sharing certain dependencies.

That is completely transparent for you.

There are frameworks that enables you to download a React version once and reuse across all the microphone tents or only the microphone tents that acquire that version.

In this case, we have React 18, so we downloaded a new version of microphone tents, but they are living exactly in the same application.

For you, the look and feel looks the same because you're using the same design system.

You have exactly the same thing that you have in the past.

But the cool thing is that here we have two levels of, let's say, navigation.

The first one is between first level URL, as it's called, so hard navigation between home to catalogue.

We are changing domain, so therefore we are loading a new microphone tent.

Inside the catalogue, the team responsible for that will be responsible for having the full view of the product that are available and the specific view on a specific product.

It could be that they have also the review that is owned by a different, if you are a large team, you can have the customer reviews that are coming from a different team.

Therefore, it could be microphone tents.

If you have a simple e-commerce, it's more than enough having a component.

Those are just components that you can reuse in multiple parts of your system, but it's reused inside the same team, the same, let's say, area of the application.

That, I believe, is one of the power of these things.

I can evolve this stuff in the way that I want.

I can drill down and expand the capabilities of my catalogue, adding more second, third, fourth layer of URL, and drilling down with a complex routing mechanism while the application shell takes care about the global navigation, that is basically the first level URL.

Now, when I move, for instance, in my accounts now, the cool thing is that I have React 17 and React 18 that are already loaded because I loaded them before, but they can't even live together.

This is a classic example when you are migrating or when you are working with different teams.

In a distributed system, the coordination is the part that you suffer the most between teams because it's very difficult that you can say, okay, so now stop everything.

Don't deliver that feature because we need to update a version of React, Angular, whatever.

Therefore, what you can do, though, is isolating, doing scope creep with multiple approaches, but this one is the one that I choose for this application and say, okay, these both will work together because they are not sharing specific data, but just, let's say, an object that is read-only and is vanilla JavaScript.

It doesn't matter the framework.

Now, if I want to communicate between the two microcontents, like in this case, when I click make default, you have this toast element that is at the bottom.

This is a component that is living inside the application shell because it's generic.

It doesn't have to be lazy load.

It has to be there because multiple elements can use this.

The thing that happens is what would you do in a microservice application if you want to, let's say, avoid point-to-point communication?

You start to think about having a PubSub because a PubSub enables you to publish an event and one or multiple subscriber will react to that.

Same thing with microcontents.

Instead of having, let's say, a global state that maintains the state for everyone and where everyone can write and change potentially certain things, you just send an event that has a body.

If you think we are getting closer to a certain extent of messaging architecture, you start to look into that part there, where in JavaScript it becomes extremely simple because now I have this element that is easy to test because I know that these, let's say, subscribe to certain events, so I can generate these events and see how it behaves.

As long as when I push for production, the other microcontents are doing the same thing, then suddenly everything will start to work very nicely because everything is independent in the testing phase, in the design phase.

There is a little bit of coordination, obviously, because maybe there is a new design system that changed, some breaking changes, whatever it is, and they require these things.

But if you start to think about the effort

where you design carefully

what are the touching points for the company

and when there are touching points,

you create mechanisms, request for comments,

architecture decision record, events that are typed

and are capable to be shared across the system,

you start to see that this area of design,

the social technical system,

generates a very simple architecture

because now if I'm responsible for payments as a team,

I will be responsible for the API of payments,

I will be responsible for the integration,

probably when I'm subscribing

or the checkout phase for payment,

I will be responsible for this view

that basically enables me to change the thing.

So now my team responsible for payments, we know inside out that domain, we'll be domain expert with that, they can contribute with the products people to create a better user experience and a better UI with the designer.

And moreover, they can take the right decision for the job where very often we try to operate in economy of scale because we don't have enough bandwidth or people to cover the extent of a specific complex system.

Now, if we start to look into this approach, now you see that your role as architect or platform engineering, et cetera, is supporting all these teams in a way with, let's say, common practises that will enable them to work together closely, but without being coupled.

Because if sending an event is easy to test, as long as everyone respects that event, I don't have to coordinate with others.

If I need to add a new microphone tent because there is complexity arise or a new domain that we need to squeeze inside this view, but then become easy because if I know what are the events that are bubbling around this view and the events that are available in the application shell, I just add new stuff.

Even if I add the new events, I can add the new events, start to send it.

The worst case scenario is no one is listening.

There is no error happening inside the JavaScript.

It won't block your application at all.

And you can also have a lot of nice logic on, okay, I'm interested in that event.

And then you can start to have, okay, can I have also this information with this other team?

So you create a request for comment, you express what you need to have, and the other team can validate your request.

And you see that now we start to look into holistically on the system.

It's not anymore I implement React and I use this stuff.

Now we want to encapsulate, and the terms encapsulation includes data and methods.

It's not just UI.

So if you start to think about that, my payment methods is encapsulating all the knowledge about payment of that specific user.

In this case, there is no leaks.

And if it needs to communicate on something that happens, can communicate passing the title and the description of what happened with this specific action.

But the action itself can be reused by other place because you design in a way that is agnostic from the domain because it's living inside application shell.

A lot of these thoughts that I described, that I'm showing you here, are basically the process that enables you to create independent teams that reduce the extent of dependency, don't eliminate the extent of dependencies, but just reduce them.

And they have more control and power on making change without interfering with other massive release that could happen.

Then in my experience, once or twice a year, sometimes four times, of course, if you have a very fast pace place, you are required to have something that's spanning across a new feature that's spanning across multiple domains.

So in this situation like that, there is the requirement of coordinating multiple teams, trying to understand how these things will pan out in terms of contracts.

And in this case, what kind of teams will be affected into that.

I was in that scenario very often.

But if you play very well your role as, I don't know, staff engineer or group of the virtual team that is working on the design or architects, whatever is available inside your company, then you start to see some interesting pattern that if you design properly that chunk, the implementation will become a breeze because it will be part of the patterns that you have already created.

And if you have a new pattern to integrate, you will have the possibility to test with a chunk of the system without affecting all the rest.

So the complexity is there because you need to think holistically on the system.

But at the same time, the reward is there as well because I have, let's say, my previous company, what I was working for, for this company called The Zone, a staff engineer that I met last year told me it's eight years that we are working with this architecture.

It never went through our way.

We were able to, let's say, change the things accordingly for what the business wanted because of your principles and, let's say, design that enables us to be flexible where it was needed to be flexible and then force boundaries and generate friction where it was needed.

And I think that was the testimony that design is still an extremely important part of software.

Okay, Luca,

so to recap a little bit here,

so the approach is

as if with a microservice system,

any microservice system,

we're looking at having high cohesion

within a microservice

or a group of microservices

that are bound to a specific domain

or subdomain,

however you want to name it

using domain-driven design

or just plain language,

so that within that cohesion,

you have a full understanding

of the problem space

like payments or like catalogue

or like if needed,

the top bar of the website.

And that's the high cohesion.

And then looking at the distance

between different domains,

so either groups of microservices

or a singular microservice

and the teams governing them,

then we have a higher distance

between those two,

so we don't need that shared knowledge

as long as we describe the contracts well,

whatever those contracts may be,

here being like with microservices,

either API calls or events,

if we do PubSub event-driven architecture

exactly like with a microservice system

because it's very nice

to combine microservice systems

with event-driven architecture.

That's a very common thing that happens architecturally.

I'm curious because I've never been a front-end guy.

I mean, I do write a little bit of HTML, but that's the extent of my front-end knowledge because I mostly write it for all sorts of plugins that I do in my Google workspace.

So front-end is completely not my thing.

I'm more of a, well, middleware engineer, not even a back-end engineer in that sense.

So I only utilise front-ends rather than build them.

I'm curious, could we dismantle this in a diagram to show lines and boxes and where does that communication and what type of communication does happen here?

If you even take the example of Fred's Tales, which is this demo site that you have, perhaps we can use that and you can then reiterate on this using some diagrams.

Would that be a good idea right now?

Yeah, that's fine.

Do you share the screen or should I share the screen?

Yes, I'll pop in.

So if any of you watching, we're currently live on Miro.

I'll post the, I'll copy the board link and put this in chat on YouTube.

There we go.

And also we'll do this on LinkedIn if you want to follow us on the board.

Otherwise, I'll just follow Luca.

Yeah, so let's try to, let's try, oops.

Diagramming in Miro, yes.

Yes, exactly.

So let's try to do one thing.

So this one was user details.

Let me increase a bit because otherwise everyone will hate me and we are near Christmas.

So at least we can say that we did good.

And this one was payment.

Just for the sake of Santa not putting us on the list, right?

Yeah, exactly.

I don't want to be the naughty boy, the naughty architect.

Could be the next title that I could use, the naughty architect.

And then we have here the application shell.

Sorry.

Question, what do you get in Italy?

What do you get from Santa if you're naughty?

Nothing.

In England, that would be a lump of coal.

Yeah, that could be that.

But usually it's for us, the 6th of January, there is the befana that I know is very specific for us.

And it brings usually, if you are a naughty boy, you have the coal.

Okay.

In Poland, this is a stick.

A stick to whip.

A flexible stick that we get if we're naughty.

All right, so this is the shell.

This is our situation, right?

Then we will discuss about the interoperability with the services because also there are interesting discussions.

So the first thing is, I don't know how to draw that.

Let's assume that we can do in this way.

So you have like our object that could contain some configuration, okay?

That is owned by the application shell.

This is, let's say, the first element.

Ideally, it's not always the case.

Not everyone is implementing that way, but ideally, this should be read-only and is a property like it tells you.

Majority of the time, you have like, I don't know, feature flags.

You have maybe some URLs that you need to provide dynamically.

Sometimes, for instance, I've seen some companies passing the user data into either the HTML or exposed as an object inside the page.

I remember when I did the request engineering 10 years ago on Netflix, they were basically adding the user data inside the JSON object inside HTML in order to avoid to make another code.

That was a smart way for optimisation, but there are plenty of ways that you can do it.

But usually, you have a configuration of some sort.

The other thing is, at this stage, I can retrieve some stuff.

You will have, majority of the time, let's see if there is more shapes.

There is the document shape.

My shape, I don't know.

Yeah, there is AWS stuff, obviously.

Okay, let's assume.

Let's take this.

This one?

Can I take this?

No, I need to upgrade, so I cannot.

Let's take this.

Okay, perfect.

So then you have, majority of the time, a cookie that is your session.

This is available to everyone, right?

So the cookie is something that is, as long you configure it properly, because the security model of the cookie is that you can set up different subdomains there.

You can say www.payment.mysite.com will have this cookie, so the cookie will be accessible by every single domain.

There are a bunch of other, sometimes you have a database that you can have on local storage, session storage, or even a web database that is available inside your browser that you can use.

Those two things are accessible globally in JavaScript, so you don't have to do creating any fancy stuff unless you want to, but these are usually the things that are accessible.

So basically, every micro-frontend will have access to the configuration.

99% of them will need that.

Cookie, if you are in an authenticated situation and or local storage, session storage, web storage, whatever it is that you want.

Those are the things that everyone has available.

Now, if I want to communicate with the application shell or with the payment, what you usually do is having this emitter.

This one is, let's see if I can increase this.

Boom.

Okay.

You have this emitter that is a singleton, so you have just once in your instance, just once, and then you inject inside every micro-frontend, but the idea is that now my micro-frontend can, my direction probably is better, can send an event to or receive an event from an emitter and say, okay, I send an event that, I don't know, the user detail changed.

I need to show a pop-up, and therefore the application shell in this case will have a component that subscribe to the, let me see if I can do this, that subscribes to, how do I do a pop-up here?

I could build this one.

Okay.

That subscribe to the specific event that is, let's create the event.

It's called, let's see, onUserChanged.

Something better maybe, but let's use it.

That's a listener more.

Yeah, sorry.

Yeah, userChanged, I suppose the event would be then.

UserChanged, then what happens is, you send these events, then the pop-up will have that onUserChanged.

Basically, we receive these events and we'll behave in certain ways of showing the pop-up and then allowing certain things.

The userChanged obviously can have an object with some details that it can use and that are useful for the pop-up, either for retrieving certain information and other things.

That's basically miniaturised, event-driven approach.

Correct.

It's literally a pop-up system.

If you think about that, JavaScript is already event-based.

I click a button, a dispatching event.

The problem you have with JavaScript events, that is a problem I sorted out a long time ago with a technology called Flex that was part of the Flash platform and that shows how old I am.

I still remember Flash.

Missed it dearly.

The problem there is that even in JavaScript, you have a DOM structure that is basically a tree.

I can have different branches.

Let's assume that we have two branches.

This one is living inside a branch and this one is living in another branch.

If I use dispatch event in JavaScript, in order for me to listen to payment without referring to payment, because otherwise I create coupling, I know that today there is payment, tomorrow there isn't, so I need to change twice, so you don't want to do that.

But during that time, what you do is doing this.

So you do window.addEventListener. So registering the listeners to somewhere.

Why that?

Because this one is the top object that's composed of the browser, so for sure we'll arrive there.

The problem is the for sure part, because in JavaScript, I can also have inside my payment an object that what it does is, or a component, that is a higher level component that has, what is it?

Searching.

But it's further in the tree.

It's in between the payment or the component that dispatch that event and the window, and basically we'll do, these are the user change, you will have my function, my function, and inside my function, you can have a nice event, so preventEventDefault, if I remember well the method, and this will basically stop the propagation, and therefore it will never arrive to Windows.

Edge case.

When happens, good luck debugging.

So instead, this is a way that is completely abstracted to any framework.

That works, it's like pure vanilla JavaScript.

This is usually an emitter, it's an observer, not an observable, an observer pattern.

So I have an array of objects that are subscribing to a certain event.

When I emit an event, it's just taking the array part, going through the entire array, and say, on method, and then dispatching this specific event.

The beauty of this approach is completely agnostic from the position, so if tomorrow I nest payment in a different way or as part of another microcontent, whatever it is, it doesn't really matter, as long as it has the instance of emitter.

So this approach simplifies drastically the way how you deal with not having to think about, oh, now I have, let's say, a potential issue that could happen.

I don't know when it happens, because obviously at the beginning we all know we are extremely, let's say, pumped on applying all the best practises, but then when we have the first thing that you need to deploy for tomorrow because otherwise there's a problem, then you start to implement and cut corners everywhere.

And usually, even if you cut corner, you don't crash.

That's basically the idea.

Yeah, because the tree structure makes it difficult.

I don't really get to experience that because I don't get that level of events in anything I write in JavaScript, but if I can make an analogue in my head in what I do, it's basically where I put the variable in my code matters in the tree structure.

So this is exactly the same aspect.

If I put the definition of the variable very low in the tree, close to the root of it, then it's accessible to a lot of things in the code.

But if I define it somewhere further in a loop or in an if statement or anywhere else, then I will have a problem because it will not be visible to the other parts, and then I need to rethink all of this.

And this is exactly the same issue, but at a different scale.

Correct.

That's the challenge.

Yeah.

And this one is the communication that's happening inside the browser, basically, majority of the time.

Right.

Now, there is a communication towards the backend.

And here we have a variety of possibilities.

We can have GraphQL as an approach.

So I expose, like, GraphQL.

Why GraphQL for frontend makes a lot of sense?

Because if you have a majority of the,

let's say, application nowadays

are on mobile, are on web,

sometimes in other devices,

and the thing that I can query,

let's say, GraphQL,

with information that I need

only for that specific screen,

reduce the chattiness,

I can design the things in a better way,

I download way less code

that is not needed,

especially the mobile teams

are extremely happy

when there is GraphQL on that.

And there is a caveat, but we will discuss in a second.

And in general, you know, it's a great way, very, I would say, quite democratised nowadays.

It's not that you need to get crazy on that.

There is a very nice level of sophistication now in certain implementation where you can even have security on what you see based on the token or based on the role of the user.

So there is, let's say, quite a lot nowadays.

The beauty of this approach now, especially in the last few years, is that you have this idea of, what do I use?

This one probably.

Schema federation.

Where, if you think about that, I have multiple teams that are working on an application.

We decide that we slice in a certain way our front-end and our back-end.

Now, suddenly you are introducing a single point where every single request is passing through.

How can I maintain the independence of teams?

And GraphQL come up with this idea of schema federation.

This idea where I create my own schema for describing my own domain.

And then GraphQL is creating a super graph that is bundling everything together.

So I have it for front-end, it's a unique layer that I get access to.

But for the back-end, I can evolve things in a way that are completely independent.

Okay.

So for those who are versed in domain-driven design, for me, this sounds like GraphQL created an open host service with published languages based on whatever is the domain you're trying to work.

And that schema federation works as the repository of those published languages.

Correct.

So the cool thing of the schema is that you think about, you create a schema, and I need to consume that.

You create one, and then another person will create another one.

And somehow I need to find myself that they can combine different domains because the domain on front-end might not be the domain on back-end.

In the previous example, for instance, you probably have a user domain and you have a payment domain.

That would be some foreign tables, some communication between these things, depends from the complexity that you have.

But the reality is these two things will be distinctive.

But in the front-end, we want to show both.

And therefore, as you can see now, you are in a situation where you create something ad hoc.

For instance, GraphQL won't require that because you have the availability of multiple domains available for you, and that could be okay for certain companies.

In certain scenarios, though, there are, let's say, if you start with REST APIs, you want to keep REST APIs because the problem is not that GraphQL will create technical challenges, but will introduce philosophical issues inside your system because the way how GraphQL, let's say, democratise the information is maybe something that you want to do on a certain part of the system.

At the moment that you introduce something like that, in six-month time, I can guarantee you that happens more than once, someone will say, but that team is using GraphQL.

Why cannot we use the same because we have a similar problem?

And that opens up a door of different philosophies, different way to update APIs, different ways to consume APIs, different way to scale infrastructure, and that can go ahead forever.

So for me, it's very, very important that when we, at the beginning of the discussion, we were saying, guys, let's try to think and design things in a certain way.

You look into this problem and understand, okay, GraphQL, it's something that we want to embrace.

We know the trade-off, what they are, so we democratise the information.

Is it fine for what you need to do?

Because then if you have high volumetric and it requires, let's say, I don't know, you have a million requests every second, then you need to scale horizontally.

It's totally doable, obviously, but one thing is, let's say, handling, let's say, one service that has to scale, I don't know, 200,000 requests per second.

One thing is scaling one that is a million, and if it's down, basically the whole system is down, right?

So you need to be careful on how you design these things.

You can potentially think about a back-end for front-end approach that is domain, let's say, divided by domain.

That could be another approach that you can think about where you just basically have the possibility to not having a schema federation.

You just have a REST API that aggregates a bunch of APIs from different domains, potentially, or the same, up to you.

But then it means that I will have a proliferation of those, so one per domain, and a BFF.

If you are actually partitioning per domain, because I would argue that depending on the maturity of the organisation, the maturity of the teams, you may just have a single BFF that will handle all sorts of domains because you haven't even thought about the main partitioning at this point just yet.

You have more of a functional partitioning and technical partitioning rather than actual domain partitioning.

For me, you know, because in my experience, there are, I can tell you, in my previous job, for instance, we used one BFF for one domain that was my account for not having to deal with exactly this problem here.

Because when you have one microcontents, you need to create governance into that.

Who is responsible for end-to-end testing?

Who is responsible for integration?

Who is responsible for making sure that we need to define these API, these events, and therefore everything will work?

Who is creating the, so there are a lot of who is creating, so the ownership part becomes complicated.

So how I solve that is say, okay, I can have two teams responsible for that or I can have a BFF for my account, let's call my account here, that includes payments and user details and whatever else we had in the past.

So now that this team is responsible for one microcontent, okay?

That services two, yeah, that services different things.

It is super simple.

The domain aggregation is done at the backend and still the same team is responsible for these things.

And they remove all the complexity on governance.

Right.

So I was the only domain that needed this specific treatment, introducing GraphQL like it was asked from developers or let's say handling microcontents differently, but then having all the complexity on updating and all the other stuff, I resolved in a very simple way.

I created a backup from front of my account.

The API weren't changing very often because I check the code volatility of these API.

So the contract remained fairly stable.

Also because we have, let's say, payment APIs are delicate in general and user are the same.

When you define user, usually you augment the API.

You don't do too many breaking changes in a year.

So code volatility wise, we were fine.

And that enabled me to have, let's say, a single point where I aggregate all the information.

The team was responsible to switch when needed the right version of the API to consume.

And the microcontent, it will have always the same, let's say, contract.

So it will be a team, very easy to maintain that microcontent.

The only thing that needs to take more into account is the backend for frontend.

So as you can see now here, the decision, it wasn't, oh, let's play with GraphQL.

It's trying to figure out what means for me in terms of trade-offs if I have multiple microcontents in the same view and analyse what is the benefit of instead introducing a middleware and disaggregating the data, because in reality, they're not changing very often.

And the traffic on that specific area, my account, if you think how often you go to my account in Netflix, it's probably once a year when your credit card expire, when you want to change your email, stuff like that.

So it wasn't, let's say, the complexity wasn't worth it for the domain that I was designing at the time.

That's another key takeaway, in my opinion.

Very often, again, we're not playing with best practises or amazing tools or bleeding edge tools, but we reason around what is the trade-off that really makes shine that specific context, because context is king.

They can provide the best effort without, let's say, create too much complexity.

So basically here, we not only have a trade-off analysis

over, let's say, the functional aspect of this,

because we have the scope of usage, the volatility,

which is one of the degrees of coupling,

as described by Vlad Kononov,

but also we're looking at the socio-technical aspect

of what is the trade-off then,

from a socio-technical perspective,

over responsibility, accountability,

of different tasks around the whole lifecycle

of these components.

So development, making changes, maintaining this, testing this end-to-end, and all other aspects of communication between teams.

As I was saying at the beginning, the whole point that I started with, the principles behind a micro-frontend, and one of them is being dependent, that was my north star to follow.

Therefore, if I design things without thinking

what is the impact of my developers

holistically, in terms not only on cognitive load,

but also what is the effort, what is the governance

I need to create, what the platform teams need to do,

there are extra new things that we need to think about,

think about ownership and stuff like that,

I'm making a disservice to the company,

because, again, it's not architecture that is failing,

it's you that you are, let's say, simplifying too much

the complexity of building software

in a distributed system,

because a distributed system has a complexity

that is in three dimensions always for me,

architecture, engineering, culture,

and team topology, so organisation structure.

If you're not seeing these three dimensions holistically

when you do trade-off analysis,

then you are basically taking a guess

that you might have the right decision or not,

and then blaming architecture

because there is friction inside the system

without understanding that this friction

is the way that architecture

or a social technical system has

to tell you, by the way,

you didn't think about the other dimensions.

I like to refer these kind of points to Tesla's law.

You probably know Tesla's law because this is a very common law used in user experience.

I personally use this for system-to-system interoperability because it's still very much applicable, and Tesla stated that there is an inherent amount of complexity in the problem domain that is irreducible.

We can add accidental or additional complexity to it by over-engineering, by over-complicating, or over-simplifying a problem.

That complexity, the question is who is going to handle that complexity?

Basically, what you're saying is it adds degrees to where that complexity can go or derive from because it can derive from architecture itself, it can derive from the engineering culture and the team topologies to the organisation itself or go to those places if it's poorly addressed in any of those categories that you mentioned.

Completely, because if you see this example that I made on purpose, this approach is technically sounded.

And similarly, the approach technically works because I'm maintaining the separation of concern between the elements.

Now, the problem is in a vacuum.

Both will work and will be well-designed.

But if you start to add a new layer

that is the context,

so the business requirements

and the architectural characteristics

and the engineering culture

and the organisation structure,

now you start to say,

but probably this makes more sense

because looking at the vacuum

on the technical solution nowadays,

especially in distributed systems,

is, let's say,

being a bit blind

on the reality of the case

because if you are not capable

to have a full understanding

of the system,

it's very difficult,

and the context is very difficult

to say this is the direction of travel.

As an AWS specialist, what I'm doing is jumping in a customer that I maybe never speak with and that half of my discussions is around organisation structure and what you're trying to achieve, what are the goals that you have, what is your volumetrics, what is your availability goals, stuff like that, that they know will impact whatever I'm going to say after that.

And usually after 40 minutes that I'm talking about all of this, in 20 minutes I can solve the problem because now I have all the context of the world and I can tell you, listen, you are doing this, but the problem you have is that if you're telling me that your teams are doing this, that probably what you are implementing doesn't work.

Either you change the way how you structure the team or you change the way how you implement these things because otherwise friction will arise anyway.

So it's not a problem of technology, it's a problem of that you didn't think holistically on a specific part.

And that's why, let's say,

in the last 10 years

I mastered a lot

of this kind of multidimensional vision

as architect

because it enables me

to look at things differently

from a developer

that unfortunately

they are forced to look

into their chunk of the system

and therefore they master that part,

they are extremely proud of their craft,

but they don't, let's say,

take a step back

and look, okay,

what are we trying to achieve here?

And that's where I believe more senior people like staff engineers or architects or engineer manager, whatever, should provide that information to feed inside the teams for taking better decisions.

There is a quote attributed to Einstein that Einstein, when asked, at least supposedly, if he had one hour to save the world, what would he do in that one hour?

And the quote is that he would spend 55 minutes understanding the problem and five minutes actually saving the world and fixing whatever is wrong.

And I found this, I believe this exact attribution to the quote was somewhere in the book I was recently reading, a very nice one, domain-driven refactoring.

And basically, in the book, they touched, because refactoring is also a psychological problem, they touched upon what you already hinted at for the perspective of developers.

Developers, or engineers in general, they hate to be in the problem space.

They like to be in the solution space.

Oh, we see a problem, we jump to solutioning.

Exactly.

And that's from a perspective of business or from perspective of architecture, that's pretty much the worst thing you can do.

Because then you have a solution that doesn't really fit the problem and it doesn't really solve the problem because it didn't take enough time to understand what the problem is and potentially the solution should have been a lot simpler.

Yeah.

So already by solutioning instead of architecting, we jump into making assumptions.

And that's always going to be painful to a certain extent.

And this is why this kind of trade-off analysis and also looking at the other axes of the problem like engineering culture or the organisation or team topologies, the dynamics between teams, it's crucial to build a proper architecture.

Absolutely.

And that's why, honestly, what I'm trying to do is democratising this approach and trying to provide a distilled version of all the things that I discussed so far in my book in order that they don't have to do what I have done and they can, let's say, apply these things properly.

In my book, I spent plenty of time to describe migration, the status of the specific context that I was doing and stuff like that mainly because I want to, let's say, start to make them sensible on these topics because it doesn't come for free.

Very often, I have seen that teams blame me from time and when they maybe try in the field and then they start to speak with me and I start to dig deeper into the topic and I explain to them, oh, yeah, but your friction was generated by that from what you're telling me.

I say, oh, yeah, you're right.

And then they give a second chance.

The second chance usually is successful because if the mindset is not because I'm ingenious or I'm better than others, I'm definitely not.

I'm definitely an average person.

But the thing is, what differentiates me is that I start to look holistically on these things.

And everyone can do that if I was able to do this.

But the thing is, you need to understand that the problem space is bigger than what you expect.

Mm-hmm.

That is definitely true.

Usually, in general, the majority of the problems we have in IT are not technical problems.

Yeah.

We need to solve them on the level of a conversation with our stakeholders, conversation with our business to understand what is the actual business need.

Not the business wants, to be precise, because the business will say what they want, which is not precisely what they need.

And for us as architects, this is the part where we can step in to actually translate what they want from us into what they actually need to be built and developed and then we need to figure it out how it is supposed to be done.

And this is the difficult part because this is where we as architects really don't need that technical knowledge.

We really need a lot softer skills, right?

Conversation, capturing nuances, discovering things, being pretty much business analysts.

And that's for a lot of people, it's very difficult, especially if they're just beginning their journey into architecture.

Oh, yeah.

Yeah, it's a role that you grow in more than you're ready and you just, let's say, start to do that.

You need to push outside your comfort zone very often and definitely technical background helps because you have, let's say, already one part of the problem in your head.

You don't have to be, let's say, the best developer in the world, but definitely having a bit of background, in my opinion, helps because you have, let's say, a portion of the system there.

Then I was lucky enough to be in a situation where we needed to move fast and I have the possibility to look into the other two dimensions.

And that's where probably, let's say, nowadays, I'm more confident to say this is going to happen or this is the right solution because I was able to see them firsthand.

Yeah, I think that experience you had over this fast really quickly growing company, I think that really shapes.

Like me, if you work in consulting and you're exposed through projects just to a small snippet of the problem space, it's a lot harder to grow into the role of an architect that way because you don't have to tackle all those aspects.

You just tackle what you're served in terms of tasks in Jira or whatever other system that you agree on the scope of work.

And that's very problematic for people to grow out of that mindset and to look at the broader picture, to have that holistic view of what's going on.

And this is something that is really needed.

And I learned that kind of the hard way, but I also had, through reading the works of Mark Richards and Neil Ford, that really helped me further develop that view into architectural thinking instead of being narrow-minded into that technical thinking because it created more friction for me than it needed, really.

Yeah, totally.

I think when I had the possibility to jump from product to consulting, I always said no for a certain period of time because the challenge you have usually is if you work in product, you take some shots and some decisions.

But before you see the impact of your decision, it would take probably between six to 18 months from when it's in production.

Before that, it can be as good as it could be, but the reality is you learn, you need to play the long-term, long game in architecture because the more you see things that, okay, I decided this, this was the context, this was the situation, these are the outcomes.

These are all baggage that you usually have.

In consulting, the vast majority of the time you arrive to deployment of a solution, you see a chunk of the system.

If you are lucky, you have a contract that is long enough to see these things, but it's not given for granted, while if you are internally in the product, you evolve the product over and over again and that you see all your decisions right or wrong or right for the context that has to be changed, but you have the context of why you take that decision at that time.

Luckily, maybe you also documented in your architectural decision record, but then you have the possibility to iterate into that based on the involvement of the social technical system.

And that, for me,

is where really you learn

how to do architecture,

let's say, properly

because very often,

if you just, let's say,

move from one project to another one,

you will have a lot of breadth

of use cases,

but you are not going to see

if your decision will have

right or wrong impact

because of a variation

with consultants

that are telling me,

oh, I was doing that

and then it turns out

that some of them

was one of my customers

in AWS.

And when I spoke with them, we were saying, oh yeah, this consultant did that, but basically after they left, they left a mess because they were incapable to scale at the level that we needed and then basically they call other people to fix that and they validate with us.

So this situation happens over and over again.

So I think it depends in which, let's say, part of your career you are at.

I was lucky to move back and forth between consulting and being in-house, so I have the two perspectives.

And it really depends on what you need right now in your career.

Sometimes you need the breadth of knowledge to experience different technologies, experience different projects, different types of projects, because you got bored by your in-house project, which is constantly in the same scope of business problems.

So that's no longer interesting.

Other times, it's really, really nice to see over time how your work actually impacts the organisation.

And I remember this lovely part where I was still a junior developer working in consulting and then I moved to my client to have an internal role later as an architect.

And I opened, that was back when subversion was still a thing, not Git.

And I opened subversion, like, who the hell screwed this up so royally?

And I saw four years earlier my name under those comments screwing it up so royally.

And I was like, oh, okay, this is a growth moment, right?

This is where the perspective comes in, kicks in, and now I have a proper understanding of what's going on.

And this is important to put that context in.

Completely.

I think it's just a learning thing.

So in order to become an architect, you need to design a lot of stuff, see the impact of your design, and it's easier to a certain extent if you spend a few years in the same place because you will have a better perspective because you understand the context.

And moving between context, you can take away between context in terms of industries, potentially.

You can take away a lot of your learnings and apply in different industries.

But I did something similar like you.

When I was living in Italy, I had my own agency, so I've seen a lot of, let's say, breadth at the beginning of my career.

And when I moved to UK, instead I started to work more on product because I needed to go deeper.

I needed to see the impact of my things either as a developer or architect, wherever it was.

And that worked out

until a few years back

that I decided to go back

in a certain way

consulting in AWS

because there I wanted

to see where my depth

and breadth was reaching

the tipping points

and see what I'm missing,

what I didn't see

or I didn't discover yet,

and the possibility

to work with large companies

and large customers,

obviously,

was for me

extremely important

for my career

and validate, basically,

my learnings

and learn new things

that obviously

was one of the key aspects

for me to join

a company like this.

Yeah, these paths are crucial.

It's crucial

to have a little bit

of a reflection

over time

where you want to go next

and what you want to do

and why,

not just do random moves

in your career

because these moves

will definitely shape

your thinking

and the way you do things

and it's always

a difficult choice

in that sense

because there are

so many factors

that go into that decision

and your opportunities

for growth

from that perspective.

So, yeah, and this later translates to these kind of lovely designs like microfrontends which is amazing.

Okay, so if we had our microfrontends, we had the Shell app, we had different microfrontends embedded into that Shell app, we discussed GraphQL as a means of reading data.

Do you use GraphQL at all for writing data?

I don't think it's a thing.

Yeah, potentially you can do also that.

It's bi-directional completely so it's not a big deal.

You can even have subscription that basically enables you to have a web socket under the hood and when one thing changes, on the back end, it will be displayed inside the UI.

It's extremely powerful to be honest.

I've seen a lot of the capabilities offered by GraphQL used with microfrontends or with monolithic applications but majority of the time I've seen successful implementation on multi-device approaches due to the nature that they can query whatever they want and now with schema federation was a big plus.

Now microfrontends,

we borrow the idea

of schema federation

where you compose things

in a single schema

creating a super schema

and that's where

you lazy load stuff

and since I would say

seven, eight years ago,

we started to see

a proliferation of frameworks

that came out

on microfrontends

but now also

the new frameworks,

the server-side rendering one,

the one that is usually used

for e-commerce,

the most famous one

like Next.js, Astro.js, etc.

They have microfrontends as first-class citizen inside their system because you can use what they call React Server Components or Astro Server Island that are basically implementation microfrontends.

They have similar principles.

They don't call microfrontends but you can build microfrontends with those.

I have several examples

in my GitHub repository

with Next or with Astro

just to show

how you should think about it

because the reality is

when you understand architecture,

you are in a position

where it doesn't matter anymore

if it's edge rendering,

server-side rendering,

client-side rendering,

a desktop application,

a mobile application, whatever

because the logic is always the same

as architecture at the end.

It's not a framework.

You are not bounded to a framework.

You are bounded to, let's say, an approach.

So for me, in the book I describe what I call the decision framework that basically are four decisions you need to make in every single architecture.

Every time you design with microfrontends, I encounter this decision every single time.

So how to slice a microfrontend?

You want one microfrontend loaded per time, multiple of them.

Obviously, they are non-mutual exclusive so you can choose certain domains you will have multiple microfrontends like the one that we show in the diagram.

Some others, you might have a single microfrontend like the catalogue that I was showing in the demo.

And it's fine.

But then you need to think about how you route and how you compose.

So you do on the client, you do on the server, you do on the edge because, for instance, I applied strangler pattern on the edge for migrating from a monolith towards the microfrontends in a very nice way because that enables me to pass through the CDN no matter what I do.

Therefore, I can start to have some smart logic.

I started to have kind of releases at the edge where I say, every time that you call this microfrontend and I have a new version, I want that 5% of the traffic goes with the new version only if they are in, I don't know, Germany and they are in Google Chrome.

So in this situation, I can shape the deployment that basically the idea of introducing this was creating a safe net for developers to reach production more often because as the book Accelerate taught us several years back, we were looking into dollar metrics so we want to go as fast as possible in production because that is one of the characteristics that enables a successful company to succeed.

And if you create a safe net for developers, they are capable to, for instance, this approach moved the needle from two free deployments per month to 25 per day per team.

So we end up with more microservices and microfrontends at the end of the month when we started to have certain maturity that we had thousands of deployments per month across different layers.

But that tells you how fast you can go, how safe you can be, and stuff like that.

And did we screw up?

Of course.

Because naturally we have human beings in the mix.

So sometimes you forget about a specific configuration.

You forget to put behind the feature flags.

You forget about these things.

But that doesn't, nevertheless, doesn't mean that we screw up the proposal.

It's just, OK, we found a blind spot.

We need to understand how we can mitigate this blind spot that doesn't happen again.

This is the mindset that, in my opinion, people should have more than, first thing is, OK, let's create a gate that basically is preventing people to deploy.

And we hide behind this change advisory board that should know everything about everything that is happening inside the company.

Usually even if you have the smartest people in the company, the cognitive load is finite.

So they will never be able to tell you this specific service will not clash with the change on this other specific service.

So you are basically creating friction that is a safe net for the management, not for developers.

So let's invest more in automation and we create something that makes more sense for developers because those are the ones that need to speed up and be safe when they deploy.

Right.

Did you mean Accelerate?

Accelerate, did you mean the book by Nicole Forrest-Grant, Jess Hubble, and Gene Keem?

Yes.

So if anybody would like to dig in, here's a QR code.

of 200 companies worldwide where basically in the first part of the book they describe what are the traits of successful companies.

And the second part, they describe how they tested or better, how they conducted the research for retrieving this information.

What they discover is that there are some traits that make companies successful.

One is how fast you can deploy, how fast you roll back if there is an issue, how fast it takes from ideation to production, and that basically is the base of the foundation of Dora Metrics.

And that was one thing that nowadays in the industry is quite well known.

And now there is a new book from Nicole called Frictionless that I think came out last month, I can't remember well.

And it's basically moving to the next step.

I didn't read it yet, but it's definitely my reading list.

Okay, I don't see it.

Otto Reilly would have to dig deeper to find it, but yeah.

Let me see if I can find it.

Okay, now if I just still took a look at the diagram we drafted on Miro, and I'm looking like, okay, so we have interoperability between the microfrontends being through the emitter, so we have even driven-like aspects that are avoiding the JavaScript problem of events and listeners.

Then we have interoperability between the microfrontends and the backend, as in GraphQL or backend for frontend.

And then basically, if we have that layer of a backend for frontend, whatever version that may be, then basically that is our abstraction layer that we then go into communicating with the rest of the ecosystem.

So this is where my job begins, how to get that data moving between that particular backend of that frontend into the rest of the ecosystem.

And this is pretty already standardised in comparison to what we have in microfrontends, where that, for me, is something that is very much abstract, because I don't do it simply.

Of course.

Because it's that abstract.

It's just something that, as an architect, I do not really touch upon, and that's the interesting part here.

So, okay, so that's...

Any things that happen specifically if we talk about external communication as available from the internet?

Because if we look at...

Well, the frontend isn't available from the internet usually, right?

If we have a product site or whatever, but then what is...

You can share again the Miro board.

I would like to show you one example.

There we go.

Back to the Miro board.

Amazing.

So, let me zoom in here.

So, imagine that this one is your, I don't know, server-side rendering...

Oh, sorry.

Server-side rendering catalogue page, and you have classic example...

Sorry, catalogue.

And you have a classic example, an external advertising server.

Let's do it this way.

So, you have ADS server.

In the meanwhile while drafting, I put the QR code for frictionless on the screen.

So, if somebody's interested in looking into that, that's also there.

So, in this case, for instance, I want to do server-side rendering of my catalogue, but the ADS server is an endpoint that they basically provide personalised advertising based on the user, and they show basically a specific element inside the page.

So, that cannot be cached, has to be retrieved dynamically from advertising servers, etc.

So, what you do usually is that this has to communicate with whatever system you have from mobile to whatever.

So, you go with the common denominator, the HTML, basically.

What you have here, sorry, when you are fetching this information from here to here, you are going to have back, let me reverse that, you're going to have back what is called an HTML fragment.

Where is the text?

That is nothing more than an HTML element that is self-contained, that contains all the graphics, text, whatever it is, based on a bunch of parameters.

So, now at this stage is to a certain extent potentially malicious code.

If I intercept that, it could happen wherever it happens.

So, the tendency of what you do is sanitising this code and HTML.

HTML usually is not malicious because they don't provide, let's say, a lot of JavaScript.

There is probably a non-click thing if someone is clicking, is attributing that thing to the advertising or whatever it is, but it shouldn't be, let's say, too much logic.

So, this one is usually sanitised, is injected inside the page that is rendered and shipped to the user.

Now, the other approach that now is not there yet, but it will come very soon, I would say, is when you have an AI workload.

Now, the AI workload, what it's going to generate is JavaScript.

So, I have a chatbot,

and imagine that at some point

I want to do a trip to Florence,

and instead of providing you

a text-based approach,

it's going to generate UI

where you have a video of,

let's say, what people were seeing

in one place,

and maybe they have,

I don't know,

some other ideas of what could,

I don't know,

a common itinerary

or the most hotel

from the people

that are coming from your country,

wherever it is, right?

These are a basic example of microphone temps if you think about this, because instead of providing you contextual text that is explaining one thing, you can have instead graphic things that are generating in an encapsulated way with a set of elements and then pumped with data that God knows how they are generated, right?

So, in a situation like that, now you have a bunch of full microphone temps potentially.

Okay, we are in the realm of if, when, and it's going to happen, but you are going to have JavaScript here.

There are already some examples that I've seen on mobile, for instance.

It's very interesting, this approach, but imagine that you have like here JavaScript, a microphone temp JavaScript that is fully JavaScript.

Now here it can be wherever, right?

And it can be also that the implementation screwed up because it's using a specific version of a library that doesn't work.

It has a bug, it has a security issue, wherever.

So the idea here is, okay, how do we sanitise in a situation like that?

And probably we're going to need something new or let's put this one here that sanitise this, that is a code sandbox that takes the code, parse it, run wherever scan you need to run in this code sandbox and then finally reaches the part that you need for communicating with your system.

And that is becoming very interesting, right?

Because now suddenly you can generate code on the fly, you can apply your UI and your design system because LLMs will enable us to do that.

And now we have, although for security reason, you cannot trust whatever is coming because we know when we play with the system that the precision of the code is generated, is probabilistic.

We are dealing with the probabilistic system is non-deterministic, therefore that you like it or not is going to screw up.

So the code sandbox will become a sort of, if you want, a safe net for us to have this feedback loop that is communicating between the LLM and the agents to understand does it, let's say, work in the way that it is.

But if you start to think about this, now you became to add a lot of security stuff here, a lot of logic and deterministic thing, security, style, et cetera, whatever it is.

Now think how powerful it could be in transforming what today is a non-deterministic system that generates, rightly so, non-deterministic or probabilistic, let's say, responses because if you ask the same thing, it could provide the same answer or not.

But now we start to add a bunch of layers of determinism in this probabilistic system.

And what if we are not going to have the perfect deterministic system?

There is no way that a probabilistic system can turn into a deterministic system unless you change the architecture or, let's say, mathematical implementation behind that.

But in this case, we start to create, let's say, a safe net that will reduce drastically the way how we could screw up.

And if you are

in a situation like this

where things are small enough,

we are not asking to build

an application,

we are asking to design

a thing with a certain constraint,

then I think it will become

quite likely

that we are going to have

something that is kind of interesting

and could scale very nicely

because with all the

microservices approaches

that we have learned overall,

we start to have, like,

I don't know,

imagine a dashboard,

one microfrontend

that is generated from LLM

that have a bunch of safe nets

that will be served

by a single endpoint

that is integrated

through microfrontend

inside the same UI.

Now the thing starts to become

very, very cool

because with this approach,

you have a mix, potentially,

of deterministic,

non-deterministic systems

or semi-deterministic systems,

I don't know if there is a term

in English to define that,

that although you still control

to a certain extent

and it's just, let's say,

being good on defining these,

let's say, rules

or deterministic nature

for reducing or eliminating

the possibility

to have some outcomes

that are not, let's say,

I don't want to say correct

because this is the wrong word,

but as expected.

And this is probably where a number of externalised APIs will come to play to be able to facilitate that.

And the frameworks already have them because the React server component is nothing more than an endpoint where you basically render a chunk of the UI and is embedded inside a static part.

So it started to become extremely interesting, this new world.

This is an area of research that I'm currently looking into to see how far we can push these things.

There are some missing parts, but we are getting there.

Okay, that's probably going to be a very interesting feature and also touching upon interoperability to how to properly govern that and make those AI workloads hallucinate less and work to our advantage because working with non-deterministic systems is already a difficult aspect.

That's only always.

And I think this is...

We need to take for what they are and not trying to make them doing something that they are not designed for.

Or design specifically to train LLM models to be in a specific use case of micro front-ends and serving content.

This is a different topic where we have training and then fine-tuning where training is towards working as a micro front-end and fine-tuning would be then training the model in the aspect of that business or that site or whatever the purpose is.

That will be definitely an interesting avenue of research in the next years to how to properly make it a tangible use case.

Completely.

I think it's just that this idea itself could literally lead to a very interesting approach overall where it doesn't have to be let's say developed fully by developers but you need to create the governance around certain things that are developed as raw elements and then augmented through AI on the fly and then composed with all the distributed system nature that we have learned overall.

Because now we are designing a UI and now generating certain type of code so there are a lot of nuances there and with all the checks that I was mentioning to making the output not harmful for the system it started to become a very interesting thing.

So we need to understand how much we can push the boundaries.

And let's leave it at pushing the boundaries.

Hopefully, somebody will pick it up and try to push that boundary alongside you and others who are already doing this.

And that's it.

Luca, thank you so much for your time and for your explanation into interoperability of microfrontends.

That's been enlightening.

Now I know how they work at least.

For me, as an integration architect it's easier to comprehend the nuances and I see analogues to my work just on a completely different level.

Before we go offline this is the last stream we are doing this year but next year I already have a pipeline of loosely coupled till the end of February so there's some interesting talks coming up.

First one on the docket is with Chris Simon.

We're going to be talking about the living language.

So we're going to be talking about how to maintain and how to work with a living language or a ubiquitous language from domain-driven design how to make it maintainable and how to keep using it without sprawl and deviations that would be harmful to our organisations.

I think this is going to be quite a challenging and interesting conversation to be had.

And that's on the 14th of January so we're taking a little bit of a break over the holidays and New Year to reset and do some other things than live streaming here.

And that said, again Luca, thank you for your time.

Thank you for joining us in this lovely last session of the year.

Happy holidays.

Happy holidays to everyone that is listening to us and they are listening also to the recording.

So happy holidays to you and your family.

I hope that you have a good one and a relaxing one.

So yeah, thank you again for having me.

It's been wonderful to have you and everybody happy holidays and happy New Year.

See you next year.