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 4: Implementing
[00:02] Let’s talk about how we can implement the different modules of the application into the codebase. So as a reminder, the modules are sort of the main building blocks of your application. These these are the ones that we defined in the previous section when we drafted our design document and we defined that we have a home module, login module, delivery module and so on. Now a lot of these map 1 to 1 with the main routes of our system.
[00:31] So it is very common to see when we implement the codebase to sort of mix these two concepts together, routes and modules. So for example, in the case of a Next.JS application, we have a file based routing system where instead of the app folder, every time we create a page.tsx file, we are defining sort of like a main entry point for your route. And then every time we create a folder, with a page.tsx we are defining a new route name. After the folder, right? There are a lot of conventions that we we can follow here to define routes that have parameters in them and so on.
[01:08] Now, why don’t we put the contents of our module here? Like why, why come up with all of the components that make up the delivery module inside of the delivery route folder? Well, there are a few reasons why I like to keep things separate. As you may notice, I have a modules folder here which contains my actual modules and I like. First of all, I like being able to see them all at a glance here, which won’t be the case if I have them sometimes nested in within the app folder.
[01:39] So as we mentioned earlier, there isn’t always a 1 to 1 relationship between modules and routes, which makes it so that we can’t really look at the app folder and just look at all of our modules at a glance. For example, the shopping cart module that we defined earlier, it doesn’t have its own route, so we have to figure out where to put it. They will probably won’t be inside of the app folder, it might be outside of it and or we may be following one of the sort of the weird conventions that really all file-based routers have, which are, in the case of Next.JS adding parentheses to your to your folder so that in case doesn’t create a new route for it.
[02:21] That’s okay. That’s up to you like I guess personal preference, but I like to keep things consistent as much as I can. And in this case I like to be able to don’t have to follow any conventions because here for me, a module is just a folder inside of the modules inside of the main module directory.
[02:41] Now there’s also the possibility that your your modules might be nested within other modules in the case of the menu item module, it is a top level module is at the same level of importance as all of my other modules. But in terms of routing, it doesn’t have its own its own top level route. It is a subroute of the restaurant module. So having things nested in this way may make it complicated to to find things when we want to see where something is implemented.
[03:11] One of the advantages of defining the modules of our system is that it makes things easier to navigate. So for example, if I want to fix something in the menu item module, I know that I can go to the menu item module. If one of its components and it’s probably going to be around there. But if I have it nested within the restaurant route and I have to follow all of these conventions, then I might not know where to find things. So I like to keep things separated as much as possible.
[03:41] And finally, the last reason is that this makes it simpler to apply some of the constraints and guardrails that we’re going to talk about in the last video of the course. Now, with this structure, things are still very easy to navigate because we’re simply using the app folder as a router. We don’t have anything else on it If it’s not related to routing or to the, you know, how do we define the URLs or the conventions on Next.JS about writing, then it’s not going to be on the app folder and then everything else is going to be inside of a module.
[04:12] So our app folder, it’s simply our router. Here we have these In the case of this delivery route, we import this component from the delivery module and then we’re just rendering. We might do some data fetching and we might do other things as well. But the majority of the logic should be within the modules.
[04:34] Now if you open the delivery module, you’ll see that we have some conventions, you have some features, and within those features we might have components and so on. And that’s part of the hierarchy that we define to for how we organize modules. We’re going to talk about that in the next video.