Exploring NestJS Workspace

In the previous article, we saw why and how to use NestJS, in this article we will go through the NestJS workspace.

NestJS Workspace

NestJS supports 2 modes:

• Standard Mode
• monorepo mode

Standard Mode

When we create a new Application using nest new we are using standard mode. In standard mode Typescript's tsc will be used as the compiler. Below is how our App looks like in Standard Mode.

monorepo mode

A monorepo mode is where we have more than one application, generally, it's one App and one Library, we already have App, let's add a Library by using the below command. It will add a new Library project.

nest generate lib shoppingLib

Now as we are in monorepo mode, rather than tsc webpack will be used as a build tool. You can open the nest-cli.json and notice below lines of code being added. compilerOptions has webpack value to true.

{
  "collection": "@nestjs/schematics",
  "sourceRoot": "src",
  "projects": {
    "shopping-lib": {
      "type": "library",
      "root": "libs/shopping-lib",
      "entryFile": "index",
      "sourceRoot": "libs/shopping-lib/src",
      "compilerOptions": {
        "tsConfigPath": "libs/shopping-lib/tsconfig.lib.json"
      }
    }
  },
  "compilerOptions": {
    "webpack": true
  }
}

And After adding a Library the App structure will look like below

Let's go through some important files:
tsconfig.json: The configuration file to be used while running tsc to transpile your files.

• nest-cli.json: The Nest CLI config file, has a list of projects when we are in monorepo mode, and defines which build tool we are using webpack in monorepo and by default its tsc .
• main.ts: This is the entry file for our NestJS application and has bootstrap() function to bootstrap our app, by default server runs on Port 3000, you can change it and while using on production we can use an environment variable.
• app.module.ts: This is our root module, which has registered all modules, controllers, services.
• app.controller.ts: Our application should have at least one controller defined and this is our default controller.
• app.service.ts: We can have multiple services in our application this is a sample service added as a part of the workspace, this is optional.
• Libraries: Libraries can have reusable code like service, pipes, guards or interceptors.

Tool for FullStack App with NestJS

If you are building FullStack Application with Angular/ReactJS and want to use NestJS as a backend you should consider Nx Dev Tools which provides a lot of features. 

Conclusion

We learned about the NestJS workspace and 2 modes which are available and how they differ, and how we can convert our workspace to monorepo mode. We also saw different files are which important and why they are useful. In the next post, we will discuss Controllers and how we can create and configure endpoints.

Comments

[leob]

Seems a pity that just because you're adding a library to your project you now suddenly need Webpack and its complexities, instead of just simply TSC. Why?

[Santosh Yadav]

Let me try to explain why it is needed, when we create monorepo these are 2 separate workspaces, both having there own tsconfig so they will be compiled separately, so when build is created the final main.js has to know both or multiple files which are included via a library this is where webpack is required.

[leob]

Right, this is what you would probably solve in Express.js with a separate npm component. But that's arguable more hassle, I'll grant you that. Do you think that Nest.js also has advantages for devs who don't have a background in Angular and or .Net/Java and so on?

[Santosh Yadav]

Every framework requires has some learning curve, what I like about NestJS is for large enterprise application it provides a clean architecture, you don't have to think which code needs to be added where. While using other frameworks with JavaScript developers do it as per there convenience, every organization may have different way to architect your app, which is challenge when you change the job.

[leob]

Makes total sense! So, it might be more useful/compelling in a corporate setting than for a solo dev/hobbyist or small scale project. (but maybe even there)