Subscribe to access the entire course.
🌶️ tip: unsubscribe at any time.
Ah, that's a great question!
Frontend at Scale is a bi-weekly newsletter (as in, once every two weeks) that is all about software design and architecture for frontend engineers.
Subscribing to the newsletter is the best way to support my work and encourage me to keep making free resources like this one.
I probably don't need to say this, but I would never ever spam you—and you can unsubscribe with a single click at any time.
Already subscribed? Don't worry, you won't get double-subscribed. Nobody deserves to read my terrible jokes twice.
Module 1: Foundations
[00:03] Architecture versus software design. Is there an actual difference between these two terms or are they pretty much the same thing? Well, there’s definitely a lot of overlap, and I think it’s fine to use the terms interchangeably. But there is one difference, and I think it’s important that we talk about it.
[00:18] So when we think about the relationship between architecture and design, we can also see it as this spectrum kind of thing where the architecture end of the spectrum, we have things that are about the structure of the system. And on the design end, we have things that are more about the code, about the design patterns that we use, about the big decisions that we make when naming functions or how we organize the code and so on.
[00:44] And to know where a particular decision falls in this spectrum, it helps to analyze it through a few different lenses. One of them is how hard or how easy the decision is to change. The harder it is to change, the more architecture will be in nature. Another one is how strategic or how tactical the decision is. Architectural decisions typically involve multiple teams. They have longer term implications, or they just require us to think more strategically about how do we make that decision. While design decisions are more about day to day operations or about how do we work with our immediate teams.
[01:22] And also, architecture issues are high level. They require more context. They require us to know how other parts of the application or, how all other applications work, while design decisions are more at the level of the code. So we don’t need to know. Typically they are constrained to a particular codebase.
[01:40] So let’s see a couple of examples of how can we put a particular decision in this spectrum. So let’s say we’re trying to make a decision about the style of our architecture, whether we want to use micro-frontends or monolithic SPA or islands architecture or whatever it is that we’re trying to define. So that definitely falls in the architectural side of the spectrum because it pretty much checks all of our boxes. Sometimes it’s hard to change. It is not easy to change from a micro-frontend to a monolith or vice versa. So that’s something that’s definitely hard to change.
[02:15] It is strategic because it involves pretty much the entire team and maybe other teams outside of the organization, and it has very long term implications. And it’s a high level decision because it requires me to know more, not just how my team works, but also other things like what level of performance I’m trying to achieve, or what about their reliability. You know what what quality attributes do I care about?
[02:39] Another example is the decision we saw earlier about choosing to use signals to share global state in my application. So that is something that it is not necessarily easy to change, but it’s also not very hard to change. Also, it falls more on the on this side of the spectrum. It is very strategic. It’s kind of strategic in nature because it involves my entire team and it probably going to have some some long term implications, even though I can change that decision earlier. So I will say it falls more on the architectural side of things or on that regard.
[03:12] But is that kind of like a lower level decision Because it’s about the code, it’s about how do I share stating the code So also it falls more around here. So overall we can say that the decision itself falls in this area.
[03:25] Now why does this matter? Why are we even talking about this? And the reason that this is important is that it helps to know how seriously we should treat the decision. The more that a decision falls on the architecture end of the spectrum, the more time we should probably spend thinking about or doing research about the decision to make sure we’re making the right call. The more people should be involved or at least aware of that decision and the more important it is that we document that decision. And if there is an architect in the team, they will be probably the person making the call and the more a decision is about design more quickly, we can make it like we don’t have to align the entire team on how do we name a function or we don’t have to have a meeting to define which design patterns we want to use.
[04:13] And this helps us avoid two things either underestimating an architectural decision which which means treating it very important the hard to change decision too lightly, or overestimating a design decision which will be like spending too much time thinking about something that it’s pretty much trivial. This is scenarios come up all of the time.
[04:29] So next time you are faced with the decision that you have to make or that your team needs to make, it helps to know where it falls in that design architectural spectrum because it can help you avoid these two very common and very dangerous traps.