Principles of scalable front end projects
bornfight.com
bornfight.com
What I've dealt with over the years, and would've loved to see addressed, is questions that are actually specific to projects at scale. Having hundreds of views, how do you classify and manage components? How do you manage shared components? How to achieve (and keep) architectural consistency across thousands of components? How do you address death-by-a-thousand-cuts performance regressions in big web apps? And so on. Sadly, this article doesn't address any of these.
My guess is that it is “scaleable in terms of a team of 10-20 developers working on the same codebase”. The practices are fair in this sense, though I’m a bit unsure on the specific library recommendations and why they are better than the alternatives not listed. I was also missing things like tooling om test coverage - and agreeing with the team on how to go about this - or code review practices and enforcing (or not enforcing) this.
When it comes to scaling for millions of users, things like monitoring, alerting, logging, measuring performance in smart ways are things that also need to be done.
I happen to head up a web team who is building “scaleable” web apps in this latter regard (we have millions of monthly paying users around the globe whom we need to scale for) and I’ll write up the additional practices we use to “scale” with w small team in a later post on my blog [1] for anyone interested.
I’m not going to pretend I’m some hardass enterprise engineer, but my only time spent on frontend work these days are on two different applications that solely exist because the actual enterprise software sucked so much that these applications exist. So, I like to think I at least have an idea. As over the years the features have been added to the apps, and more of the “fun little quirks” in the data. Which is why I want to hear how real “enterprise” level frontends are being handled. Believe me, I know the value of keeping my code modular, and I really know the value of keeping logic out of presentation, but if working with enterprise software, and software that’s deployed to 30+ different departments to standardize and centralize processes they’ve been doing themselves for 50+ years (under the guise of “making their jobs easier” but really they central office where just tired of having to deal with the random of assortment and varying quality of data, lol) there’s always another edge case. I cringed when they mentioned that using one of the big frameworks, and forgoing global styles, because after a couple years of “the frameworks built in css isn’t totally the way we need it” (or more likely, “fucking updates broke the UI on a minor release for no reason”) or “oh using the current components we use to do that don’t take data that way or return it the way we need either, and it’d take too long to replace, just create a new set for this feature” it’s not going to be the nice paradise where everything is siloed off just like in Uncle Bob’s blog. I just this week got sick of UI framework’s because the built in component I needed wasn’t able to handle the task in the exact right way, so I had to make adjustments to it, and I’m just that’s never going to break in the future... not to mention that absolutely none of them are really doing any more than the bear minimum accessibility wise, which is one of the reasons to use a framework was to eliminate that boilerplate. So, I just started tinkering with the new Vue3 composition API to build a UI framework that literally has no styles attached just dom elements that know how to setup their aria-attributes, handle keyboard events so a mouse isn’t the only method, etc (as well as if they weren’t passed given enough information to make themselves complaint with the aria guidelines). To style them, I’m just going to make pass in a list of tailwind classes in a config files at build time, that they can (optionally) but will in no way the actual core framework itself is dependent on.
I just want to hear how some real enterprise team are managing their frontend (and more importantly their commentary — I can find code online but without the context it’s not the same) when they have 100x the amount of edgecase legacy bullshit I have to deal with and likely 1000x the burden of buroqracey
I have thought about a changelog and inclined to like it, but I haven't come across a strategy to have a good changelog structure.
This allows adding metadata such as dates, descriptions, authors, type, etc. without much hassle.
This requires investing in some own CLI tooling, since creation and rendering should be automated for this.
We are currently working on a solution for this problem (scalable SPA where multiple teams can develop and deploy independently). Its been used by some of our clients for quite a bit now. Their dev teams seem to like it so far.
If anyone is interested our GitHub repo is at https://github.com/smapiot/piral - thanks!
It’s not a silver bullet and requires A bit of overhead. I’m interested too to hear how other people manage the problem.
Most our projects where microfrontends have been actively demanded (and we did now quite a lot of them) did not come up due to use of multiple frameworks. Yes, it is possible to use multiple technologies, but quite often there is key technology in place anyway. E.g., one of our clients had a huge pattern library written in React and demanded all microfrontends to be written in React.
So why then microfrontends at all? Well, all parts are still independent from each other, i.e., independently developed and deployed. Our client has multiple teams and like that these teams can just work in their own pace using a few guiding principles that have been given by the solution architecture.
Agreed, the only mention of using different technology has come up in the current project is in discussions of Typescript vs plain JavaScript. That’s been the only bring-your-own-technology for the most part, since we’ve standardized on React and some shared libraries like Lodash.
We’ve primarily benefitted from the forced feature and team isolation (aka domain boundaries if you would), plus it gives teams more granular control over their deployments. So, pretty much just what you described.
Another benefit has been our ability to build once and share features across different applications, since we have a few of those for reasons. Teams can build out different “views” (roughly) for different use cases on different apps which share the core functionality.
You can either use shared dependencies from the app shell or share dependencies independently from your microfrontends using import maps. The former involves additional responsibility on the app shell side (dangerous) the latter potential overhead in case of unaligned dependency versions (then these are loaded multiple times).