I had thought microfrontend kills the efficient development by sharing components (and CSS). However he told me that microfrontend is not for efficient development but for scale and innovation. It gave me a wake up. Great speech. Thank you.
Thank you for the presentation, it makes a lot of sense. The only thing that doesn't quite add up is the fact that you go against having a shared component base. We actually have a team that is dedicated in making the basic building blocks for all the organizations worldwide. But how you presented your architecture was that this (shared components between frontends) actually hinders productivity? Itd be great if you could elaborate on this. Thank you!
yep sure, in distributed teams having a team owning a shared library used by all the other teams could slow down the productivity. if you are going to share code you need to be very well aware where it is used, who is owning and so on. We are currently working on a design system shared for all the micro-frontends but we are defining some rules like avoiding business logic and trying to keep as primitive and composable as possible allowing each micro-frontend to implement them easily in their business logic. Happy to have a deeper chat if you want, just drop me a line if you want :)
Nice presentation ! we are also building the microfront end but with diffrent approch. by the way which template you use to make this presentation may I know please :)
Yes, but it's a tradeoff. If you have one lib to rule them all micro Frontend when you want upgrade you will get real pain. Cause you create coupling and each team need to be ready for the upgrade
Eugeniu Rata the code of our platform is not available open source. It’s not only theory, there is a concrete example available online and used by millions of users. I believe having a concrete example in production is more valuable than a POC in a git repository.
While i think that scalability and innovation is clearly higher when you do not even share any UI components, i think it is very bad for your user experience. Not only do you have to synchronize all kind of components all the time (buttons, calendar, cards, form fields, really if it only would be a header and footer i would not mind), but also the user has to download everything several times during using your application. not to talk about how often the user might need to download the same asset e.g. a font file or the big icon spreadsheet. Just think about yourself and how much you as a user love it that apple has everywhere the same user experience and the same components. Or how twitter interactions are completely different if i use it in the browser on desktop, mobile or the native app versions of the application. (try yourself to share & save a tweet. every time I think i know it, i am pressing the wrong interaction possibility)
not sure if you've heard about it, but a well made design system addresses this problem. there are also great tools (such as storybook) that you can use as the source of truth/documentation for your components.
@@MultiPlexiglas Since the time of that talk, I did further researches on design systems and micro-frontends, they are definitely applicable and I'm going to share more in a future post
@@My50c I do wonder if micro frontend approach makes more sense when the brand style guide and design system is more mature. When the project is still in discovery and don’t even know what to include in the navigation header, what are the common components and patterns in the design system etc, might end up each micro frontend team coming up with their own design system and running in different directions for the same product?
In about 10 years the new developers will be destroying this approach saying " who make this cr**p", I personally don't like it the fanatics destroy the simplicity of the front end, before was the more simple part of a system now is a hell of libraries forcing something to be what is not, stop the micromadness please
Exactly. In fact, micro frontends is the latest thing you want to work with in real life. Here's a path of product transformation: 1. A single modular monolith app for all users (you start here as your your team is small, business domain is blurry yet, design is evolving and changing too often) 2. Multiple modular monolith apps per target audience + common UIKit (optionally) (you make this evolutionary step once your design has stabilized, business domain is clear, team size has grow and you can split into few teams and work on products per well-defined audience) 3. Anything else to avoid micro-frontends... 4. Micro-frontends (you'd better find another job 🙂)
I had thought microfrontend kills the efficient development by sharing components (and CSS). However he told me that microfrontend is not for efficient development but for scale and innovation. It gave me a wake up. Great speech. Thank you.
For design, you can share a UI KIT between MFE.
Micro frontend is the silver bullet for applications with multiple developers working at the same time. Amazing talk, so clear.
Haha, just check What Are Micro-Frontends & How to Use Them • Luca Mezzalira & Lucas Dohmen video at 7:38. 😁
Ótimo vídeo
Luca, thank you so much for this!
16:00 DAZN implementation
25:00 Microfrontends Frameworks
Great presentation. Thank you Luca.
Thank you so much, Luca! You make me more clear about it.
Great speech. I liked the decisions made for dazn microfrontend arch.
interesting thoughts !
it was incredible
thank you for such informative presentation
Amazing talk. Very informative on MFEs
loved the presentation.
Glad you liked it!
Great presentation ! Thank you
Amazing talk!
Thank you for the presentation, it makes a lot of sense. The only thing that doesn't quite add up is the fact that you go against having a shared component base. We actually have a team that is dedicated in making the basic building blocks for all the organizations worldwide. But how you presented your architecture was that this (shared components between frontends) actually hinders productivity? Itd be great if you could elaborate on this. Thank you!
yep sure, in distributed teams having a team owning a shared library used by all the other teams could slow down the productivity.
if you are going to share code you need to be very well aware where it is used, who is owning and so on.
We are currently working on a design system shared for all the micro-frontends but we are defining some rules like avoiding business logic and trying to keep as primitive and composable as possible allowing each micro-frontend to implement them easily in their business logic.
Happy to have a deeper chat if you want, just drop me a line if you want :)
I still didn't see your micro frontend architecture....
Thats great
Nice presentation ! we are also building the microfront end but with diffrent approch. by the way which template you use to make this presentation may I know please :)
very informative
Won’t components/libraries be duplicated across micro frontends increasing file size and negatively impacting performance?
Yes, but it's a tradeoff.
If you have one lib to rule them all micro Frontend when you want upgrade you will get real pain. Cause you create coupling and each team need to be ready for the upgrade
With tree-shaking in place , bundle size may not be too much but with the advantages that micro front ends bring .. I think that’s ok
Good introduction to the micro front end architecture. Waiting for more deeply ones, with a view of a real architecture technical challenges
He is releasing a book about it
Amazing Talk 😉 Are the slides of this talk available?
Here the slides docs.google.com/presentation/d/1pHVTfsClopppz3aL6eV75LxGxU-mVhoyIgamTdeYdkw/edit?usp=sharing
where can I see the actual implementation of your approach?
www.dazn.com if you are in a country where DAZN is available
@@My50c no, I meant the source code, otherwise why speaking some much theory without any concrete sample, that's the worse a developer can get :)
Eugeniu Rata the code of our platform is not available open source.
It’s not only theory, there is a concrete example available online and used by millions of users. I believe having a concrete example in production is more valuable than a POC in a git repository.
I might be little late. But here is a good talk : th-cam.com/video/ftBc8w-lwmY/w-d-xo.html
While i think that scalability and innovation is clearly higher when you do not even share any UI components, i think it is very bad for your user experience. Not only do you have to synchronize all kind of components all the time (buttons, calendar, cards, form fields, really if it only would be a header and footer i would not mind), but also the user has to download everything several times during using your application. not to talk about how often the user might need to download the same asset e.g. a font file or the big icon spreadsheet.
Just think about yourself and how much you as a user love it that apple has everywhere the same user experience and the same components. Or how twitter interactions are completely different if i use it in the browser on desktop, mobile or the native app versions of the application. (try yourself to share & save a tweet. every time I think i know it, i am pressing the wrong interaction possibility)
not sure if you've heard about it, but a well made design system addresses this problem. there are also great tools (such as storybook) that you can use as the source of truth/documentation for your components.
@@fernandolucchesi i m building living Design systems since a couple of years. But as i understood the talk, it was advertising against it.
Yeah you are right, I misunderstood your first comment... doesn't look like we can have the best of both worlds yet =/
@@MultiPlexiglas Since the time of that talk, I did further researches on design systems and micro-frontends, they are definitely applicable and I'm going to share more in a future post
@@My50c I do wonder if micro frontend approach makes more sense when the brand style guide and design system is more mature. When the project is still in discovery and don’t even know what to include in the navigation header, what are the common components and patterns in the design system etc, might end up each micro frontend team coming up with their own design system and running in different directions for the same product?
Seems like a development hell
In what way? The separation means that developers can work without dependencies. What challenges do you see?
Tom Segura has really changed his content.
When Tom was asked to do a Netflix special he went down a really long rabbit hole 😂
Grüße
In about 10 years the new developers will be destroying this approach saying " who make this cr**p", I personally don't like it the fanatics destroy the simplicity of the front end, before was the more simple part of a system now is a hell of libraries forcing something to be what is not, stop the micromadness please
Its all theory theory and theory in every video... no real examples sadly
Exactly. In fact, micro frontends is the latest thing you want to work with in real life.
Here's a path of product transformation:
1. A single modular monolith app for all users (you start here as your your team is small, business domain is blurry yet, design is evolving and changing too often)
2. Multiple modular monolith apps per target audience + common UIKit (optionally) (you make this evolutionary step once your design has stabilized, business domain is clear, team size has grow and you can split into few teams and work on products per well-defined audience)
3. Anything else to avoid micro-frontends...
4. Micro-frontends (you'd better find another job 🙂)
Yeah, yeah, yeah, you have this, you have that, you have investors, but you have no customers.