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