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.
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.
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?
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 ;-)
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.
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.
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 ...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
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.
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 ;)
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?
This sums it up well.
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 ;-)
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.
Can you elaborate more on how you split your frontends, just high level, do you do it by feature or by some other method?
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.
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.
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:
Don't think in black and white. Choose what makes sense when it makes sense ...