Who This Book is For

If you are trying to figure out how senior devs seem to magically know how everything works and how they understand complex concepts so quickly, I’m going to show you how. At this point in your career, you’ve probably been working as a software developer for a few years. You know how to complete your tasks with solid code regardless of whether it’s on the front-end or back-end.

While you might have some knowledge across the full-stack, it’s likely you have a focus on one part of the stack over the other. On the front-end, you should be familiar with things like making responsive layouts, fetching data from APIs, and some of the frameworks like React, Astro, or Svelte. On the back-end, you’ve done some database migrations, built some APIs, and handled some basic authentication flows.

You also have skills like using Git with any of the repo hosting services, like GitHub or GitLab, and using different tools to test your changes. You may have worked on one project for years or you might have hopped around, but the scope of your work has typically fallen under some of the concepts mentioned.

Now you’re ready to move to the next level in your career. That means learning how the whole system works and why technical decisions are made. That’s what will be covered in this book.

What You Will Learn

The high level of what you’re going to learn in this book is everything it takes to create a full-stack web application hosted on a cloud platform. You’re going to learn how to find where the business logic for every app comes from. You’re going to gain some intuition on how to decide between different architectures, third-party services, and tools to create a maintainable application.

You are going to learn the subtle, yet deep skills it takes to become a senior developer. This book is going to give you strategies for working with different teams and understanding how product decisions are made. You’ll also deepen your existing skills to cover the full-stack confidently.

Regardless of whether you start on the front-end or back-end, you’re going to learn about design and development principles and when to apply them. You’ll learn all of these things as you go through the software development lifecycle (SDLC) of a project in this book and build a production-like application.

Think of this book as a reference you can pick up at any point in the SDLC and use it as a checklist. You will learn all of the essential parts that need to be considered for app development so that you know exactly what to do when a question comes up. By the time you finish, you’ll know how, why, and when to make technical decisions and how the business requirements evolve.

What This Book is Not

This book is not a deep dive into any specific set of tools and it will not teach you general JavaScript programming. There will be a large range of topics covered in this book with accompanying examples to demonstrate senior-level considerations, but it is expected that you know how to read code, debug issues, and find additional learning resources.

Since there are so many topics covered, there will be strategies discussed along with the code. These strategies are meant to be tools you can bring to any project you work on, although they might not work on every project. There isn’t a single approach that would work for any two projects because everything has its own nuances. So the goal is to give you a number of options you can choose from as needed.

There will be some parts of the book that need a much deeper explanation than a chapter or section can provide and there will be links to other resources. No book can adequately cover all of the topics presented here and I want to make sure you get all of the information you need. So while some topics will be light on the full implementation details, there will always be links to complementary resources.

How This Book Is Organized

The first part of this book, Starting your new project, will be relatively short and cover how you translate designs into tasks and questions that you’ll have to ask the Product team and other teams. This is where you get your first introduction to where business logic comes from. 

The second part of the book, Building the back-end, focuses on creating the back-end of this project. You’ll work with Nest.js as we walk through a number of considerations, like security and third-party services, for development.

After you have the back-end ready, you’ll switch over to part 3, Building the front-end where you’ll work with a React project. You’ll build the user interface (UI) for this project and cover concerns associated with front-end apps, like responsiveness and performance. 

Finally in part 4, Deploying the full-stack app, you’ll dive into the details of connecting the front-end, back-end, and other systems to build and deploy a full-stack app to production. By the time you finish this book, you should feel comfortable jumping into any part of a project and asking questions that will help clarify tasks as well as provide technical advice.

You’ll notice that each part of the book varies in length. That’s because it’s supposed to help break down where a lot of time really gets spent during development. Some parts of a project take more time than others or have different feedback cycles. This book is trying to reflect real-world conditions as closely as possible.

Conventions Used in This Book

The following typographical conventions are used in this book:

Italic

Indicates new terms, URLs, email addresses, filenames, and file extensions.

Constant width

Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.

Constant width bold

Shows commands or other text that should be typed literally by the user.

Constant width italic

Shows text that should be replaced with user-supplied values or by values determined by context.

Using Code Examples

Supplemental material (code examples, exercises, etc.) is available for download at https://github.com/flippedcoder/dashboard-server.

If you have a technical question or a problem using the code examples, please send email to support@oreilly.com.

This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.

We appreciate, but generally do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Full-Stack JavaScript Strategies by Milecia McGregor (O’Reilly). Copyright 2025 Milecia McGregor, 978-1-098-12225-6.”

If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at permissions@oreilly.com.

O’Reilly Online Learning

Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, visit https://oreilly.com.

How to Contact Us

Please address comments and questions concerning this book to the publisher:

• O’Reilly Media, Inc.
• 1005 Gravenstein Highway North
• Sebastopol, CA 95472
• 800-889-8969 (in the United States or Canada)
• 707-829-7019 (international or local)
• 707-829-0104 (fax)
• support@oreilly.com
• https://www.oreilly.com/about/contact.html

For news and information about our books and courses, visit https://oreilly.com.

Find us on LinkedIn: https://linkedin.com/company/oreilly-media

Follow us on Twitter: https://twitter.com/oreillymedia

Watch us on YouTube: https://youtube.com/oreillymedia

The Project You’ll Build

Here’s the description of the project you’ll be building as you go throughout the whole book. You work on an e-commerce platform that has access to a lot of user data, including some personal identifiable information (PII), and connects with multiple third-party services. You and your team have been tasked with creating a user dashboard so customers can see information about their order history and other actions they have taken, make purchases, and interact with their digital purchases, like ebooks. They’ll also be able to take different actions based on their permissions within the app

