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.
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
Why we decided to use NestJS
* 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.
*** Community size (& maturity)
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
- 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.
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