As someone who builds reasonably large web apps for a living, this list doesn't really address anything that's specific for large scale. Separation of concerns, a common API layer, tests, linters and etc are the baseline of good development today, not something to consider only for bigger projects.
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.
It very much comes off as a marketing piece. Heck, the name of the company splashes the page for several seconds before you even see the article. They say some things that aren't really wrong but also aren't really interesting, and it makes them sound like they Really Know What They're Talking About so that you'll pay them to build something for you.
The article does not mention what the author means by “scaleable” projects. Scaleable in terms of the codebase being used by tens or hundreds of apps? Scaleable in terms of tens or hundreds of developers working in the same codebase? Scaleable in terms of millions of users with different hardware and devices using the web sites?
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 hate to sound elitist or whatever, but I’m just tired of seeing a blog title something about writing a scalable or “enterprise” web app and the content almost always being “write modular code, write comprehensive tests, and don’t write spaghetti code though usually through the veil of domain drive design jargon (whether or not they don’t use the term DDD or they are literally quoting Dr Bob blog posts and including vague graphics showing the “boundaries”). But, any decent developer will literally come to the same realizations after spending a significant amount on anything that’s not a toy/pet project. I also get that not everyone has had that realization and this blog may be insightful/helpful to them, it’s just not the content I was hoping to come across as it’s something I’m very interesting to hear what others are doing.
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 thought this one might be about microfrontends. It was not...
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.
I've seen many authors bring up micro frontends recently, but I haven't seen anyone address size overhead. In modern web apps, third party dependencies can easily be the bulk of your final deliverable volume. With micro frontends and complete separation, this overhead cost can easily end up being paid multiple times. How does your project address this?
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).
We make heavy use of peer dependencies, so microfrontends rarely end up actually bundling their own dependencies. Build tools like rollup help with that.
It’s not a silver bullet and requires A bit of overhead. I’m interested too to hear how other people manage the problem.
That is true, however one of the main arguments for micro frontends is the freedom to use anything: one team can use React, the other Vue, one uses this table library, the other another. If you don't do that, micro frontends offer very little in benefit as far as I see. If you do do that, what you're left with is pretty much regular architecture, just in separate repos and harder to keep in sync.
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.
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.