DEV Community

Discussion on: Thoughts about Micro Frontends in 2020

Collapse
 
florianrappl profile image
Florian Rappl

This is wrong. Just to elaborate why: Certainly we will read these post mortems - we read them about microservices, too. The reason is not that microservices suck, but that the pattern has been applied by the wrong people and / or for the wrong reasons.

The same is true for microfrontends. They are not for everyone. If everyone uses this pattern then something is wrong. It's just another tool and people should finally stop thinking in terms of "only X is best".

If your problem can be solved with a monolith then you should go for it. That's true on the backend and remains true on the frontend.

Collapse
 
pavelloz profile image
Paweł Kowalski • Edited

Those post mortems also usually mention couple things that apply specifically to micro* things:

1) devops is much more expensive
2) deploys are harder
3) debugging is harder
4) rollbacks are harder
5) architecture is much more complicated, ergo more error prone and when SHTF in one of them, usually most of the things are down
6) pool of devs that can work on it is much smaller, because not everyone is interested in banging head against docker for a day every month when someone changes something somewhere (especially frontend devs dont like it)
7) logging is harder and more expensive (usually need external service to aggregate)

... and many more.

So, as famous Aaron Patterson said... "But at what cost?"

IMO If you dont have enterprise human resources (why enterprise? because they are a waste machines and they dont care), its just huge mistake to divide to micro*, especially micro frontends.

Thread Thread
 
florianrappl profile image
Florian Rappl

Some of these things either make no sense or only sense when a particular set up is found.

Independent of these specifics I guess you missed the main point of my post: There is no silver bullet. Obviously, microservices come with some drawbacks - so do microfrontends. But monoliths also come with drawbacks.

In other words:

Choose your architecture wisely knowing what it takes work from you and also where it requires work from you.

Don't think in black and white. Choose what makes sense when it makes sense ...