3 ms·
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 pos
by fabianholzer 3y ago
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 (or rather a suite of closely related applications/products), that need to be presented to the users as a single system. Ballpark figure of the business unit 400+ software developers and 80+ modules/sub-products.
I think the MFE architecture was a justified trade-off, given our organizational structure and product landscape, but one should be very cautious if it is presented as a some kind of default solution.
- no_wizard 3y agoThat is what I think MFE is meant for, where you have entirely different parts of an organization working on an application but you need it to feel the same to the user. 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.