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] Before we get started, I want to give you a quick walkthrough of the project that we want to be working with. So you will find a link to this repository in the description of this video. And it’s a pretty standard Turbo repo setup. If you haven’t used to Turbo repo before. It’s a very powerful but also very simple tool for managing mono repos. I like to use mono repos almost as a default for most projects that I work on unless they are like super simple. Something that I’m maybe hacking on, on the weekend.
[00:31] But if I’m working with a team, if I know that an application is going to have or a project is going to have multiple packages and multiple applications potentially, I like to start with with a mono repo, but because it just makes things much simpler in the long run. So again, this is a pretty simple setup, but I just want to give you just a quick overview of what we have here.
[00:52] We have an apps folder. The two main folders we have here, are apps and packages. The Apps folder contains three applications. One is the core API, which is really like a mock version of the real core API that we saw in the container diagram. So we’re going to be using these for some of the exercises, but and we’re not going to be touching these really. But just so you know, you can see what endpoints are available here by opening this index JS file and it will return some mock data that we’re going to use to represent some of our entities.
[01:27] Then we have our DOCS application, which again, we’re not going to be using this per se, but this is just to give you an example of other types of applications that you may have in your own project. For example, these might be for internal documentation, or it could be like a storybook application or docusaurus or something like that to to document your design system.
[01:48] And then finally, we have the web application, which is the main Next.JS application that we’re going to be working with. I’ll come back to this one in a minute.
[01:58] Then we have the packages and packages are just again, just as an example, we have some ES lint config, some typescript config, some common types that we may have, and also a UI package that is again, it’s meant to represent our design system, our main component library, and we have some example components here. These are not production ready at all, but this is just to give you an example of how we might structure the entire project and the entire codebase to to have all these different packages in an organized way.
[02:29] So coming back to the Web application, as I mentioned earlier, this is the customer facing full stack application is the one that we designed the architecture for. And it’s very standard, very simple Next.JS application. As I mentioned earlier, we’re going to be using Next.JS In this example, if we want to run the application, you can open up a console and run NPM run dev from the root of the project and thus this will run all three applications.
[02:56] It will run the core api, the docs application and the web application. We really don’t care about docs, but that’s fine. It’s not going to it’s not going to do anything. And then we can see it running on localhost 3000. So if I open a browser here, this is what you should see when you run this locally.
[03:13] Now again, this is a copy of the Uber Eats website. It’s not even like a good copy, but this is again, just to give it something to look like. We only have two routes implemented in this in this main branch. We have these home routes where we haven’t provided an address yet. And then if we just click this search here button, it will take us to Dad delivery page, which is another one of the pages we have implemented.
[03:39] If we go back to the code base, if we want to see how this things are implemented, you will see that we have in our app folder, which is the the routing folder for next year. We have main page application in a route folder. We have the page.tsx, this represents our home route and then we have our delivery folder with also a page.tsx This is a Next.JS convention that represents all delivery route.
[04:07] Now, as you will see, we have nothing else. We have a layout.tsx which is the sort of the or heading or header and footer and so on. But really we don’t have anything else. We don’t have any components inside of the app folder, and that is by design. So we’re going to talk about how we’re going to keep all of our code, really most of our code inside of our modules folder in the next video.