I am Software Developer, currently interested in static type languages (TypeScript, Elm, ReScript) mostly in the frontend land, but working actively in Python also. I am available for mentoring.
I believe microfrontends has only sense if the project/projects is so huge that we don't deal with "micro" but with frontends already, for example web app like Facebook most probably has separated FE services which they deploy separately, but this is exactly frontends case.
I am developer many many years, most applications I was doing were monoliths in the server and in the front-end. Maybe few of these applications really needed separated services at the BE, for few of them it was natural to make some service outside the core, I will repeat again - natural, and not forced. For me saying that microservices are the best solution for the BE is generalization. You can have system for which it will be best solution, but its not common.
Sorry, but it hard for me to imagine that microfronteds should be used. I think they shouldn't be used until we have very rare situation where the benefit is higher than the cost. And for all small, middle-size applications and even most big ones it will never happen.
Still thank you for informative content. I also will leave this here:
Exactly. Stop making simple CRUD apps as microservices from day one. You will probably never need to scale this app to the level not achievable by monolith. twitter.com/GeePawHill/sta…
20:39 PM - 22 May 2020
GeePaw Hill
@GeePawHill
And hence my advice: before you leap to microservices or serverless or clouds, get your making strong enough to maximize what can be done in simpler architectures. When you hit the real limits of the monolith, your making and your makers will be strong enough to make the change.
Your comment makes it sound like I wrote "you should use microfrontends everywhere" which could not be further from the truth.
If you watch any of my talks on YouTube you will also hear quite often that microfrontends are a solution to a specific problem. Just like microservices you should not use them unless you are sure that they give you benefits. There's always a trade off and there's no silver bullet.
If your problem is solved with a simple static HTML page -> go for it. If you need no more than a server-side rendering -> go for it. If a simple SPA does it -> great. Here its all about options - not about forcing you into anything.
To Florian's point, MFE shouldn't be used all the time, and same with microservices. Monolith still certainly has a place in the world of applications.
Though I have to strongly disagree with the 'shouldn't be used' ideology. My ecommerce organization is in a position to benefit greatly from this, we have data coming in from a dozen different channels, and the web environment is just another channel, but it draws over half a million unique users a day. Our front end team is among a mobile team, integrations team, a couple purpose-built enterprise solutions teams, and more. Our team has grown to over 30 developers working on 5-6 parallel projects on a monolith application, and it's absolute hell to manage releases.
I am Software Developer, currently interested in static type languages (TypeScript, Elm, ReScript) mostly in the frontend land, but working actively in Python also. I am available for mentoring.
I wrote "shouldn't be used until..." so please don't take out sentence from the context. I said there are use cases, and exactly in bigger projects where monolith starts to be a problem. Great to hear that it works for your project.
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.
I believe microfrontends has only sense if the project/projects is so huge that we don't deal with "micro" but with frontends already, for example web app like Facebook most probably has separated FE services which they deploy separately, but this is exactly frontends case.
I am developer many many years, most applications I was doing were monoliths in the server and in the front-end. Maybe few of these applications really needed separated services at the BE, for few of them it was natural to make some service outside the core, I will repeat again - natural, and not forced. For me saying that microservices are the best solution for the BE is generalization. You can have system for which it will be best solution, but its not common.
Sorry, but it hard for me to imagine that microfronteds should be used. I think they shouldn't be used until we have very rare situation where the benefit is higher than the cost. And for all small, middle-size applications and even most big ones it will never happen.
Still thank you for informative content. I also will leave this here:
Thanks and totally agreed.
Your comment makes it sound like I wrote "you should use microfrontends everywhere" which could not be further from the truth.
If you watch any of my talks on YouTube you will also hear quite often that microfrontends are a solution to a specific problem. Just like microservices you should not use them unless you are sure that they give you benefits. There's always a trade off and there's no silver bullet.
If your problem is solved with a simple static HTML page -> go for it. If you need no more than a server-side rendering -> go for it. If a simple SPA does it -> great. Here its all about options - not about forcing you into anything.
To Florian's point, MFE shouldn't be used all the time, and same with microservices. Monolith still certainly has a place in the world of applications.
Though I have to strongly disagree with the 'shouldn't be used' ideology. My ecommerce organization is in a position to benefit greatly from this, we have data coming in from a dozen different channels, and the web environment is just another channel, but it draws over half a million unique users a day. Our front end team is among a mobile team, integrations team, a couple purpose-built enterprise solutions teams, and more. Our team has grown to over 30 developers working on 5-6 parallel projects on a monolith application, and it's absolute hell to manage releases.
There is definitely a use-case for this.
I wrote "shouldn't be used until..." so please don't take out sentence from the context. I said there are use cases, and exactly in bigger projects where monolith starts to be a problem. Great to hear that it works for your project.