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 2: Understanding
[00:03] The last thing that we’re going to cover in this module is the concept of architectural decisions. As you might remember, these are the decisions that fall more toward the architecture end of the spectrum. And this may be because these decisions here are about the structure of the system, or they are hard to change, or they have longer term implications.
[00:24] At this point in these early stages of the project. Most of the decisions that will make would be architectural because we don’t really have enough information to make a design decision yet. We don’t have any code to look at. For example, we might want to decide which frontend framework we want to use. These something that sometimes is more like an implementation detail, but in other cases it’s really an architectural decision because it will drive the structure of your project. A lot of these frameworks like NUX. And Next.Js and Remix they come with their own structure that you have to follow in order to build the rest of your obligation on top of that particular framework. So it may be as well, architectural decision.
[01:04] Then we have, for example, making decisions about version control. Do we want to use a mono repo or do we want to use a large number of repos and deploy them to a private NPM registry, for example? These are decisions that we might want to at least keep in mind that these early stages we might want to make decisions about how to keep the code base organized. This is maybe a decision we might like to do later on, but at some point we have to define whether we want to use a particular method of organization like domain driven design or clean architecture, or do we want to use that got more like a simple hierarchy to keep our components organized.
[01:41] Another decision might be, for example, if we have to support an influential functional requirement, do we need to use any third party vendors that we should keep in mind at this point? For example, in the case of the real time functionality that we have? Do we want to use a third party like Pusher to drive that functionality in our case, we know that that’s not the case because we already have our own real time infrastructure. But this is something that you might want to consider for your own project and also maybe you want to make decisions about what you’re going to do about observability and monitoring, how you’re going to keep your logs. If reliability is something that is a high priority, quality attribute in your requirements. Then you may want to consider this as early as possible.
[02:29] There are two things that I want to say about architectural decision before we move on. The first one is that we shouldn’t try to make every decision at this point. This this will probably block the entire development process, who will probably have spent spend too much time thinking about these decisions and maybe lead to analysis paralysis. So it’s much better to use the last responsible moment principle and only make the decision once we know we have as much information as possible. And the second thing is that the why of the decision is more important than the what. This means that what the decision is is not as important as why did you make the decision
[03:11] So in our project, as an example, we’re going to make the decision of using Next.JS for our for our frontend framework. Now, don’t worry, if you don’t have experience with Next.JS or even if you don’t like Next at all, these will have a very small impact in the rest of the course. But more important than what the decision is, which is using Next.JS. Yes, is why do we make that decision and to do that a great way to document the why is using a tool called architectural decision records or ADRs
[03:44] ADRs allow us to document our architecturally significant decisions. And over time, all of all of our ADRs will form some sort of architectural decision log. And that log will be like a book that will tell the story of our architecture. So for ADRs, I like to use this very simple template by Michael Nygard, which you will find in the description below. And essentially has a few sections. We have a title for the ADR. We have a status which might be something like in progress or accepted or draft and so on. We have some context about what the decision is, why do we have to make that decision, what the decision is and the consequences, both positive and negative.
[04:31] So let’s look at an example, ADR that I have here about the decision we talked earlier about using Next.JS Yes, for FullSnack. So we have the title here and it’s usually a good practice to also name or have an ID, like just a simple number for our ADR so we can then refer them by using these ID here. Then we have the status. It is accepted because I am the only person working on this project. So I wrote the ADR and I accepted immediately. And then we have the context about why we have to make this decision for building the new. We need a new UI framework for this new application that we’re building and wanting to create a robust, scalable and performing obligation. We have a very tight timeline of four months.
[05:16] Here’s what the decision is, which is to use Next.JS as our framework and to host it on our own AWS Infrastructure using SST. Now don’t worry if you don’t know what SST is, it’s just a tool that allow us to deploy on Next.JS or ASTRO application or they support many other frameworks on your own AWS Infrastructure, which I assume you remember This is one of the constraints that we had. And then we have the consequences of these decision. The positive consequences include rapid development because all of the team members are already familiar with Next.JS So we are reducing the the risk of taking on a new framework that no one is familiar with. So we’re reducing the unknown unknowns in a way which allow us to move fast and meet our tight deadline. And we have other other positive consequences like flexibility of development and the fact that Next.JS has a large community and ecosystem, for example, then we have some negative consequences as well, which are also a good idea to document.
[06:17] Now this again, this is just an example of an ADR, and you can use this as a template for your own ADRs. But the point is that it is is always a good idea to document the decisions that are important. If someone is going to ask a question in the future about why someone made that decision or why you as the architect made the decision, it’s good to have a document like this that will tell them exactly why.
[06:41] And with that, we reached the end of the Understanding module. Hopefully at this point you have a good understanding, a solid understanding of what the problem is that we’re solving. And in the next module, when I come up with a good solution for it.