101–110 of 143 posts
Earlier quoted context omitted.
Until the org chart is reorganized, then what?
Then you reorg the system. Note that this can go either direction - you can also change your system to how you want the org chart to look. Generally it goes one way because engineers rarely have the power to change the org chart, but sometimes we are consulted and can suggest 'improvements'.
Most of the implementations of MFEs I've seen are reliant on webpack or Single-SPA (which by default uses webpack under the hood). vite, esbuild, parcel etc. have not adopted anything around this. To me, that says that those putting out the nuts and bolts work that having been leading this space for several years either haven't spent alot of time evaluating them, or have found them overly complex for what they are, o…
The examples that are publicly available and written about, are in my opinion all suffering from a too low level of abstraction. They are more tech demos of possible implementation options, for such an architecture, but as they are all contrived to demonstrate some mechanism, but the not a single of the examples would be actually justify that kind of architecture. I am working on a MFE shell application for a product…
That feels right.
Another I've been apart of is applying it to a given codebase post acquisition, helps speed up integration in some respects
One example I've seen floated though is remote modules for design systems. This one I'm unsure about. I can only speak from one experience when this was tried and it was a disappointing result.
I think people forget that code in monoliths can be written in a way to set boundaries with namespaces and thinking through class-level API design. Most of the time you can accomplish the same outcome of what a microfrontend might provide inside a monolith. Same is often the case for the backend.
It’s obvious that strong walls have immense cost, but perhaps for a large enough organization it enables faster movement overall with fewer faults. Walls are good after all.
What’s fascinating to me about micro-anything vs. monolith-anything is it’s much more a function of team structure and culture than of technical merit. In some cases, the technically inferior solution can deliver more to the business when combined with the unfortunate realities of human development.
I agree with the original offer that micro-anything should ultimately be considered a failure of better modularity mechanisms.
I am always frowned upon when I describe our product as a monolith with network hops. These just add more network hops, complexity, latency and projects to upgrade every 30 seconds.
Author makes some solid points. I've seen the road from "monolith" to "microservices" that was actually a descent into a quagmire of "distributed monolith" -- it's supremely inefficient. So much more time is dedicated to the churn vs feature development, it's depressing. Wanting to couple that with the JS ecosystem, I don't even want to imagine that.
I think people forget that code in monoliths can be written in a way to set boundaries with namespaces and thinking through class-level API design. Most of the time you can accomplish the same outcome of what a microfrontend might provide inside a monolith. Same is often the case for the backend.
They can, but the walls are not strong enough to perturb those programmers who do not know any better, don’t care, or are under sufficient pressure to sweep aside good practice. Micro-anything is the philosophy based in the presumption that your engineers will not respect softer walls and modules and therefore strong ones must be constructed. It’s obvious that strong walls have immense cost, but perhaps for a large e…
I hadn’t heard of MFEs before but this reminded me of renderings in the Sitecore CMS and the Helix organizational methodology to handle dependencies and coupling.
To me it sounds like they are re-inventing portlets (JSR-168).
I’ve worked on two 100+ weekly committer monoliths and two similar sized MFE architectures. I think the article hits good points though I’d add some acutely painful ones it misses[1]. I’m someone who is by gut now squarely in the pro-monolith camp, but I think that in the comment thread of a similarity anti-MFE article it’s worth steel manning the pro-MFE arguments rather than characterize it simplistically as cargo-…