what-is-frontend-architecture

[utterances-bot]

What is Frontend Architecture? - Tomasz Ducin - blog

While working on applications (let it be React, Angular, Vue, pick your favorite one), we make architectural decisions all the time. It's extremely important to be aware of them, i.e. have architectural drivers in mind, be aware of the tradeoffs of these decisions and cope with the limitations. Or maybe you think that it's all overcomplicated and Frontend Architecture is just the directory structure?

https://ducin.dev/what-is-frontend-architecture

[lkrzysiak]

Great article!

[jsardev]

Great insights, thank you 🙂

[jooa7878]

Thank you for the great article! I found it really interesting.

I’m a junior developer without deep knowledge of software architecture, and I have a question.

From what I understood, one of the key factors in determining whether something qualifies as "architecture" is whether it holds meaning even when viewed from outside the team.

Among the examples you provided under "Architecture defined by" (the points marked with ✅), I’m curious whether these aspects are meaningful from an external perspective. If so, in what way and how do they provide value externally?

Could you explain how to approach understanding this concept?

Since this is a translated comment, some sentences might be a bit unnatural—I apologize if anything sounds unnatural. 😅

Once again, I appreciate the great article. I’ll definitely check out the books you recommended!

[ducin]

hi @jooa7878, thank you for your interest.
No, I wouldn't say that the "external" factor is the key here (it holds meaning even when viewed from the outside). Not sure if that's a translation issue.
You could think of architectural decisions as the ones that:

• affect your product in a long perspective
• are often difficult to change
• narrow down your possibilities by following an approach that brings certain consequences
  and so on.

On the other hand, something that "remains meaningful outside of the team" is important in terms of:

• cross-team/cross-module integration. One team might depend on another - in code, in event-driven integration, in public APIs in general
• providing capabilities that others need to use in order to make the overall product more competitive on the market (it matters if and what is a given team delivering or not)

All in all, most often, whatever a team is doing TECHNICALLY, the less the outside knows about it or depends on it, the better - as autonomy allows teams with different goals to move in different directions/speed, have different priorities etc. So most often you should not care what another team is doing unless integration and/or product-strategy (discussed above).