How Nest.js Templates Can Centralize Your Node.js Configuration

In the software industry, this is a must if you want to stay relevant in the market and grow with the sector, and it applies to both companies and engineers. To achieve this, you not only have to keep yourself up-to-date on new technologies, but also be familiar with existing software paradigms, patterns, and architectures. And that’s quite a task. 

Nest.js is a way to go

In this post, we’ll talk about one of the most recent and reliable server-side frameworks that’s giving the community a lot to talk about: Nest.js. Don’t know why you would move from using Express? Let’s see a high-level example.

Example context

Developing software-as-a-service, some of your goals might be:

• Scale quickly
• Keep a constant and effective communication
• Iterate strategically
• Keep simple

To accomplish these goals you might use guidelines like the Twelve-Factor App, which suggests, among other things, isolating dependencies. Here is where a highly opinionated, structured, and scalable framework like Nest comes to the rescue to help us achieve those goals.

In the process of developing software, as your product and your company grow, you can find yourself in the middle of something called “dependency hell.” I've been there several times, and its demons are really scary. 

Since I started down the developer’s path, to this day, in every project, something you are going to spend time and effort on is trying to not mess up a project’s dependencies. I’ve seen projects where the development team avoids using new libraries just because of the mess they have in their dependencies. This might be caused by several reasons, for example, different engineers in the project that are not working in the company anymore, or lack of tracing the installed dependencies. 

For some teams, it’s easier to spend several weeks coding a function from scratch that could be performed with a library using a two-minute installation. Even when you have everything in order in your project, someone in your company may be spending the same amount of time installing and maintaining the same libraries. Or maybe that someone could be you in the future, duplicating your efforts. The advantage of centralizing the effort is hard to ignore.

You can define your product-line engineering by having a template where you are going to centralize all the architecture, guidelines, and dependencies that you’re going to constantly use in all your company’s projects. Templates let you scale fast because the configuration for a service is universal and hidden away from the engineers that are not involved with the maintenance of the template itself.

Where does Nest.js fit?

“Okay, sounds great,” you might be thinking. “But where does Nest fit in all of this?”

Glad you asked! 

Nest.js is designed to simplify all the standardization your template needs. Through its native support of the latest version of TypeScript, decorators, and Controllers, you can define, for example, basic controller configuration so that all the engineers can start from your specification already set up instead of trying to search in the forums for how to do something. For example, you might have Swagger already configured.

Each developer has their Swagger definition and implementation already set up.

@Controller('api/template')
export class TemplateController {

@Get() 
@ApiOperation({ 
summary: 'summary goes here' 
}) 
@ApiResponse({ 
status: 200, 
description: 'description goes here', 
schema: { ...define schema here... } 
}) 
async findAll(): Promise<string> {}
}

Beautiful, isn’t it?

A quick comparison with Express.js

In order to accomplish the same result in other frameworks like Express, where you may have more freedom, you can have your Swagger definition on a JSON file like this:

module.exports = {    
    swagger: "3.36.2",
    swaggerDefinition:{
        openapi: "3.0.2",
        info: {
            title: "Testing Api Documentation",
            version: "1.0.0",
            description: "Testing purpose Swagger Definition"
        },
        schemes: [
            "http",
            "https"
        ],
        components:{
            securitySchemes:{
               ApiAuth:{
                    type: "apiKey",
                    in: "header",
                    name: "Authorization" 
                },                    
            }
       }
    },            
    apis: [
        "routes/authRoutes.js"
    ],
    tags: [
        {
          name: "Testing API",
          description: "Methods"
        }
    ]
};

And you might have a comment in every route file with the definition in YAML format that will include some of your endpoints — let’s say a POST method for authentication:

/**
  * @swagger
  * /users/authenticate:
  *   post:
  *     summary: Authenticate user TOKEN
  *     description:
  *     tags:
  *       - Authenticate user
  *     parameters:
  *       - name: body
  *         in: body
  *         required: true
  *         schema:
  *           type: object
  *           required:
  *             - email
  *             - password
  *           properties:
  *             email:
  *               type: string
  *             password:
  *               type: string
  *           example: {
  *             "email": "testing@gmail.com",
  *             "password": "ValidPassword"
  *           }
  *     responses:
  *       201:
  *         description: User Authenticated!
  *         schema:
  *           type: object
  *           properties:
  *             success:
  *               type: boolean
  *             data:
  *               type: string
  *         examples:
  *           application/json: {
  *             success: true,
  *             data: "data"
  *           }
  *       401:
  *         description: Error
  *         schema:
  *           type: object
  * /

So you can use one or the other definition for your endpoints (JSON/YAML, centralized or distributed). You can also use both of them, as we did in this example. And here comes the big “BUT.” Did you notice that we used an OAS 3 definition with an OAS 2 implementation? And it still runs.

No errors are shown until…

It is not sending the body! And this is just a simple example of little misconfigurations that you can get while you’re using Express. 

At this point, you may be thinking that this is not quite common because you already have a project with everything configured, but isn’t that the point of templating?

Here you have the correction with the implementation with OAS 3. Let’s say you have to change this in all the projects where you might have this little error. That’s quite a task.

/**
  * @swagger
  * /users/authenticate:
  *   post:
  *     summary: Authenticate user TOKEN
  *     description:
  *     tags:
  *       - Authenticate user
  *     requestBody:
  *       description: Object with email and password
  *       required: true
  *       content:
  *         application/json:
  *           name: testing!!!
  *           schema:
  *             type: object
  *             properties:
  *               email:
  *                 type: string
  *               password:
  *                 type: string
  *             example: {
  *               "email": "testing@gmail.com",
  *               "password": "ValidPassword#"
  *             }
  *     responses:
  *       201:
  *         description: User Authenticated!
  *         schema:
  *           type: object
  *           properties:
  *             success:
  *               type: boolean
  *             data:
  *               type: string
  *         examples:
  *           application/json: {
  *             success: true,
  *             data: "data"
  *           }
  *       401:
  *         description: Error
  *         schema:
  *           type: object
  */

Even having the correct configurations and having replicated them on all your projects, it’s a lot of code, a lot of effort, a lot of time — time that, as we have shown above in the NestJS example, could be optimized. And we are talking about only configurations! All of this is to say nothing of the app itself.

Conclusion

The opportunities can go from simple implementations of some in-house architecture passing through the definition in the template, to the basis for Dockerizing every project under the same structure, to any place your imagination might fly. It’s a great chance to modernize your workflow using a minimalistic version of the convention-over-configuration paradigm.

Making these high-level decisions can be tricky. Even this approach has to pass through the Build-Measure-Learn loop to fit every company’s own needs. But you can never go wrong standardizing your design patterns, and they are essential to building high-quality software and saving time, which you can spend doing anything else — barbecuing, climbing, skateboarding, or, let’s be honest, writing more code.

Here at Fullstack Labs, we have helped a lot of companies stay relevant and maintain high standards throughout the development process of each solution we get involved in. Let’s talk and get your projects on the right track to reach your goals.