First of all, great post and a long one.. :). I'm beginning to explore micro-frontends and this really helped a lot. From my experience as an enterprise architect, I would say, 1. Having a core team for the host is a must like you said. 2. I really don't think having multiple frameworks will ever work, it's just too much complexity for data sharing, performance etc. I believe you will lose all the time saved doing micro frontends by fixing those bugs!! I'd rather stick to a single framework..:)
Lead for JavaScript e2e DX at Microsoft Azure. ex-Architect at MongoDB. ex-Principal Architect Adobe Stack at Cognizant. GDE for #Angular and #WebTechnologies Opinions my own.
Education
The Internet
Pronouns
she/her
Work
Principal JavaScript e2e DX/Dev Tools Lead @Microsoft Azure
👨🏫 Co-Founder of This is Learning, Organizer of AarhusJS
✍️ Writer, Speaker, FOSS Maintainer 📗 Author
🏆 Microsoft MVP 🌟 GitHub Star
🌊 Nx Champion 🦸 Angular Hero of Education
I strongly agree. If you're going to use the same framework, a well-structured monorepo will help you a lot more. It should allow teams to work in isolation, only test, build, and deploy according to what has changed in their commits. It should guard them from making deep imports.
The only real use case for most organizations in my mind is if feature modules are not known at build time. JavaScript itself is very dynamic and even allows arbitrary dynamics imports. Out build tools and compilers are the issue here. Recently, a build tool provided a solution for a problem it introduced itself. Webpack Module Federation. This is just scratching the surface. Microfrontends bring a lot of complexity and challenges as mentioned in this insightful article.
Lead for JavaScript e2e DX at Microsoft Azure. ex-Architect at MongoDB. ex-Principal Architect Adobe Stack at Cognizant. GDE for #Angular and #WebTechnologies Opinions my own.
Education
The Internet
Pronouns
she/her
Work
Principal JavaScript e2e DX/Dev Tools Lead @Microsoft Azure
First of all, great post and a long one.. :). I'm beginning to explore micro-frontends and this really helped a lot. From my experience as an enterprise architect, I would say, 1. Having a core team for the host is a must like you said. 2. I really don't think having multiple frameworks will ever work, it's just too much complexity for data sharing, performance etc. I believe you will lose all the time saved doing micro frontends by fixing those bugs!! I'd rather stick to a single framework..:)
Thank you! and ....Exactly!!! Which then makes you really wonder if you truly need microfrontends in the first place :D
I strongly agree. If you're going to use the same framework, a well-structured monorepo will help you a lot more. It should allow teams to work in isolation, only test, build, and deploy according to what has changed in their commits. It should guard them from making deep imports.
The only real use case for most organizations in my mind is if feature modules are not known at build time. JavaScript itself is very dynamic and even allows arbitrary dynamics imports. Out build tools and compilers are the issue here. Recently, a build tool provided a solution for a problem it introduced itself. Webpack Module Federation. This is just scratching the surface. Microfrontends bring a lot of complexity and challenges as mentioned in this insightful article.
100% agreed, Lars. Monorepos are definitely the way to go!