We ended up with a web page with 10 nearly identical sections implemented 10 different ways by 10 different developers across 10 different git repositories.
Micro-frontends are cancer, please don't fall for it. You can get much more done for less with a single webserver and a graphQL service, not matter your project's scope.
No front-end on earth needs multiple teams to build it - if it does, your product is convoluted and needs to be split up and/or simplified.
The only place I can imagine this working is at the very, very top end of the organizational scale: somewhere like Facebook where they have the engineering discipline and know-how to manage hundreds of front-end engineers working on a single application.
For every other use case if micro-frontends seem like a good idea it's because something else is going wrong in your development process.
Why would you do that ?
You can already share and resuse components, modules, stores, functions ?
What I don't see here ?
Say you have monolithic front end and you want to move to a new framework/version/etc. Instead of rewriting the whole app, you can approach it feature-by-feature and slowly replace the legacy app, Ship of Theseus style[0].
You're absolutely right that we can, but the issue is that most teams are too large or too disorganised to share complex codebases, so they choose to do a hard division: splitting the code itself.
Here's an argument that I love: Microservices and microfrontends are (most of the time) a failure of encapsulation [1].
Of course there are other benefits, such as separate deployment processes and ability to use different frameworks.
[1] https://michaelfeathers.silvrback.com/microservices-and-the-...
Personally, I'm looking forward to implementing this at work, but I don't think I'll ever touch it for my personal projects.
In those cases, you have to understand the rusty sink at least well enough to fix it, and hopefully well enough to assess if it was the right tool for the job, and how to safely remove it if it really wasn't.
A great example of this is actually create-react-app. Many people who have no idea what they're doing start off an app using this toolset and end up with a boatload of things they aren't even aware of, like a half-baked service worker that by default caches the app's code in localStorage to enable offline app functionality!
My own experience with that specific issue was of people building a production system on top of an ejected create-react-app, who ended up with deployment issues where some users arrived to a blank page after some deploys. It just seemed to happen randomly.
It turned out that after some deploys, for some users, the default CRA service worker's cache and the webpack js minify+chunk configuration, and the 404 redirect configuration for firebase, didn't play well together. You could end up with new code calling cached code which requested chunks that didn't exist anymore, and getting served html 404s with status 200, so the cache wouldn't bust properly. Understanding this, debugging it, and solving it safely (in part by safely deregistering the service worker for all users) took ~days!
The really upsetting part is that no one involved in building this app (neither founders nor original create-react-app-running devs) ever wanted service workers, nor a progressive web app offline code cache, nor code chunking, nor optimistic 200-html pages in place of 404s. But those were all default options and packages and stackoverflow copypasta that got cargo culted in, and it produced a bit of a tower of crap.
Where's the Visual Basic 6 of our era? :)
Sure, apps weren't pretty, but you could bang one out in a few days and start getting use from it.
That's why I've devoted my career to tooling, hoping to improve the situation [1]
[1] {cough, cough} https://mintdata.com is where we put our blood, sweat 'n tears as a result :)
> I still don't see how this is going to work
> when the shared modules release breaking changes
If you are working within a singular repository (monorepo), you can make a singular commit that fixes all parts of your application at once, and since it is deployed in one go there will be no breakage in production.
On the other hand, if you have a shared library that affects multiple repositories, somehow everybody needs to do the PR at the same time, and somehow every deploy needs to be synchronised in order that all micro frontends are updated at the same time. How can that be done in a way which doesn't cause breakages? What if one team is slower to update than every other team? What crazy piece of infrastructure might we require for this kind of gradual distributed upgrade?
This almost certainly sounds crazy to most engineers, but at the organisation I work they build quite a lot of App Store style applications which amalgamate 100s of other applications into one gigantic application. Additionally, for some legacy reason, we are tied into using separate repositories for each line-of-business micro frontend.
Could be just my limited experience, though.
In my org, most teams that need it have like one front end dev that's shared among three other teams, and like one or two people who can hammer out some React and don't hate JS to help out with most of the stuff. I suspect this would be an utter madness for that kind of a team.
And yet I feel like I wanna try that for our next project.
This is intended by Micro Front.
Most Billions Dollars SaaS are based on this Frankenstein type of architecture, the goal is simple :
- Support legacy code with Zero Effort
The result for the end user is absolutely horrendous , it create slow and bloated web pages with Megabytes of JavaScript with UI of various style and behavior similar to Confluence/ Jira etc...
This architecture fits perfectly fit the state of the current market :
- Push lots of stuff out "as fast as possible"
- Turn over in software in +20%, people who build Jira 5 years ago aren't there anymore , they cashed in their stocks and went somewhere else to get a bigger paycheck
- The people who build those apps , most of the time , don't use them...
Leaders of Atlassian use Gmail and GDrive , I'm pretty confident that they don't even use Jira or any of their own software...
Those apps are so slow and bloated it's astonishing...Yet when something is the "norm" in the industry , it's definitely not an issue.
Still, parcel is not 100% seamless in the sense that whilst parcel doesn't (generally) require plugins, you do still need to add/install regular file type dependencies. "typescript" for .ts files, and "sass" for .scss files and so on.
If that's given, "micro" creates a compound noun that comes with a dash. Hence, micro-front end. Whether it's correct, that, I strongly suspect, depends more on your style guide than anything else.
As far as I'm concerned, whatever makes the technical writer happy is good for me...
"We couldn't agree on a programming language, framework, or set of common development practices, so everyone gets their own individual silo and never has to worry about what everyone else is doing."
Does anyone pay attention to the organizational problem that underlies all of this? You have to agree as a team on this stuff. Microservices is not a way to solve a technical problem, but a way to bandaid an organizational/people problem. You simply couldn't get 2 different front-end or back-end teams to agree on some policy or framework, so now you put an explicit rift between them with this microservice bs.
We did monolith->micro-services->monolith. I will rewrite a system from scratch before i put it into a leaky box and try to wrap an API around it ever again. You can try to sell this as some sort of way to migrate away from legacy without rewriting code but that is a bullshit siren song that is never true in any reality. You will likely save more time over the long haul building 1 coherent system (both frontend and backend). Keeping legacy around and pushing it further and further into container inception is not a rational technical solution if you actually want to pay down your technical debt at any point.
Whats being proposed here are dynamically linked shared libraries, they expose some functionality & also consume dependencies (that may be shared). Theres no need to be talking about containers, federation, orchestration etc...
We've been able to achieve this to good effect using Webpack 4 with some hackery (https://www.matthinchliffe.dev/2020/06/03/taming-webpacks-co...) but I'd love to be able to point to something documented and official instead... this sort of looks like it might meet this need. Fingers crossed.