You’re starting with a fresh Product team and possibly a Design team that you’ll work with to make this dashboard a reality. The Product team will be responsible for talking with different stakeholders to decide what features should be built. The Design team will be responsible for making the user interface (UI) for those features and doing the first pass at the user experience.

The first part of the project will likely involve the Product team and the Design team working closely together to make some mock screens for you and possibly some behavioral docs. These mocks will be shown to you and discussed in a project kick-off meeting.

Project Kick-Off Meeting: Going through the designs

This kick-off meeting typically involves the Product team going through the mocks the Design team has made with you. There’s a strong chance that these mocks will change as you go through development, but they should be about 80% of the way there. They’ll take you through the user flow, show you how users interact with the app, and give you an idea of the data you need. At this point in the project, get comfortable asking a lot of questions. There are usually things that come up when you start looking at the designs from a technical perspective that the Product or Design teams haven’t considered.

Remember, this whole process is very collaborative. Asking questions early and often will make things smoother as the project moves forward. Right now there are only two screens that need to be built for a proof of concept, but Product has told you the functionality will expand over time. Let’s take a look at these screens and go through the user flow.

The screenshots are from a commonly used design tool called Figma.

Figure 1-1. : Overall design in Figma

Figure 1-1 shows what all of the views in the application look like. There’s usually a design like this somewhere that visually describes how the app flows. As you move through the engineering process, you’ll focus on one of these views at a time, like the user info screen in Figure 1-2.

Figure 1-2. : user info screen design in Figma

Figure 1-2 is where users can see their information, like orders, suggested products, and other details.

Figure 1-3. : user actions screen design in Figma

In Figure 1-3, users edit their information like address, cancel orders, and see their digital purchases.

Figure 1-4. : app designs with mobile view in Figma

The design in Figure 1-4 shows how these views should look on mobile devices. The majority of projects that interact with external users will have mobile designs. If you don’t see these designs, make sure you ask about them!

A lot of designers use this tool when they create the mocks for an app or a particular feature. Some other tools you might run into are inVision or the newer alternative, Penpot. These Figma designs also have the HTML and CSS in them, so they can be useful for developers when they want to check dimensions while arranging elements on the page. Although the CSS is there, it’s usually best not to copy it directly into your code. It doesn’t always generate style rules that fit with your existing theming.

By the time you see these mock designs, Product and Design will have had several meetings trying to iron out as much detail as they can. That doesn’t mean they’ll have everything figured out and that’s where you come in. Based on these designs and the explanation of how a user will interact with the app, you have to work with your team to decide the technical approach you want to take.

Let’s walk through these designs, similar to how you will with your Product team.

1. On the first screen, there’s a navigation bar at the top of the page with links to other areas in the app.

2. Then, there is a featured products section, along with the users most recent order.

3. There’s a sortable table that displays all of the user’s orders with several columns.

4. Finally, there’s a footer that includes links to information about other parts of the e-commerce platform.

On the second screen, there are several sections that have fields the user can interact with. There are a few settings users can toggle, fields that they can update, and actions they can take based on their purchases. This screen has more complexity than the first screen, so you’ll want to take time and really go through this with the team. As the senior developer on the team, Product and Design will often turn to you for the final say on technical decisions.

With these designs in hand and a few documents on how the screens are supposed to work, it’s time to develop an understanding of the business logic before you go to the team. Having a solid understanding of the business decisions behind the designs is a huge help when you’re trying to explain things to other developers.

As you go through this information, there are a lot of things you’ll need to consider based on the designs you have.

Design Considerations

This is a stage where you will find yourself asking a lot of questions and that’s totally normal. Now is the time to really dive into the details and get nitpicky. One of the ways you can get more experience with evaluating designs for technical purposes is by getting exposure to different design sets. For example, the Design team you’re working with is likely doing design work for other apps in the company.

If you have questions about how a dropdown is supposed to behave, ask if there are other designs you can use as a reference. Many times there are and you should take the time to thoroughly understand how they work. Some of the best questions come from experience with different implementations. Another way to get more exposure to different designs is to start paying close attention to the apps you use! Have you ever really thought about the user flow for your bank app or the flow for an exercise or meditation app? These are all examples of product designs that are in production that you can make comparisons with.

Think about how designs look for other products and how interfaces behave when you’re breaking them down into the details. As you think of differences, take notes about the questions they bring up.

You might be wondering what some good questions are and they always depends on your designs and the business logic. Here are some that can get you started as you look at the screens you have available:

• Are there translations to other languages we need account for?

• What are the brand guidelines, like colors, fonts, and responsive sizes, that should be used throughout the app?

• What permissions do users need to see their information?

• What permissions do users need to take actions in the app?

• How many different types of user will there be?

• How long do we expect users to be active, so we know how long an access token should live?

• What is all of the data we expect to handle for users?

• Do we want to show this data for different time ranges?

• Should the table be sortable by each column or only specific columns?

• How do we know which orders should be featured?

• What type of data do the input fields accept?

• When a user saves changes, do we want to redirect them to the previous page?

• When a user saves changes, what should we show them?

• If there’s an API error or client-side, what should the user see or be able to do?

• Does the user need to enter more credentials before taking sensitive actions, like changing PII?

• Should input errors be shown inline with the field or by the submit button?

• Do we need to consider tablet-sized devices?

• Will the back-end of this app be used by any other apps?

