Principles of scalable front end projects
bornfight.com
Principles of scalable front end projects
1–10 of 18 posts
Re: Principles of scalable front end projects
#2> 10 — Keeping a changelog
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.
Re: Principles of scalable front end projects
#3The 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.
Re: Principles of scalable front end projects
#4And apparently principle zero is make scrolling janky for some godforsaken reason.
Re: Principles of scalable front end projects
#5As 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.
Re: Principles of scalable front end projects
#6I 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.
If anyone is interested our GitHub repo is at https://github.com/smapiot/piral - thanks!
Re: Principles of scalable front end projects
#7I 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. If anyone is interested our GitHub repo is at https://github.com/smapiot/piral - thanks!
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?
Re: Principles of scalable front end projects
#8I 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. If anyone is interested our GitHub repo is at https://github.com/smapiot/piral - thanks!
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?
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.
Re: Principles of scalable front end projects
#9> 10 — Keeping a changelog 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 might be a good starting point: https://keepachangelog.com/en/1.0.0/
Re: Principles of scalable front end projects
#10> 10 — Keeping a changelog 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.
I think GitLab uses YAML Files representing changelog lines.
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.