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 3: Designing
[00:03] In the previous module, we talked about the C4 model for visualizing software architecture and we saw the first two levels of the model, the system context diagrams and the container diagrams. Now it’s time to zoom in further into level three and see where the actual contents and building blocks of our container, which in our case is the application that we’re building. In the C4 model. We call these building blocks components.
[00:30] But for frontend systems, I like to use the word modules instead because there are some slight differences between modules and components, and also because in frontend development we typically use the word component to refer to UI components like React components and so on. So in order to avoid confusion, I rather call them modules. You can think of modules as the top level concerns of your application.
[00:51] So when we start to break down the application into smaller chunks or smaller mini applications or mini problems, the first layer of that breakdown is to break them down into modules. So the way that I like to find the modules are, which are the module of my system, is to take a look at the routes. We don’t have the routes yet. They don’t exist. But I think it’s good to speculate a little bit about how they might look like by looking at their UI spec, for example, or some definitions in the in the projects specs and try to come up with an initial list of which routes we may have.
[01:26] This will help us structure our application in the code later on as well. These don’t have to be the final routes. We might change the name of the routes, but from this we can take the name of the modules that we’re going to be building. And from this routes, we can come up with an initial list of modules. So we have a home module, logging module, delivery pickup, restaurant profile, search and so on.
[01:48] You might notice that some of our modules like restaurant have a relationship with one of our entities. We also have a restaurant entity, but I try to stay away from trying to map always 1 to 1 entity some modules, because not all modules are entities and not all entities are modules. For example, we have search, which is one of the modules of our system. It has its own set of features, its own set of components and functionality, and it is a big part of the application, but it’s not really an entity. There is no search entity search. It’s more like an operation or an action that other entities can do.
[02:26] So trying to restrict entities or trying to always tie together entities and modules can lead to weird conventions or defining entities that are not really entities. Just for the sake of compliance with this restriction. Now, this doesn’t mean that there’s always going to be a 1 to 1 relationship between routes and modules either.
[02:49] So I would have made that rule. For example, here we have a subroute, this is a second level that represent our food items or menu items. Menu items have a lot of complexity. If you look at the UI, you’ll see that they have a ton of menu item options and categories and so on. So I will consider them their own module, even if they’re a part of the restaurant main path.
[03:11] So in this case, this is something that breaks a rule because now there is no menu item or item. Main path is just part of the restaurant route, but this module is not part of the restaurant module. It is its own thing. We also have some modules that don’t belong to any particular route. The shopping cart, for example, is something that shows up on every page and so it doesn’t have its own dedicated route, but it’s still something that I will consider to be a module because he has a ton of functionality.
[03:40] So once we have our initial list of modules, we will in theory, go ahead and implement them one by one. We can divide them among the different people on the team and each person can take on our particular module, develop it completely and move on to the next one. But of course we know that in reality things don’t really work that way. There’s always going to be some shared functionality or shared code and components between different modules, and there’s always going to be dependencies between modules.
[04:06] For example, menu items, maybe two modules, but they don’t exist by themselves. They are deeply connected to the restaurants. Without the restaurants, we wouldn’t have menu items. So there’s always going to be some level of communication between these two modules. So for now, we’re only going to focus on identifying which modules we have in the application and in the next module. When we talk about the next module of the course, when we talk about implementation, we’re going to see how we can handle these cases of shared functionality or dependencies across modules.