• Will the front-end need to be integrated into another app?

• Are there any compliances or regulations this app falls under or will get audited by?

You see, this list of questions can get very long and I’m sure you thought of other questions as well. It’s ok if the list is long. Of course, it’ll be hard to get all of these questions addressed so you should definitely prioritize this list based on the feature. It’s better to ask as many of these things in the beginning compared to half-way to the deadline. If there are small things then you can probably use your experience to make judgement calls, like with form handling.

The questions can be all over the place, but these are questions the Product or Design team can answer. There isn’t anything technical in here yet, although the answers to all of these questions will drive technical decisions. Getting answers to these sorts of questions early is why senior developers tend to deeply understand the business logic.

In order to make the best technical decisions you can, you have to understand the purpose of functionality and how it fits in the overall business. This can give you some foresight on how to build the app in the most maintainable way because you see the direction the business is going. Some of this foresight will come from the data you know you’re going to work with.

Data-driven Design

Data drives design. Everything the designs do is built around how to best deliver data and let users interact with it. Take the table screen for example. The data doesn’t have to be displayed as a table. It could be a collapsable list or a graph. That’s why you have to dig into these questions about the business logic and what you will be working with. It’s one of the reasons that front-end development is usually dependent on back-end development. We’ll talk about this more in the next chapter though.

As you go through the designs, it’s also a good idea to take notes on the data you see you’ll need for each screen. On the settings screen, you can see that you’ll need the user’s name, shipping address, and language preference in one section. Take notes on potential variable names and data types for these that you feel comfortable sharing with the team. It can help spark the initial conversations around how to approach the project. Also confirm with the Product team that these values are correct and what’s expected by the app. Always check with the Product team that you have the correct data and relationships between the data.

They won’t explain it in technical terms, but they’ll walk you through different scenarios so you can paint the big picture. This is like the discovery phase of the project for your development team. Once you’ve gone through these designs and you have your questions and notes, get ready to talk about specific features.

Breaking Down Designs into Tasks

You’ve made it through the first round of refinement for the project! In this next round, you can assume that Product has answered all of your team’s questions and you have updated designs. Now you’ll be working with Product to carve features out of this info. This is when you’ll first come to the a kanban system, like Jira, Trello, ClickUp, or Shortcut.

Figure 1-5. : example of a backlog in Jira

The tickets you make here are going to go through refinement once you start bringing in more developers and other teams. The goal at this stage is to make action items for segments of the designs. The user info screen for example has several pieces that can be broken out into features. The featured section and the table are individual features. You’re trying to get people thinking about how the designs will actually work and start bringing in that technical perspective. As a senior full-stack dev, you might try to group features based on data relationships.

This will help make it easier for back-end changes to be made and deployed as the front-end is being built. This is also the point where you can still call out any big issues you run into as you start thinking through the tech stack. Any time you have a thought for a feature or technical requirements, make sure a ticket gets made. If there isn’t a ticket, the work won’t get prioritized.

Discussing Timelines with Product and Other Teams

At this point in the project, you can assume you have well-defined tickets and the details are as ironed out as possible. Now it’s time for one of the higher level conversations. After all of the tickets have been estimated, Product will be ready to set a launch date.

This is going to involve more than just your team. You might need to coordinate with developers on other projects, the DevOps team, the Support team, and the QA team. It just depends on how far the reach of your changes goes. Don’t commit to a launch date until you’ve talked with these other teams. You’ll want to see how your goals fit into theirs and what you can do to make the process easier for them.

Bringing It All Together

You’ve made it to the final step of project kick-off. You have all of your notes from the different team meetings and it’s time to distill it all and give the highlights to Product. All of these conversations will help you come up with a reasonable deadline. This is where some negotiation will start. One thing to keep in mind with deadlines is that something in development will go wrong.

Give yourself and your team room to breathe and possibly over-deliver. Remember, under-promise and over-deliver. Unless the feature you need to implement is time-sensitive, like a third-party service being updated, add a few days of padding to account for weird happenings. After you’ve settled on a date with Product taking all of the other teams’ concerns in mind, summon everyone together for one final, short call.

This call will have someone from all of the teams you’ve talked to. The only things you want to confirm at this point are everyone’s action items and deadlines. Having this call is about establishing accountability and triple-checking that everyone is on the same page. As prep for this meeting, take all of this info out of your notes and make a short doc that everyone can reference leading up to the release.

At this point, you have many of the Jira tickets you’ll be working on and they’re well-defined. You’ve documented the cross-team connections. Project kick-off is complete. You have everything you need to finally get started writing code. In the next part of this book, you’ll build a scalable back-end in TypeScript using the Nest.js framework.

Why Nest.js?

Before we dive too deep into the weeds, let’s discuss why Nest.js is a solid choice. It’s basically like a back-end architecture in a box. As soon as you initialize the app, you immediately have access to things like validation, authentication, routing, controllers, data schema, and a lot of other functionality. Instead of piecing everything together, Nest.js gives you everything you need to make a scalable back-end from the beginning. That does mean it’s a little less flexible in what you can do with it, but it’s the trade-off for all of the up-front scaffolding.

This is when you get to have some fun as a senior dev as you set up the initial repo for the back-end. The decisions you make here drive the direction for the future of this project. As you come to questions that have options, ask your team for their technical input. They might be aware of something you don’t know about. This not only helps you build a better app, it also helps everyone on the team learn.

