5 ms·

We already kind of solved this problem at IMDb using Webpack 3 and 4 (with tons of hackery). It was, all things considered, a terrible idea. We ended up with a

by mmmeff 6y ago

We already kind of solved this problem at IMDb using Webpack 3 and 4 (with tons of hackery). It was, all things considered, a terrible idea. We ended up with a web page with 10 nearly identical sections implemented 10 different ways by 10 different developers across 10 different git repositories. Micro-frontends are cancer, please don't fall for it. You can get much more done for less with a single webserver and a graphQL service, not matter your project's scope. No front-end on earth needs multiple teams to build it - if it does, your product is convoluted and needs to be split up and/or simplified.

throwaway888abc 6y ago
I don't understand anything here about the microfronted. Why would you do that ? You can already share and resuse components, modules, stores, functions ? What I don't see here ?
- smessina 6y ago
  The use case I've seen is for iteratively moving away from a legacy system. Say you have monolithic front end and you want to move to a new framework/version/etc. Instead of rewriting the whole app, you can approach it feature-by-feature and slowly replace the legacy app, Ship of Theseus style[0]. [0]: https://en.wikipedia.org/wiki/Ship_of_Theseus https://en.wikipedia.org/wiki/Ship_of_Theseus
  - throwaway888abc 6y ago
    Thank you
  - adamredwoods 6y ago
    This is exactly what we're doing now. Some of the problems we've seen thus far is how to maintain packages but allow for high-iteration development. It is cumbersome using a packaging service, so at best it's being able to decide what to keep in a shared rep, versus things that are being rapidly developed in it's own rep. Any component that needs specific tweak then becomes duplicated and sadly, code-reuse and maintainability suffers. Another problem is tracking down inter-component bugs, especially if the code is behind a repository. How am I to make small tweaks? Bleh! I haven't digested what Webpack 5 is doing, but I'm skeptical, mostly because I don't like Webpack's plugin implementation.
- ratww 6y ago
  > You can already share and resuse components, modules, stores, functions? You're absolutely right that we can, but the issue is that most teams are too large or too disorganised to share complex codebases, so they choose to do a hard division: splitting the code itself. Here's an argument that I love: Microservices and microfrontends are (most of the time) a failure of encapsulation [1]. Of course there are other benefits, such as separate deployment processes and ability to use different frameworks. [1] https://michaelfeathers.silvrback.com/microservices-and-the-failure-of-encapsulaton https://michaelfeathers.silvrback.com/microservices-and-the-...
  - k__ 6y ago
    To me, microservices were more about scalability than encapsulation. Maybe that's the reason that I find serverless more promising.
    - rumanator 6y ago
      Sometimes it appears that microservices contrarians are just focused on nitpicking while turning a blind eye to the myriad of advantages that justify their existence and widespread adoption. It's similar to how it's fashionable to criticize Java or C++ just for the heck of it. Sure, the architecture style is not a panacea and there are plenty of downsides and some projects made poor decisions and some evangelists try to make a career selling their snake lard. However, one just need to understand that vertical scaling is not a panacea or effective in reducing latency or providing reliability to understand the need for microservices.
      - JamesBarney 6y ago
        I feel like the debate between the microservices evangelists and the contrarians are "Microservices are a best practice you should almost always use" and "Microservices are a tool for primarily splitting up development teams when they get too large to manage, i.e. a technical solution to an organization problem".
        6y ago
ng12 6y ago
I've had a similar experience. I spent a few weeks hacking with a team to discover what was killing their productivity and it all came down to the early decision to adopt micro-frontends. The only place I can imagine this working is at the very, very top end of the organizational scale: somewhere like Facebook where they have the engineering discipline and know-how to manage hundreds of front-end engineers working on a single application. For every other use case if micro-frontends seem like a good idea it's because something else is going wrong in your development process.
JMTQp8lwXL 6y ago
The last assertion is problematic. A team of engineers can only produce so many pages -- you could reasonably need multiple teams to work on different parts of the product's UI.
joshuanapoli 6y ago
In my company, micro-front ends was appreciated by the development teams involved. It seemed to reduce problems with delivery to production, probably because of splitting up our tests (which were too slow). It is worth noting that we introduced micro-front ends along with a change to the philosophy of the product and also a change to the technology. So our front-ends might be better described as separate applications that happen to be presented to users within a seamless shell.
8agpc 6y ago
We have spoken before. Hashed module ids? Cli that figures it out? I based webpack external import off that. Then rearchitected webpack for MF. IMO MFEs were a cumbersome idea, however the mechanics of module Federation make it hard to locate real issues. 10 repos, likely overkill. However there is a very real use case. I’m working companies that have 300 teams of 20 devs per team and over 50,000 handwritten modules. No matter how efficient you make something. The build still takes 40 min. Your use case sounds like overkill, suboptimal with 10 MFEs that are similar. I’d suggest a monorepo if you’re not bottlenecked.
darepublic 6y ago
I see it coming into play with automated UI building systems

