Introduction

Working With Monorepos

Workspaces

Shared Configs

Frontend

Schema

Backend

Introduction and Getting Started

Analyzing

Designing the Customer-facing UI with TailwindCSS

Data Model

Analysis and Design

PostgreSQL Ranges

The Provider Table

The Booking Table

Modelling with advanced Postgres features

Tailwind CSS

Foundation

Frontend State

Shared Components

Select Day

Frontend UI

Introducing tRPC

Connecting to tRPC

Refining the tRPC setup

Connecting to the Database

Generating Zod schemas

Endpoints

Testing tRPC Endpoints

Testing With the Database

Testing Frontend

Testing

Completing the Select Date Page

Infrastructure for Ranges

Completing Booking

Connecting The Dots

Conclusion and extra resources

This comprehensive course will equip you with the skills and knowledge to build modern full-stack applications using TypeScript, TailwindCSS, tRPC, and PostgreSQL. You will learn how to create a robust and scalable application architecture, from the backend data layer to the frontend UI.

PostgreSQL

NodeJS

Knex

React

TypeScript

tRPC

Monorepos simplify code development and can be split when necessary.

Setting up npm workspaces in our monorepo

Setting up shared Typescript, ESLint and Prettier configs

Master full-stack development with a single repository for everything!

Learn the art of full-stack development with this comprehensive course. Through implementing the latest technologies and techniques, the course directly addresses the most common challenges full-stack developers face:
- **Code consistency and sharing:** Monorepos eliminate the need for multiple repositories, ensuring consistent code across your application and facilitating seamless code sharing.
- **Technology integration:** Learn how to integrate modern technologies like TypeScript, Tailwind CSS, and tRPC, empowering you to build robust and maintainable applications.
- **Database management:** Master advanced PostgreSQL features to optimize data storage, retrieval, and manipulation, ensuring a high-performance and scalable backend.

Build type-safe full-stack applications with database-centric strategies

This comprehensive full-stack development course covers monorepos, TypeScript, Tailwind CSS, tRPC, and PostgreSQL, empowering you to build modern, scalable applications. Structured into 7 modules of bite-sized lessons, each module is designed to be engaging and informative, combining video lectures, hands-on coding exercises, and real-world examples.

Fullstack Typescript with TailwindCSS and tRPC Using Modern Features of PostgreSQL

Writing PostgreSQL ranges for the application database.

Breaking down the UI to build it with Tailwind CSS

Master monorepos for streamlined development workflows and enhanced collaboration

Implement TypeScript for type-safe code that prevents errors and improves maintainability

Utilize Tailwind CSS to create consistent and beautiful user interfaces

Employ tRPC for seamless data exchange between frontend and backend

Harness advanced PostgreSQL features for optimized data storage, retrieval, and manipulation

Build modern, scalable full-stack applications using a unified approach

While the concept of a monorepo, a single repository for everything, may seem unconventional to those unfamiliar with the approach, it aligns with various development best practices and can be a sound design decision."

Simplicity: A principle I apply is always to do the simplest thing that could work and then build from there when necessary. Of course, you should take advantage of your knowledge and skills; there are times when something might not objectively be the simplest thing that could work but because you are very comfortable with it and know that it will bring value, you choose to do it anyway.

Organicity: When building something I haven't tried before, I find it's better to be humble and expect that I am unable to see where things are going. This is harder than it sounds, at least for me. I tend to think up solutions and feel confident that they will work. Still, years of experience tell me that I am often wrong and it's better to let the design evolve.

Modularity: When doing something that I am not sure how will end up, I start writing the code as close to the place where it will be used as possible. For example, if I am going to create a new form in the UI, I will write it inline in the page component or whatever the container might be. When I conclude that the direction seems sound, I might extract it into a separate component or function. Likewise, if it grows larger than just a "utility", I will move it into a separate file, and if it becomes large enough to require splitting up, I will create a separate folder for it. From there, it might turn out that the component can be used in other places, so I move it to some shared folder. If it's even more general-purpose, it might justify its own "package" at monorepo level; the final level is as a package in a package repository like npm.

In short, a good reason to start with a single repository is because is the simpler thing to do. Why create separate repositories even if you have separate services, apps, or libraries? If you discover at some point that the tradeoff is no longer in favor, split things up. The most famous example is Google, whose entire code is located in a single repository.

