DEV Community

Thoughts about Micro Frontends in 2020

Raymon Schouwenaar on January 02, 2020

Last years I see the term "Micro Frontends" become more common than before. In the world of backend developers, it's already more common to spli...
Collapse
 
pavelloz profile image
Paweł Kowalski • Edited

Every time i see "microfrontends" it feels like something very hype'y that in 5 years time we will be reading a post-mortems about how it really sucked, cost a gadzillions of dollars and when it breaks its impossible to pinpoint and fix quickly.

Complexity and abstractions come with a price, and it is usually a very high price to pay - the bigger the team and project, the bigger the price. Ask those who failed at microservices.

Just my gut feeling. Frontend guys trying to do everything that backend guys swallowed last week to make boring day to day job a little bit more exciting doesnt seem like a good idea.

Collapse
 
jsalinas11 profile image
Jordan

Well I disagree. We've used microfrontends where I work for about a year and a half now. It has really simplified my job. Apps are significantly smaller which means significantly less complex. There's a much lower chance of breaking anything. And it forces us to write clean reusable components. No more insane spaghetti code monoliths.

Collapse
 
pavelloz profile image
Paweł Kowalski

Thats why i wrote in 5 years, because usually architecture nightmare blows up in a longer term, not 1 year.

PS. Im pretty sure 10 small spaghetti apps will be worse to maintain than 1 spaghetti app, but what do i know ;)

Thread Thread
 
jsalinas11 profile image
Jordan

I guess I don't see your point. You're just staying an opinion, which is fine, but it seems baseless. You're saying a microfrontends is more complex than a monolith. I disagree. Having done both I'd say microapps are much easier to develop and maintain. Pulling them together isn't very hard either. Have you used single spa?

Thread Thread
 
pavelloz profile image
Paweł Kowalski

This sums it up well.

arch

If dev dont know how to write code, dev will make 💩 in any architecture.
The complexity on top of micro* will create additional mess that will be harder to handle.

Problems with architecture are long-term and surface after some team rotation, legacy code creation, test neglecting, etc. But you have some years until then, so dont worry ahead of time ;-)

Thread Thread
 
jsalinas11 profile image
Jordan

So your argument is that bad devs write bad code? ... Alright well I'm gonna bow out of this one. Unless you have a more substantive argument.

Collapse
 
fasani profile image
Michael Fasani

Can you elaborate more on how you split your frontends, just high level, do you do it by feature or by some other method?

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 ...

Collapse
 
lamhieu profile image
Hieu Lam

If you're interested in Micro Frontends, I think you should check out Nuz!
Nuz is a fancy library to implements Micro Frontends compatible with ReactJS and may support more in the future. 🏃 Nuz is in beta! 🧪
Github github.com/lamhieu-vk/nuz

Collapse
 
florianrappl profile image
Florian Rappl

Great post Raymon!

Maybe you can include Piral in the list.

Collapse
 
fasani profile image
Michael Fasani • Edited

Hey Raymon, thanks for sharing, I am in the process of implementing micro frontends in my current company so I am gathering a lot of data right now. Thanks for the links.

Collapse
 
stylet profile image
Vlad Fedosov

Hi! Great article! You may also mention that Namecheap uses micro frontends with ESIs currently & recently we rolled out a solution for isomorphic micro frontends github.com/namecheap/ilc