In this tutorial, you learn how to build API's with NestJS and Nx Workspace. The goal is to give you a nice starting point that's easy to extend. Additionally, it will serve as a reference for later posts and series that I intend to write.
This post serves as an introduction to the technology stack and goes over the tutorials in the series.
NestJS is a framework for building API's using Node.js and TypeScript. NestJS provides an opinionated API on top of Express (or optionally Fastify) and makes heavy use of TypeScript classes and decorators, enabling a declarative way to quickly add new functionality without writing a lot of code.
NestJS has great documentation and is actively maintained. There are a lot of useful libraries provided by the project itself, and there is a growing community that provides even more functionality. Besides that, NestJS is easy to extend if the functionality you need does not exist.
Here are a few NestJS concepts you should be aware of when going through this series.
The architecture from NestJS is inspired by Angular. It uses modules to encapsulate functionality in standalone, reusable blocks that can be imported by other modules. Modules tie the other components together, and make sure dependency injection works.
The Controllers are used to build a RESTful API. They allow building any HTTP api that you can dream of, and does so in a clean and declarative matter by adding methods to TypeScript classes, and decorate them. These Controllers define the external REST API, most of the heavy lifting is done through Providers.
The Providers are injected into the Controllers, Resolvers or other Providers, and handle their requests. Things like accessing a database or calling into third-party API's or libraries are all done in Providers. This keeps the Controllers clean and focussed, and makes it easy to share the functionality with other parts of the application.
The Resolvers are used to build a GraphQL API. They allow building a GraphQL API using a code-first approach. That means that you don't need use GraphQL's Schema Definition Language (SDL) to define the API, but rather TypeScript code. Like the controllers, the Resolvers define the external API, and use Providers to do the heavy lifting.
Nx combines a mono-repository structure with CLI tools to develop and manage one or more applications and libraries, all within the same repository. Nx encourages code collaboration, unified testing, and optimizes builds and testing performances.
Nx is an amazing tool for building medium or large sized applications. Using a mono-repo allows you to easily share code between various parts of the project, without having to worry about the these parts being out of sync. Nx is smart in the sense that it knows which parts of the app relate to each other. Read more about the Dependency Graph below.
Here are a few Nx concepts you should be aware of when going through this series.
The workspace is defined on the root of the repository, and consists of one or more projects, which can be either an application or a library. The workspace uses either the Nx CLI or Angular CLI to serve, test, build and lint the projects. The workspace is defined in the files
if using the Angular CLI).
In Nx, the applications (or apps), are the projects that contain a runnable application. Applications should be light-weight, and expose the functionality defined in the libraries.
The libraries (or libs), are the projects that implement the functionality for the apps. The libraries define an external API that can be consumed by the apps and other libs.
The actual functionality of the Nx workspace is defined by the plugins that are installed. Nx comes with quite a few official plugins that add support for, for example, Angular, Node, Next, React and Web Components. Additionally, there is a growing list of community plugins.
The Dependency Graph, or dep graph, is an automatically generated schema that shows how different parts of the monorepo depend on each other. Nx uses this information to intelligently execute commands on parts of the workspace. For example, it will only re-build projects that are actually changed, or when one of the dependencies are change.
The project structure
In this series though, we use a simple structure. We build an app called
that consumes the libraries
, like this:
apps/api libs/core libs/course libs/<library> (any other functionality goes here).
Tutorial in this series
This series consists of four tutorials that, when finished, result in a project that is solid basis that's easy to extend.
To start the project, we create an empty Nx Workspace and take a look around to see what it consists of. We install and configure some tools to automatically format the code on each commit. Having this in place makes sure all future code has a similar style.
After creating the project, we use the official NestJS plugin for Nx to create an application called api with a library called core. The core library is responsible for exporting the runtime configuration, and is consumed by the api.
When these parts are in place, we move on to adding actual functionality to the api. After installing the needed dependencies and configure the GraphQL Module for NestJS, we implement a GraphQL resolver and add a simple query that returns the servers' uptime.
Once this is all done, the API is ready to ship! After building the project locally and making sure it all works as expected, we add the configuration to deploy it to Heroku.
First of all, thanks to the reviewers of this series 🙏:
Thank YOU for reading my article, I hope it was useful. Feel free to reach out and follow me on Twitter or leave a comment on DEV! 🐝