They're only 2.5 developers -- .5 because one of their juniors is practically useless. The reason they went with it is because the "senior" in charge wanted to experiment, which can be all well and good in certain contexts, but they've had nothing but trouble. Instead of doing the reasonable thing and stepping back and thinking "Okay, solving <very common frontend problem> shouldn't be this hard. Maybe we should rethink this MFE approach", the "senior" just keeps piling more turds on top of their already huge, steaming pile of turds.
Examples: The MFEs(which live in iframes) need to be able to tell the umbrella that a certain keyboard shortcut was pressed. Normally this would just be an `addEventListener` call by whatever component is interested.. but with iframes it's not that simple. Solution? Capture every keystroke in the application in all the MFEs and send them, as JSON, over your custom messagebus.
Because they use graphql(with apollo client), every graphql request should be cached and you can set up "rules" to do optimistic mutations and whatnot. You should be able to show a lot of UI instantly to the users because you already have data cached. But the caching obviously doesn't work across iframes.. so they tack on yet another hacky solution to transport the cache across iframes sometimes when it's necessary.
Anyway, the point isn't to rant about this specific scenario forever, but rather explain how fucking awful MFEs can be when you make the wrong decision. They are very obviously building a monolith and MFEs should never have been considered, even if you don't look at the team size of 2(which is enough to make the decision ridiculous on its own). I honestly don't think there are any real use cases for MFEs outside absolutely massive organizations working on very specific kinds of products.. maybe stuff like cloud platform management UIs.