---
title: Working With Monorepos
description: Working with monorepos
isPublicLesson: true
privateVideoUrl: https://stream.mux.com/wnU4UUH601qP5SIyyrn4hZwjMOCjvQ2TM600RgBRTrKow.m3u8
---

## A Single Repository for Everything

While the concept of a monorepo, a single repository for everything, may seem unconventional to those unfamiliar with the approach, it aligns with various development best practices and can be a sound design decision."

Simplicity: A principle I apply is always to do the simplest thing that could work and then build from there when necessary. Of course, you should take advantage of your knowledge and skills; there are times when something might not objectively be the simplest thing that could work but because you are very comfortable with it and know that it will bring value, you choose to do it anyway.

Organicity: When building something I haven't tried before, I find it's better to be humble and expect that I am unable to see where things are going. This is harder than it sounds, at least for me. I tend to think up solutions and feel confident that they will work. Still, years of experience tell me that I am often wrong and it's better to let the design evolve.

The code journey:
![](code-journey.png)

Modularity: When doing something that I am not sure how will end up, I start writing the code as close to the place where it will be used as possible. For example, if I am going to create a new form in the UI, I will write it inline in the page component or whatever the container might be. When I conclude that the direction seems sound, I might extract it into a separate component or function. Likewise, if it grows larger than just a "utility", I will move it into a separate file, and if it becomes large enough to require splitting up, I will create a separate folder for it. From there, it might turn out that the component can be used in other places, so I move it to some shared folder. If it's even more general-purpose, it might justify its own "package" at monorepo level; the final level is as a package in a package repository like npm.

In short, a good reason to start with a single repository is because is the simpler thing to do. Why create separate repositories even if you have separate services, apps, or libraries? If you discover at some point that the tradeoff is no longer in favor, split things up. The most famous example is Google, whose entire code is located in a single repository.

## Monorepo tradeoffs

Pros:

-   Easier to share configurations like linter settings
-   Synchronized versioning and branching
-   Easier onboarding

Cons:

-   Higher risk of merge conflicts (However, these conflicts are typically straightforward to resolve and can be viewed as "compile-time errors" that would otherwise manifest as runtime errors)
-   Larger disk space consumption and time spent pulling
-   Configuration settings must work for everyone
-   Potential compliance issues


Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Fullstack Typescript with TailwindCSS and tRPC Using Modern Features of PostgreSQL

Module 1: Introduction and Getting Started

Introduction:

Start Here

Lesson 1: (3:09)

Introduction

Lesson 2: (6:35)

Working With Monorepos

Lesson 3: (6:45)

Workspaces

Lesson 4: (17:56)

Shared Configs

Lesson 5: (9:27)

Frontend

Lesson 6: (16:20)

Schema

Lesson 7: (5:21)

Backend

Module 2: Analysis and Design

Lesson 1: (3:09)

Analyzing

Lesson 2: (4:04)

Designing the Customer-facing UI with TailwindCSS

Lesson 3: (2:49)

Data Model

Module 3: Modelling with advanced Postgres features

Lesson 1: (6:18)

PostgreSQL Ranges

Lesson 2: (16:10)

The Provider Table

Lesson 3: (4:47)

The Booking Table

Module 4: Frontend UI

Lesson 1: (1:25)

Tailwind CSS

Lesson 2: (7:58)

Foundation

Lesson 3: (21:53)

Frontend State

Lesson 4: (4:52)

Shared Components

Lesson 5: (16:13)

Select Day

Module 5: Endpoints

Lesson 1: (7:45)

Introducing tRPC

Lesson 2: (17:22)

Connecting to tRPC

Lesson 3: (7:22)

Refining the tRPC setup

Lesson 4: (7:28)

Connecting to the Database

Lesson 5: (4:56)

Generating Zod schemas

Module 6: Testing

Lesson 1: (4:33)

Testing tRPC Endpoints

Lesson 2: (25:00)

Testing With the Database

Lesson 3: (12:37)

Testing Frontend

Module 7: Connecting The Dots

Lesson 1: (21:07)

Completing the Select Date Page

Lesson 2: (14:07)

Infrastructure for Ranges

Lesson 3: (15:49)

Completing Booking

Module 8: Conclusion and extra resources

Lesson 1: (1:02)

Conclusion and extra resources

Working With Monorepos