Full-Stack To-Do List application with Node, NestJS, Angular 2+, Postgres, Liquibase and Docker (Part 3 of 9)
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.
Sick. Ship it! 🚀
Let’s take a quick peek into the ./api/src
directory.
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:
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:
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.