Micro-front ends in Webpack 5
github.com
github.com
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.
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].
Another problem is tracking down inter-component bugs, especially if the code is behind a repository. How am I to make small tweaks? Bleh!
I haven't digested what Webpack 5 is doing, but I'm skeptical, mostly because I don't like Webpack's plugin implementation.
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-...
Maybe that's the reason that I find serverless more promising.
And scalability seems like an incremental benefit at best. If you're cpu bound you can load balance without microservices. And if you're database bound (and have already cached, optimized, and scaled up your db) you can scale up your db to multiple instances. Even Stackoverflow runs their entire infrastructure on just 4 db machines.
There are plenty of problems and challenges with microservices, but that rant makes no sense at all. The blogger does not understand the upside of running separate processes? And then although he presents himself totally oblivious to the problem somehow asserts that "programming languages give us all we need to encapsulate state and environment", claiming that any shortcoming is due to people doing it wrong?
Quite frankly, that article is just a rant devoid of any rational point, and it surprised me how it has been presented as some sort of argument on an entire architecture style.
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.
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 :)
Automagically installing dependencies that it fails to `require()` seems way out of scope for a bundler. Or managing Rust toolchains. Or a bunch of hard-coded rules that hard-exclude compiling stuff in `node_modules`. Unless they're in symlinks (presumably for Yarn workspaces?). And so on.
I started with Grunt. Then came Gulp, webpack, and a couple of others. They all do pretty much the same thing, and yet apparently someone has come up with a new one called parcel.
Do they do this shit to make nice CV's so they can land FAANG jobs?
Everything was easier back when we used to use FTP to upload CSS and JS files to sit alongside index.html or index.php.
EDIT: I just googled and the first result is parceljs.org, but that one is blank with a BLM logo on it. Is there another site?
Personally, I'm looking forward to implementing this at work, but I don't think I'll ever touch it for my personal projects.
I do wish there was a middle ground where you could use 90% sane defaults and customize the other 10% without taking on a huge amount of tool-specific baggage. Parcel is great for simple projects, but is not (in my very limited experience over a year ago) anywhere near customizable enough for more advanced use cases.
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.
Luckily they turned it off for new Create React App projects a while back - so at least it shouldn't haunt any new apps.
So yeah, software development fads matter whether you personally follow them or not.
"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.
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 not to diminish the work of the Webpack contributors. I still think it's a wonderful feature, and folks with less messy situations (e.g., for organizations still doing micro-frontends, but everyone's using a single UI framework-- their adoption of module federation would likely have less friction) and thus be worth the effort.
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.
Could be just my limited experience, though.
> 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.
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...
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...
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.
No, you don't _need_ to find and install plugins, unless you need it because you're going further beyond than the core use case of webpack.
You're comparing two tools that have different focuses and compare them on the axis of "working out of the box" which some specific use case in mind. Parcel might work out of the box for React, because it was created to provide that experience. Webpack wasn't created for that, but to provide customizations for its users. Of course Parcel is gonna be better at providing that experience
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.