There are so many considerations for building a back-end that having other input will help you make decisions faster and more confidently. It will also help to keep architectural decision records (ADRs). These help keep track of why and when important architectural decisions were made and you can see some examples in this GitHub repo.

It can be a little overwhelming being the one to open the empty terminal and bootstrap a completely new project. There’s nothing to build on except examples and boilerplate code. It will go whatever direction you and your team decide to take it. This is a fun time because you can really set up the code base to be in a position that’s clean to update, test, and expand.

Choosing a Project Approach

This project will be a monolithic back-end with a couple of serverless functions. This will allow you to build and deploy quickly and you’ll get to work with a hybrid back-end architecture. You could have also decided to take a microservice approach. Then all of your APIs could be serverless functions, for example. Your choice of back-end architecture is dependent on how the app is going to grow over time. Microservices can take more resources and more engineers to maintain compared to monoliths. Although monoliths can make it more difficult to make larger changes as quickly as you can with microservices.

You’ll also be using TypeScript. The reason you’re starting the project off with TypeScript is to help prevent debugging because it’s harder to write incorrect code. By strictly enforcing typing, you’ll catch some errors before you even run the code. It also helps make it easier to see what fields and data types you’re working with and where they come from, which is wonderful for keeping types consistent across the front-end and back-end. Having some typing in place is like having documentation for how things are connected and it lets you see all of the fields you have available.

Setting Up Nest

You’ll walk through all of the steps to bootstrap this whole project. To start, there are a few environment things you need to have in place. You can follow along with the demo repo here: https://github.com/flippedcoder/dashboard-server

You’ll need to install the Nest CLI. The current version of Nest as of this writing is 9.2.0. Open a terminal and run the following command:

[source, bash]
npm i -g @nestjs/cli

You can create a new Nest project with the command: 

[source, bash]
nest new <your-project-name>

For this project though, you’ll use this command:

[source, bash]
nest new dashboard-server

It will ask you which package manager you want to use. Select npm and hit ENTER.

[source, bash]
? Which package manager would you ❤️  to use? (Use arrow keys)
❯ npm 
  yarn 
  pnpm 

After that the installation will start and it might take a few minutes. This process is installing all of the project dependencies, scaffolding the entire architecture, adding boilerplate code, and more. It even comes with TypeScript preconfigured. Take some time to go through this repo before you start making changes. Whether you’re working on a brand new app like this or a legacy project, always take some time in the beginning to get a high-level understanding of how everything works.

Key things to look at are:

• The package.json so you can see which packages are used in the project.

• All of the config files so you know how things work under the hood.

• The test files because these give you a good idea of the major functionality of the app.

• Some of the actual code to see how developers are expected to write things and if anything can be improved.

After you’ve poked around a bit, go ahead and run the app with these commands:

[source, bash]
cd dashboard-server
npm start

You’ll see an output in the terminal like this that will let you know the app is running successfully:

[source, bash]
> dashboard-server@0.0.1 start
> nest start
[Nest] 20891  - 03/03/2023, 8:18:46 PM     LOG [NestFactory] Starting Nest application...
[Nest] 20891  - 03/03/2023, 8:18:46 PM     LOG [InstanceLoader] AppModule dependencies initialized +11ms
[Nest] 20891  - 03/03/2023, 8:18:46 PM     LOG [RoutesResolver] AppController {/}: +5ms
[Nest] 20891  - 03/03/2023, 8:18:46 PM     LOG [RouterExplorer] Mapped {/, GET} route +3ms
[Nest] 20891  - 03/03/2023, 8:18:46 PM     LOG [NestApplication] Nest application successfully started +1ms

This is where one of your first senior decisions comes up. How exactly are you going to test this back-end? Having a consistent environment for development will change how quickly you can test code and how much frustration the team experiences as the product grows and the team grows too.

Testing the Back-end Locally

Some popular tools you’ll see include Postman and Paw. You’ll work with Postman in this book (and many times in real life) because it has a free version. This is how you’ll be able to make requests to your endpoints with different headers, body values, and other values and see what response you get. That’s typically how you test the back-end before there is a UI available.

Remember, tools like this are here to help you move faster. Don’t get caught up in all of the tool options. At the end of the day, it doesn’t matter what you use for your local development as long as you’re able to make meaningful progress. Now that you have Postman available, make a GET request to +http://localhost:3000+. You should see +Hello world!+ as the response.

Figure 2-1. : GET request and response in Postman

Everyone will have a different preference for the tools they like to use for back-end testing and it typically doesn’t matter. However, it’s easier to troubleshoot when all of the devs on the team are in agreement on this particular tool. You can share your endpoint tests with other devs and that helps everyone find issues faster and more consistently. Eventually your back-end tests can serve as the documentation for the front-end. This will be something worth making a Jira ticket for so you can get it included in a sprint. 

Now that you know the app is working, you can start making changes to get it ready for the team.

Updating the README

Start by updating the +README.md+ with specific instructions on how to set up and run the app. There’s already a lot of good stuff in there, so you can trim it up a bit and add a few things. A basic update can look like:

