Our NestJS Adoption Story: The Need for an Extensive Application Framework

There are various alternatives to the Scala/Play framework. This article presents a detailed overview of one alternative that we discovered, called NestJS. Our long discovery path began in response to the complexities associated with the previous framework. In this piece, we cover the reasons behind our transition to NestJS, the implementation process, as well as key takeaways following the transition.

1. MOTIVATION

Why we looked for an alternative to our Scala/Play Implementation

Throughout the development process, the Argus team had the REST API written in the Scala/Play framework. The Play framework is a functional and asynchronous framework that is adopted by a relatively big community.

The Play framework is also written in the Scala source code, which is a common programming language in the Big Data automotive world. Throughout the implementation stage, the team identified gaps in the system from unnecessary load, due to Scala/Play’s nature:

• Compared to other build tools out there, the open source build tool sbt is inefficient. It lacks documentation and engineers claim that it’s hard to learn and is slower than other build tools
• System overload – sometimes it would take 4 minutes just to bootstrap a service after restart

2. ARCHITECTURE

Why we decided to use NestJS

When looking to transition the REST APIs to an application framework, we wanted something that is lightweight and designed to be a microservice by nature. It’s important to note that for production microservices, we use either JavaScript or Scala, and there’s no reason to add or change the programming language. We also considered other options, such as ExpressJS and Akka-HTTP, but decided they were not a good fit given that they are libraries and not frameworks.

The requirements:

* Opinionated (read more about it here)

Some developers prefer not to have opinionated frameworks because they have many unknown rules and reactions. As developers, we prefer the known structure and best practices. Therefore, since we use this for basic use cases of REST API, there’s no reason to invent a new structure or practice ourselves.

**Static types

NestJS is not statically typed by nature but uses TypeScript by default, which brings static typing to JS. Typescript allows Javascript users to write cleaner and safer code, making them simple and easy to learn. Moreover, NestJS provides a great typing experience in the non-typed Javascript ecosystem.

*** Community size (& maturity)

The community size and maturity level of NestJS present bigger concerns that need to be addressed. Essentially, NestJS is a relatively new framework with limited usage among developers and without significant backing of a well-known organization. Moreover, the JavaScript ecosystem changes and evolves faster than the JVM ecosystem. Looking at the technology radar raised further questions regarding the maturity level of NestJS.

3. PROCESS

The gradual shift to NestJS

After examining the architecture and evaluating NestJS, we conducted a POC: creating a project template that contains all the common boilerplates to be used when implementing a new micro-service.

Breakdown of the goals for the project template:

• Basic REST API implementing CRUD
• Implement RDBMS integration with ORM
• Integrate with an OpenApi 3 tool
• Logging Expose metrics to Prometheus
• Perform tests with >80% coverage
• Dockerfile, Helm chart, Jenkins job

Besides ensuring that the NestJS works in our ecosystem, this project template taught our team to use NestJS with existing practices (ORM, metrics, tests, CI/CD, etc). Finally, we open-sourced our NestJS project boilerplate in GitHub, originally written by Vitaly Melnitchuk, Software Engineer at Argus.

4. ROLLBACK STRATEGY

Once we addressed the concerns regarding community size and maturity level, our team decided to check what we can do in a future case when NestJS is no longer developed and maintained. After a quick exploration, we understood that the TypeScript files can easily be used with ExpressJS. If one day our team decides to stop using NestJS, we will simply transition to ExpressJS in a matter of a few days.

5. IN RETROSPECT

Takeaways from using NestJS

• Those who oppose NestJS avoid opinionated frameworks and dependency injection in their JavaScript. We recommend you figure out whether this is the most recommended method of work for you.
• It took us a while to figure out how to properly work with NestJS’s module/ Dependency Injection best practices. We encourage you to take the time to learn how to use it correctly. Even though it is less intuitive, it will help in many ways (such as deployment, testing, cleanness, etc).
• One of the greatest benefits to using NestJS lies in its unit and integration testing practices. Use it and test everything!
• Before you adopt it, make your own project template.
• When using this NestJS framework (as well as any other 3rd party software) it is important to constantly monitor security vulnerabilities and update the code implementation with the latest patch updates.

6. SUMMARY

The widespread transition to NestJS allowed our team at Argus to truly scale our microservices, ensuring that they are stable and lightweight. When it comes to distributed microservices/cloud architectures, the lightweight factor is essential — from both the engineer and customer perspective.

 

Author: Barak Cohen, Software Team Leader
at Argus Cyber Security