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] Let’s answer the $1 million question. What exactly is software architecture? Or at least we’ll talk about what do we mean by architecture for the purposes of this course. So if we think about architecture in an intuitive way, the definition that might come up is that architecture is about the structure of a system. This makes sense, right? Because in the same way that the architecture of a house is about the structure of the house, the architecture of a piece of software is about the foundation of the software, the building blocks where all of the other pieces of the software will sit on top of.
[00:42] I think this is a correct definition. It is hard to argue with that because architecture is definitely about the structure of the system. But this leads to the question, what exactly is the structure of the system and how do we define the structure of a piece of software, whether it’s frontend or backend? So a lot of people struggle with this question. Even the best architects are having a hard time defining what exactly is architecture.
[01:05] And one of my favorite pieces that tells the story of one of these struggles is this article by Martin Fowler, which he wrote over two decades ago when he was trying to find a definition for architecture, for a book that he was writing that had architecture in its name. So he felt compelled to come up with a good definition. And in this article, he talks about a conversation that he had with Ralph Johnson, another legendary software architect. You might know him as one of the authors of the classic Design Patterns book, and they were discussing different definitions of architecture.
[01:46] And one of those definitions that they throw around in this conversation is that architecture is the decisions that you wish you could get right early in a project. Now, I like this definition because it talks about architecture being a set of decisions. This is the first time that we see that it’s related to the decisions that we make. And the reason we want to get these decisions right early on is because these are the decisions that are then hard to change.
[02:09] So the conclusion from this is that architecture is the things that people perceive as hard to change, anything that we think that is hard to change, and that is part of the architecture. But again, this leads to another question like how do we find what is hard to change? How do we point to something and say, this is hard to change or this is easy to change?
[02:34] So after a while of this discussion, they come to the conclusion that architecture is about the important stuff, whatever that is. And this is my personal favorite definition of architecture. And I use these all the time, but still, like it begs the question, what is the important stuff? How do we define what the important stuff looks like?
[02:51] So for this course, I wanted to have a more complete definition, something that we can point to and say, okay, architecture is this. And my favorite, the best one that I could find, the one that I like the most is this one from this book called Design It. So Design It is a fantastic book by Michael Killing, which we’re going to refer to a lot in this course, because a lot of the concepts that Michael talks about in this book, there are things that are about understanding problems and solving them and designing solutions, which is exactly how this course is laid out.
[03:26] So we’re going to refer to this book a lot. Now, the definition of architecture in Design It is that a system’s software architecture is a set of significant design decisions about how the software is organized to promote desired quality attributes and other properties. Now, I know that’s a lot of words, so we’re going to break it down a little bit.
[03:45] The first thing that I like about this definition is that it describes architecture as a set of decisions. This is in line with the previous definition that we saw in which we define architecture as the decisions that we wish we could get right early on. So in both cases, we see that architecture is nothing more than decisions. If we can point to the decisions that we make, then those are, that’s the architecture.
[04:08] There we can see that these are significant decisions. And the reason they are significant is because they are about the things that are hard to change and they are about how the software is organized, which again comes back to the structure. The structure of the system is how we organize it.
[04:27] And finally, the overall overarching goal of this architecture is to promote quality attributes and other properties. We’re going to talk about what these mean exactly in later video, but for now, just know that quality attributes are things like performance or accessibility, or deployability, scalability and so on. All of the things that we want architecture to promote.
[04:51] And in other words, another word for this is that these are the important stuff, we can think of this as the important stuff in our architecture. So if we think about it and the reason that I like this definition the most, is that this combines our attributes of all of the other definitions that we saw earlier. It’s about decisions, it’s about the things that are hard to change, is about the structure. It’s about the important stuff.
[05:19] Now, I like this definition a lot to describe what architecture is, but we still haven’t defined what architecture looks like, how we can point out something and say that is the architecture. And for that I like to use this framework from Head First software architecture.
[05:30] This is a pretty new book. It came out this year, but the framework originates from a previous book that Mark Richards and Neal Ford wrote several years ago, a pretty famous book called Fundamentals of Software Architecture. This is an updated version of the framework that they proposed in that book, and it lets us see the architecture, or split the architecture, into four dimensions.
[05:56] So we have the architectural style, the characteristics, the architectural decisions and logical components, the way that we define these dimensions, or that the authors define the dimensions in the book is by making an analogy with the dimensions of house or a room. So in the same way that we can describe a particular room in a house by talking about its height and width and its depth. Then we can talk about the architecture by talking about these four different dimensions.
[06:28] But the way that I like to describe it is to think of the architecture as if it were a character in a video game. Now that if that doesn’t make sense, I promise it will make sense in a minute. Now think about a video game, like a role playing video game or role playing game where you have a character that you have to define different attributes to create your character, right?
[06:54] So these characters typically have a class. So in this case, it’s an Archer. It could be a warrior. It could be, you know, a mage or a wizard or a bard, depending on the game. And this determines the overall shape and the look and feel of the character. The characters also have a series of stats that are things like strength or speed or dexterity that would determine some of the capabilities of the characters, its strengths and weaknesses.
[07:23] And each character, even if they’re they are from the same class. Each character will be unique depending on how you combine these different, these different stats. Then we have the background of the character. This is the backstory. Their personality, their origin story of, you know, all of the things that they went through, what things they care about, what decisions they will make.
[07:45] And finally, characters have a series of skills that these are abilities could be special abilities or could be common abilities, like throwing an arrow, or whatever. Now, the reason that we’re talking about a video game character is that I think these four things that we can use to define a character, we can map them really well to these four dimensions of software architecture.
[08:09] So the class, for example, maps really well to the architectural style. So the style of architecture is, for example, microservices style, or it could be layered architecture, it could be a monolithic architecture, an event driven architecture, and so on. So in the same way that the class of our character determines its overall look and feel, then the style would determine the overall shape of our architecture.
[08:34] In a lot of cases, we even referred to the architecture or to the style of the architecture as the architecture itself. We typically say that we have a microservices architecture, even if that doesn’t tell the entire picture necessarily.
[08:48] Then we have the stats of the characters and this map really well to architectural characteristics, and this is another name to what we previously talked about as quality attributes. They are the same thing. They just, architects, they use different names for the same thing sometimes. And so, these are things like performance, scalability, reliability, agility, deployability. All of the “ilities” if you see something that ends with “ility” probably one of these characteristics.
[09:16] And in the same way that each architecture will prioritize different things, or each character in a videogame will prioritize different things. Each architecture will have a different set of priorities when it comes to which characteristics they support. And it’s just like with that character, we can’t really give them strengths across the board. We can’t give them 100 points in all of its stats.
[09:41] We also can’t really prioritize all of the characteristics at the same time. This is about choosing priorities or what are the things that we care about the most, which will help us then evaluate different tradeoffs.
[09:51] Then we have the background story, and this I think I like to think of this as the architectural decisions. We’re going to talk about architectural decisions in a later video, but for now you can think of them as structural guides. These are sometimes there are rules, sometimes, or most of the time there are guidelines that will help your team sort of navigate the complexities of actually implementing a piece of software.
[10:15] For example, in a microservices architecture. One of the decisions you may make is how will different services communicate with each other? So these will include what protocols should you use or what rules you should follow when communicating with different services and more importantly, done. You know, what is the supported protocol or what the decision is, is to document why we made that decision.
[10:37] So that’s what we’re going to talk about when we talk about architectural decision records later on in a follow up module.
[10:45] And finally, we have the skills of a character which in my mind they map really well to the logical components. So these are your modules, your UI components, your design system, your classes, your functions, essentially all of the building blocks that actually make your architecture or your software.
[11:04] So in the same way that we can think of character in the video game as a combination of all of those different things and attributes and characteristics, we can think of the architecture as a combination of these four dimensions.
[11:19] If we want to describe what the architecture is and what does it look like, we have to use these four dimensions because using just one or two of them will just give us an incomplete picture. Another thing that I love about this model is that all of the things we’ve been talking about are really generic. We’ve been using microservices here as an example, but really all of these concepts apply no matter which part of this stack you’re working with, which means that we can use it as well to describe what we mean by frontend architecture specifically.
[11:50] And that’s what we’re going to do in the next video.