[source, markdown]
# Dashboard Server
## Description
Back-end to support customers built on [Nest](https://github.com/nestjs/nest) framework TypeScript starter repository.
## Installation
```bash
$ npm install
```
## Running the app
```bash
# development
$ npm run start
# watch mode
$ npm run start:dev
# production mode
$ npm run start:prod
```
## Test
```bash
# unit tests
$ npm run test
# e2e tests
$ npm run test:e2e
# test coverage
$ npm run test:cov
```

It doesn’t have to be a huge doc that expands on your philosophical thoughts about code and the project. Give enough guidance that any dev could clone this repo and get it running. Other docs for the project will be stored somewhere else. As the repo grows, adding more details to the README will be helpful. This is a living doc that everyone should feel comfortable updating as part of their PRs when it’s needed.

Adding a CHANGELOG

As a best practice, it’s good to include a +CHANGELOG.md+ file in your repo. This will help you keep a close record of everything in each release over time. Having this record will help you determine which version of the app contains which updates and that comes in handy when there are issues with production. Here’s what the beginnings of this file can look like:

[source, markdown]
# CHANGELOG
## Guide
- Major releases include breaking changes and the version number will be incremented like, `x.0.0`
- Minor releases include new features, but no breaking changes and the version number will be incremented like, `0.x.0`
- Patch releases include bug fixes and performance enhancements and the version number will be incremented like, `0.0.x`
### 0.0.1
- Initial release

You might also consider setting specific rules on commit messages. If there’s a certain format you prefer, set up a tool like commitlint to enforce it early. This means you commit messages can include details like whether this is a fix or a chore. It can include ticket numbers if needed. You can also make it enforce things like the message starting with a verb to state what the change does.

That commit message might look like:

[souce, bash]
fix: update modal to send API call once

As a senior dev, you might be responsible for preparing the release PRs so it’s important to make sure updating this file gets included in that process. A good way to remember it is when you update the app version in +package.json+, update this file too.

In many projects, you may need to set up ESLint, Prettier, and TypeScript config files. This app comes with a lot of configs set by default, so you should go through them and add or remove values as needed. That’s all for the initial app setup. Now you can turn your attention to building the data schema.

Monolith and Microservice Architectures

This is a crucial point in the project because you’re setting the foundation for how everything will be built for the foreseeable future. You’ll need to think about the future of the project and how it might grow and what blockers that growth might run into. Take some time to make an architecture diagram. It doesn’t have to be fancy, but it does need to represent how the back-end interacts with different pieces of the entire application.

This includes everything the app touches ranging from the front-end to cron jobs. Cron jobs are tasks that run in the background of your system on a schedule. They can be written in TypeScript as well. The back-end is like your control center. It drives the development of everything else because it interacts with a number of systems. That’s why it’s so important to take your time and make this calculated decision.

The two based architectures you’ll run into are monoliths and microservices and I’ll cover the differences here. You can think of this as a guide to help you choose one or the other.

A monolith is when all of your back-end functionality is contained in a single codebase. You’ll see this a lot with enterprise apps. There’s one database and one server for the application. It gets deployed as a single unit that is connected to all of the services that you work with. All of the endpoints, maybe some cron jobs, and some third-party integrations will be handled here.

With a monolith, you get the benefit of all the code being in one place. That way you can get exposure to how the entirety of the system works and where changes need to be made. Setting up the infrastructure is straight-forward because you’ll only be deploying one app. Debugging is also easy because you can check the back-end holistically.

Building a monolith is a simpler approach, but it comes with drawbacks. For example, if some bug gets released to production and it causes errors at runtime that didn’t happen locally, the whole app is down for users. It can also be hard to appropriately scale the app. You might only have one endpoint that gets a large amount of traffic, but with a monolith, you have to scale the whole back-end which can cost a lot.

Figure 2-2 shows an example of what a monolithic back-end can look like:

Figure 2-2. : Architecture diagram for simple monolith

On the other hand, a microservice is the complete opposite of a monolith. If you have a directory or set of files dedicated to one piece of business logic in your monolith, it becomes its own API in the form of a microservice. With microservices, all of the back-end business logic is split into different chunks based on functionality. Each microservice has its own codebase, database, and server.

One of the biggest benefits of microservices is scaling. Since all of the business logic is separated into specific entities, you can ramp up resources for one endpoint while keeping the others the same. A really unique thing you can do is use different programming languages for different microservices. You might have a microservice written in Rust for concurrency handling, a microservice written in Python to serve a machine learning model, and a microservice written in TypeScript because that’s the dominant language used on the team.

Microservices give you more flexibility throughout development and deployment. There are a few drawbacks though. Debugging microservices can get tricky. It may be hard to figure out the source of an issue when you have to sift through all of the microservices you have running. The issue of data integrity may also come up if you have references to the same data across multiple microservices.

Figure 2-3 shows an example of what a microservices back-end can look like:

Figure 2-3. : Architecture diagram for simple microservices

Another architecture you’ll hear about is serverless. These can be used to handle all of the back-end functionality, you just have to be aware of their differences because it can make a huge difference in your cloud provider bills. But if you need a few lambda functions, for example, to handle very specific behavior, this could be a good addition to your back-end design. You might see serverless and monolithic architectures used together as the product grows.

Before microservices became a thing, there was service-oriented architecture (SOA). The main difference is that with SOA, all of the separate services are sharing the same database. This can still be a good approach if you’re app gets complex enough that it still might be a good idea to break out functionality into smaller chunks code-wise to keep things maintainable. I’m not going to dive into the details of SOA, but that you can consider if they should be used as part of your architecture.

The beautiful thing about architecture is that you can take the bits and pieces that work for your use case and put them together. As you work with microservices, you might hear about service meshes too. I encourage you to learn more about service meshes and how they are implemented, but I won’t cover them here.

Remember, as you go through the process of designing a back-end, it will take time. This isn’t something that should be rushed through and you should seek out as much feedback as possible from the other developers and teams you work with. Selecting any combination of these approaches cements the future development of the project because it’s not an easy task to switch the entire architecture to something else.

[source, javascript]
type Order {
  id: ID
  name: String
  total: Number
  products: Product[]
  createdAt: Date
  updatedAt: Date
}
type CreateOrderInput {
  name: String
  total: Number
  products: Product[]
}
type UpdateOrderInput {
  name: String
  total: Number
  products: Product[]
}
type Query {
  order(id: ID!): Order
  orders: Order[]
}
type Mutation {
    create(input: CreateOrderInput): Order
    update(input: UpdateOrderInput): Order
}

[source, javascript]
{
  Query: {
    order: (root, { id }) => find(orders, { id: id }),
  },
  Order: {
    products: (order) => filter(products, { orderId: order.id }),
  },
}
So when you're ready to make a request, the query would look like this:
[source, javascript]
query {
  order(id: 'fejiw-f4wt301-4tfw2g-g4t24') {
    name
    products {
      name
      price
    }
  }
}

Conclusion

In this chapter, you’ve learned about the Nest.js app you’ll be setting up to handle your back-end. You’ve learned about a few different architectures and API paradigms and their trade-offs. Now that you’ve done the initial setup for the Nest.js back-end and you know why each decision was made and some of the trade-offs, it’s time to turn your attention to the data schema.

Initial Considerations

To build out your data layer, you’ll go through these basic steps:

1. Make a diagram for a data schema. This should include the entities, their columns and data types, and their relationships.

2. Set up the database connection in the app. This example will use Prisma to connect to a PostgreSQL database, but there are other popular tools like Knex or Drizzle you can use. Some of the reasons you’re using Postgres is because it is open-source and has a long history of reliability. You’ll find it behind huge, complex apps that have been in production for decades and newer apps that have just been released.

3. Write the data schema in the app. Take your diagram and translate it into code.

4. Add seed data. This is to ensure that your database has the essential data it needs from the beginning. It’s also a great tool for adding data for testing in different environments.

5. Run migrations. After the connection is established and the schema and seed data are ready, you need to run a migration to get these changes to the database.

6. Test the database with simple SQL queries. Check that the tables are creating, updating and storing data as expected. Double-check the relations between tables by looking at foreign keys.

Some apps will have a more complex scenario than this, but you’ll see a process similar to this across all projects. You already know what data you’re expecting based on your conversations with Product, so now it’s time to make a good diagram for the dev team.

Diagramming the Data Schema

A diagram is a great visual reference for developers and QA to understand what values to expect and why. It’s a great tool to spark discussions between the front-end and back-end, and to document relations between data in a non-code way. Again, they don’t have to be anything fancy. Something developers tend to get hung up on are little details in places that don’t matter. As a senior dev, you have to be self-aware enough to notice when you start diving too deep on a task that doesn’t need that much attention.

These tables, for example, can be just like the ones below. When possible, you want to use a tool that connects directly to the database to create the visualization, like DBeaver. That way you can see the exact relationships you’ve defined. The important part is that it’s in a format that everyone can understand.

Figure 3-1. : This table shows the columns you can expect in the user table.

Figure 3-2. : This table has the columns for the orders information.

Figure 3-3. : In this table, there are the columns associated with a product.

Figure 3-4: A visual of how Figures 3-1, 3-2, and 3-3 are related.

Finally, in Figure 3-4, you can see how all of the tables are related to each other.

Now that you have the data schema documented. You’ll take this to the team and walk through what your thoughts are and ask for feedback. The front-end devs might have specific data format requests based on how they have to render elements. When it comes to the front-end, you typically shouldn’t plan the schema around it. It’s important to make sure that the queries they typically make, like searches and sorts, are thought of in the schema design though. Other devs might bring up security considerations.

By opening this up for everyone to think about, you end up with a stronger schema than if one person handled it alone. As a senior dev, you’ll learn how to be more confident with sharing your ideas and getting others to open up with theirs. Don’t be afraid to be wrong during these discussions because it might spark an idea for someone else.

It can be an uncomfortable place to be for a while because it feels like everyone is heavily scrutinizing your code and your technical prowess. They aren’t. You have to get used to receiving constructive feedback and that’s what will help you and the team build better code. The more you present your code and thoughts to the team, the quicker you’ll be able to improve things for everyone.

With the data schema diagramed and agreed upon by the front-end and back-end devs, you can start work on connecting the back-end to the database to create these tables. You’ll be working with a Postgres instance locally, but this can also be hosted on a server in the cloud.

Setting Up Postgres

You need to set up Postgres so you can get the connection information for your app. This will normally be handled by the team that manages the infrastructure for your production and non-production environments. You’ll still need your own local instance to make sure the changes you and the team are making work as expected. This is something you’d include in a Docker container if that’s how you wanted to keep the local environments consistent. As a senior dev, something else you’re responsible for thinking of is how to make onboarding smooth for new devs. Getting the local environment setup is one of the biggest hurdles for anyone joining a new team, so doing this will really pay off as the team and the product grows.

You can also download Postgres for free here. Follow their documentation to get everything up and running. You should set a master password or a password on the database you create. Doing some basic database security locally can help reveal potential issues early on.

If you do choose to create a database password, make sure you remember it. You’ll need it to connect your app to the database. You’ll also need the database name, port number, and database username. This project will name the database, dashboard. Unless you chose something other than the default values, the other credentials will be the following:

• Database username: postgres

• Database port number: 5432

The password depends on what you decided to do when you initially set up Postgres. If you installed via the linked download, then you can create your database in pgAdmin. It will look similar to this:

Figure 3-4. : Dashboard database in local Postgres

When you’re at this point, you’re ready to start creating the tables you diagramed earlier. We’re going to look at a couple of different approaches to create these tables: SQL statements and using an object-relational mapping (ORM) tool.

Basic SQL Commands to Know

Let’s start with using SQL statements. As a senior full-stack developer, it’s good to know some basic SQL commands. You don’t have to get super in-depth with things like views and indexing, but knowing enough to do create-read-update-delete (CRUD) operations goes a long way. One way to get started is by writing a statement to insert a new row into a table. You can do that with the following SQL:

[source, sql]
INSERT INTO table_name (column1, column2, column3 ) VALUES (value1, value2, value3);

You can change table_name to the table you want to insert the data into. The column1, column2, column3 fields represent the column name you want to put the data into. Finally, value1, value2, value3 are the values you want to add to the respective columns. For testing purposes, you can add new row entries like this:

[source, sql]
INSERT INTO Orders (id,name,total)
VALUES (4, 'Mark', 25.99)
RETURNING id;

To check that your data is stored like you expect it to be, you can query the data like this:

[source, sql]
SELECT * FROM Orders;

And to round things out, you may need to delete some data to clean up an example you’ve been working on. You can do that with something like this:

[source, sql]
DELETE FROM Orders
WHERE id = 4
RETURNING *;

If you can confidently use commands like these, you have enough SQL knowledge to double-check values directly in the database. Of course you can dive deeper into SQL and database management, but you don’t need to in order to be a good senior full-stack dev. With these little SQL commands in your background knowledge, let’s move on to the real tool you’ll likely be using for database operations from your app.

Deciding What ORM to Use to Work with the Data

Aside from choosing the framework for your back-end, the ORM tool is one of the big choices you’ll make for the lifetime of your project. It’s not an easy task to switch to a different ORM tool once you’ve started building. Nest.js comes with TypeORM, Sequelize, and Mongoose built in if you don’t have a preference. There are other commonly used ORM tools like Knex and Prisma, which you’ll be using.

All of these tools essentially do the same thing, but with a different flavor. The one you use will come down to the comfort level of the team and any limitations they may have. For this project, you’ve decided to go with Prisma because it’s the tool everyone on the team has used before, the documentation is well maintained, and it’s a tool used by a lot of tech teams across different projects in the industry. There’s a built-in ORM, but Prisma has more support, a bigger community, and it works really well with Postgres. Reasons like these make it a strong candidate and that’s why you and the team have selected it.

Now you’ll need to install it as a dev dependency in your project with the following command:

[source, bash]
npm install prisma @prisma/client --save-dev

With Prisma installed in your project, you need to set up some configs to connect the app to your Postgres database. Like any ORM, you have to initialize it in your project. With Prisma, you can run this command to do that:

[source, bash]
npx prisma init --datasource-provider postgresql
✔ Your Prisma schema was created at prisma/schema.prisma
  You can now open it in your favorite editor.
warn You already have a .gitignore file. Don't forget to add `.env` in it to not commit any private information.
Next steps:
1. Set the DATABASE_URL in the .env file to point to your existing database. If your database has no tables yet, read https://pris.ly/d/getting-started
2. Run prisma db pull to turn your database schema into a Prisma schema.
3. Run prisma generate to generate the Prisma Client. You can then start querying your database.
More information in our documentation:
https://pris.ly/d/getting-started

This will create the prisma directory and a .env file in your project. Make sure the .env file is in your .gitignore first. Then inside the prisma directory, you’ll find the schema.prisma and this is where you’ll set up your database connection and the models for the app. The .env file has a URL to your database and this is the connection string that will contain the database credentials. Update the value for DATABASE_URL in the .env file with your local credentials. It might look something like this:

[source, bash]
DATABASE_URL="postgresql://username:password@localhost:5432/dashboard"

Any values in your .env should be handled in your CI/CD pipeline. Work with the DevOps team to get this in place depending on the infrastructure setup. Now you can move over to the schema.prisma file and start writing your model. You’ve already done the hard part of thinking out how everything relates, so now you can confidently start coding. You’ll notice this is where you can see one of the biggest differences between the ORM tools. Prisma has its own flavor that you’ll have to get used to and it’s ok to refer to the docs often.

In your schema.prisma, you can start adding pieces of your model. Add the following code to the end of the file:

[source, javascript]
// schema.prisma
...
model User {
  id       Int       @id @default(autoincrement())
  email    String    @unique
  name     String
  products Product[]
}
model Product {
  id       Int    @id @default(autoincrement())
  name     String
  imageUrl String
  price    Float
  quantity Int
  User     User?  @relation(fields: [userId], references: [id])
  userId   Int?
}

Building models with Prisma is similar to writing objects or type definitions if you’re familiar with TypeScript. These models use special Prisma syntax for the types, but they match closely to the common types you work with. The most important thing to note is how relationships are defined between tables. On the Product table, you see we have an associated user id. On the User table, we have an array of products.

This is how Prisma defines relationships between tables and I highly encourage you to look through their documentation to learn about building more complex relationships. You might also want to look into the Prisma VS Code plugin to help make development smoother. For this app though, these few models will get you moving.

This completes the data schema for your app so far. Now it’s time to get this schema onto the database with a migration.

Writing Migrations

Migrations are the SQL queries statements by the ORM based on your schema definition. When you connect to the database to run a migration, you’re essentially executing SQL statements. That’s what makes ORM tools so useful. Instead of having to manually write the SQL for multiple tables, like you did earlier, you can write the query in JavaScript and the ORM will translate it to SQL. That’s why JavaScript developers use these tools so they don’t have to learn all of the details of SQL and database quirks.

To run a migration with Prisma, you’ll open your console and navigate to the root of the project and run this command:

[source, bash]
npx prisma migrate dev --name initialize_dashboard_db
Environment variables loaded from .env
Prisma schema loaded from prisma/schema.prisma
Datasource "db": PostgreSQL database "dashboard", schema "public" at "localhost:5432"
Applying migration `20230318132006_initialize_dashboard_db`
The following migration(s) have been created and applied from new schema changes:
migrations/
  └─ 20230318132006_initialize_dashboard_db/
    └─ migration.sql
Your database is now in sync with your schema.

Anytime you update your schema you’ll need to make a new migration to update the database. Make sure to give it a descriptive name so you can quickly understand what happened in the database history. This is super helpful if you run into data issues on the back-end because it’s easier to see what changes have been made and when. Every migration will automatically generate the timestamp at the beginning of the folder name in Prisma. The timestamp is important so the database knows what order to run the migrations.

Other tools will handle migrations a little differently. Knex, for example, lets you write migrations in pure SQL if you want and it generates migration files instead of folders. If you look in your project’s prisma directory, you should see a migrations folder with an subfolder. This is where the generated SQL for your migration is. That’s the beauty of an ORM. You can write in syntax you’re familiar with and it will generate the SQL for you. Take a look at the migration.sql file in the migration folder. You’ll see something like this:

[source, sql]
-- CreateTable
CREATE TABLE "User" (
    "id" SERIAL NOT NULL,
    "email" TEXT NOT NULL,
    "name" TEXT NOT NULL,
    CONSTRAINT "User_pkey" PRIMARY KEY ("id")
);
…

This is just the initial set up migration for the database and you’ll be adding more tables and columns and changing names as the app grows. When you run into issues with a migration, you can roll it back and you’ll learn how to do that in the debugging section of this chapter. For now, you have what you need to add some seed data to the database so you can start working on the rest of the app.

Seeding the Database

Since this is your local database, you’ll eventually want some test data to play with. You can add that as part of the dev env setup or have it as part of the setup for the real database. To start, create a new seed.ts file in the prisma directory. This is where you’ll use the Prisma Client to create some records. In your seed.ts file, add the following code:

[source, javascript]
// seed.ts
const { PrismaClient } = require('@prisma/client');
const db = new PrismaClient();
async function main() {
  const orderData = [
    {
      name: 'inv_924',
      quantity: 2,
      total: 92.42,
      createdAt: new Date('2023/02/21'),
      updatedAt: new Date('2023/02/24'),
    },
    {
      name: 'inv_925',
      quantity: 7,
      total: 24.56,
      createdAt: new Date('2023/02/21'),
      updatedAt: new Date('2023/02/24'),
    },
…

You can find the complete seed.ts file here: https://github.com/flippedcoder/dashboard-server/blob/main/prisma/seed.ts

This code allows you to connect to the database and insert these new rows into their respective tables. Then it disconnects from the database. In order to run this with Prisma, you need to add the seed config to your package.json like this:

[source, json]
...
"collectCoverageFrom": [
      "**/*.(t|j)s"
    ],
    "coverageDirectory": "../coverage",
    "testEnvironment": "node"
  },
  "prisma": {
    "seed": "ts-node prisma/seed.ts"
  }
}

This tells Prisma where to look for your seed file and how to execute it. With the configs and some data ready, you can run this command to actually insert the data into your Postrgres instance:

[source, bash]
npx prisma db seed
Environment variables loaded from .env
Running seed command `ts-node prisma/seed.ts` ..
ߌႠ The seed command has been executed.

Now if you look in your Postgres tables, you should see the values you wrote in seed.ts. This should be everything you need for your data concerns right now. Just to double-check, here’s a quick checklist you can go through when you think you’re finished setting everything up:

• Does the schema match the designs and functionality explained in the behavioral doc?

• Have you had at least one other dev look at it?

• Have you checked to make sure the schema works for all of the apps consuming data from this database?

There are more advanced things to consider as well that are out of scope for this book. Here’s a list of some of those things and links to more resources:

• Does your schema give room for the app to grow? https://www.oreilly.com/library/view/software-architecture-the/9781492086888/

• Is there a way to audit actions and the users who triggered them? https://www.auditboard.com/blog/what-is-an-audit-trail/

• Have you considered different user role levels for table operation access? https://www.imperva.com/learn/data-security/role-based-access-control-rbac/

These advanced topics could have their own chapters or even books. There are a wide range of questions you can ask here, but to keep things moving forward at this stage, don’t get too deep into the details. If you can answer these questions, explain the schema decisions to another dev, and you can demo it to the Product team, you’re good to go for now.

Take notes and make Jira tickets for any optimizations you see along the way. That way you can come back and actually work on the details because it’s documented in a way that Product considers. You’ve decided that the schema is in a good place and the tickets regarding different endpoints can be unblocked. This is when you’ll start working on the API that different apps will interact with to get data from the database you just set up.

Conclusion

In this chapter, you went through the process of drawing diagrams for your data, setting up a Postgres instance, and handling some initial setup with your ORM. You should feel pretty good about expanding your data schema from here because you’ve already asked a lot of questions about the future of the app.