by mmmeff 6y ago

throwaway888abc 6y ago

I don't understand anything here about the microfronted. Why would you do that ? You can already share and resuse components, modules, stores, functions ? What I don't see here ?

smessina 6y ago
The use case I've seen is for iteratively moving away from a legacy system. Say you have monolithic front end and you want to move to a new framework/version/etc. Instead of rewriting the whole app, you can approach it feature-by-feature and slowly replace the legacy app, Ship of Theseus style[0]. [0]: https://en.wikipedia.org/wiki/Ship_of_Theseus https://en.wikipedia.org/wiki/Ship_of_Theseus
- throwaway888abc 6y ago
  Thank you
- adamredwoods 6y ago
  This is exactly what we're doing now. Some of the problems we've seen thus far is how to maintain packages but allow for high-iteration development. It is cumbersome using a packaging service, so at best it's being able to decide what to keep in a shared rep, versus things that are being rapidly developed in it's own rep. Any component that needs specific tweak then becomes duplicated and sadly, code-reuse and maintainability suffers. Another problem is tracking down inter-component bugs, especially if the code is behind a repository. How am I to make small tweaks? Bleh! I haven't digested what Webpack 5 is doing, but I'm skeptical, mostly because I don't like Webpack's plugin implementation.
ratww 6y ago
> You can already share and resuse components, modules, stores, functions? You're absolutely right that we can, but the issue is that most teams are too large or too disorganised to share complex codebases, so they choose to do a hard division: splitting the code itself. Here's an argument that I love: Microservices and microfrontends are (most of the time) a failure of encapsulation [1]. Of course there are other benefits, such as separate deployment processes and ability to use different frameworks. [1] https://michaelfeathers.silvrback.com/microservices-and-the-failure-of-encapsulaton https://michaelfeathers.silvrback.com/microservices-and-the-...
- k__ 6y ago
  To me, microservices were more about scalability than encapsulation. Maybe that's the reason that I find serverless more promising.
  - rumanator 6y ago
    Sometimes it appears that microservices contrarians are just focused on nitpicking while turning a blind eye to the myriad of advantages that justify their existence and widespread adoption. It's similar to how it's fashionable to criticize Java or C++ just for the heck of it. Sure, the architecture style is not a panacea and there are plenty of downsides and some projects made poor decisions and some evangelists try to make a career selling their snake lard. However, one just need to understand that vertical scaling is not a panacea or effective in reducing latency or providing reliability to understand the need for microservices.
    - JamesBarney 6y ago
      I feel like the debate between the microservices evangelists and the contrarians are "Microservices are a best practice you should almost always use" and "Microservices are a tool for primarily splitting up development teams when they get too large to manage, i.e. a technical solution to an organization problem".
      - 6y ago

ng12 6y ago

I've had a similar experience. I spent a few weeks hacking with a team to discover what was killing their productivity and it all came down to the early decision to adopt micro-frontends. The only place I can imagine this working is at the very, very top end of the organizational scale: somewhere like Facebook where they have the engineering discipline and know-how to manage hundreds of front-end engineers working on a single application. For every other use case if micro-frontends seem like a good idea it's because something else is going wrong in your development process.

JMTQp8lwXL 6y ago

The last assertion is problematic. A team of engineers can only produce so many pages -- you could reasonably need multiple teams to work on different parts of the product's UI.

joshuanapoli 6y ago

In my company, micro-front ends was appreciated by the development teams involved. It seemed to reduce problems with delivery to production, probably because of splitting up our tests (which were too slow). It is worth noting that we introduced micro-front ends along with a change to the philosophy of the product and also a change to the technology. So our front-ends might be better described as separate applications that happen to be presented to users within a seamless shell.

8agpc 6y ago

We have spoken before. Hashed module ids? Cli that figures it out? I based webpack external import off that. Then rearchitected webpack for MF. IMO MFEs were a cumbersome idea, however the mechanics of module Federation make it hard to locate real issues. 10 repos, likely overkill. However there is a very real use case. I’m working companies that have 300 teams of 20 devs per team and over 50,000 handwritten modules. No matter how efficient you make something. The build still takes 40 min. Your use case sounds like overkill, suboptimal with 10 MFEs that are similar. I’d suggest a monorepo if you’re not bottlenecked.

darepublic 6y ago

I see it coming into play with automated UI building systems