Full-Stack To-Do List application with Node, NestJS, Angular 2+, Postgres, Liquibase and Docker (Part 3 of 9)

Taylor Buckner
5 min readOct 23, 2020

API Setup

The Branch

If you want to follow along with me, you can checkout the branch api-setup-start .

Lately I’ve been using a lot of NestJS. Now, I’ve been an Angular fanboy for a while, so naturally NestJS feels very comfortable to me. They’ve got many of the same concepts, design patterns, and a dependency injection mechanic that feel nearly identical to Angular’s. Not to mention that it sits on top of libraries such as Express or Fastify. So, you get this layer of abstraction that lets you build server-side applications quickly with a swappable core. Let’s get this bad-boy installed.

Generate

Following our Monorepo pattern, let’s make use of npx and NestJS’s schematics (hello Angular fan-people) to generate all the boilerplate needed for our application without installing a single dependency (yet).

# In Project Root
npx nest new api --skip-git

Now is also probably a good time to mention that I’ve been using Yarn for a while, so I’ll be using it in this project as well. Although I’m not sure there’s much of a performance gain anymore in the Yarn vs NPM debate.

? Which package manager would you ❤️ to use? (Use arrow keys)
npm
❯ yarn

You should see a new directory now in your project entitled api, provided you did not choose a different name. NestJS’s CLI automatically installs dependencies for you too, which is kinda cool 💅.

If you accidentally forgot to pass in the --skip-git flag when creating the API, you can CD into ./api (NOTE: This is very important. You MUST be in the API sub directory) and run:

# From ./api
rm -rf ./.git

Hello World

Now that we’ve got the API scaffolded, let’s take a quick look at what we’ve got.

Start the server with:

# From ./api
yarn start:dev

By default the API will start on localhost:3000 let’s see what we have there.

Wow. Such UI. Many elegance.

Sick. Ship it! 🚀

Let’s take a quick peek into the ./api/src directory.

Tree of api/src

Here we can see that we have a main.ts file that serves as the main entry point for our server side application, an app.module that provides metadata about our application as whole, an app.service which does much of the heavy lifting for our application and an app.controller which handles routing and requests.

If you’ve done some BE development in the Node world before, chances are this looks very familiar. chances are pretty strong that this looks very familiar if you’ve done some Angular development before, too! If you’re brand new to both, in the next few phases you’ll get an introduction to how to best capitalize on these different types of classes to build your very own Full-Stack web applications!

Recap

So far we’ve got:

  • A containerized Postgres Database
  • A containerized pgAdmin service wired up to our Postgres Database
  • Liquibase CLI installed and configured
  • Liquibase tracking our changes in the DB
  • A barebones NestJS API Application

That’s all fine and dandy. But, what about our users? Surely we don’t expect them to pull up Curl or Postman any time they want to work with their ToDo List, right?

Let’s give them a slick Angular web interface to work with!

Client Setup

There’s no time to get into the debate of ‘X framework is better than Y framework’, so let me save you some time and just tell you that Angular is Superior. 😂

All joking aside, if you need to move fast in a team-based setting, and quality matters, Angular provides a great approach to solving your SPA shaped problems.

The Branch

If you’re swapping branches, jump over to client-setup-start with:

git checkout origin client-setup-start

Generate

As before, we’re going to use npx to scaffold out an Angular application without installing the Angular CLI globally. Though, this time we’re going to pass a few more flags to make sure that we all have the flavor of Angular application that I prefer. This is not required, but veering from the path could potentially lead to confusion if you’re brand new to Angular, and I won’t be there to help you 🙁.

Let’s generate that SPA with:

# From the Project Root
npx ng new client --skipGit --routing=true --packageManager=yarn --style=scss

You should see something like this now generated in your project:

Barebones Angular application

If you’ve not done a ton of SPA application development, this could look a little daunting, but I can tell you from experience that there’s nothing to fear here. Although there looks like a large quantity of files, many of the files we see are just a side effect of separating concerns well. Our meat and potatoes is gonna hang out in the client/src/app directory. This will be where we create much of our application’s components and services.

Serve

Now that we’ve got the application generated, let’s spin it up!

# From ./client
yarn start

By default, the SPA application will start up on localhost:4200. Once the development server has cranked into gear, you should see something like this:

So pretty!

Recap

Now we have:

  • A containerized Postgres Database
  • A containerized pgAdmin service wired up to our Postgres Database
  • Liquibase CLI installed and configured
  • Liquibase tracking our changes in the DB
  • A barebones NestJS API Application
  • A barebones Angular SPA Application

But this doesn’t look anything like an app to manage a ToDo list. And as a matter of fact, our API doesn’t really match up with that goal either.

--

--