Despite the internet’s best memelords attempts to convince me otherwise, I absolutely love JavaScript and TypeScript. It’s not necessarily the languages themselves that I like, but there’s something about how the ecosystem has constructed itself and the design patterns that have emerged that totally jive with me. To that end, whenever I start up a greenfield project that requires an API, I immediately look towards Node/Express rather than doing something more Enterprise-y like a Spring app. I was recently exposed to NestJS as a way to build scalable progressive server-side applications and my mind is TOTALLY blown.
I work in a company who works on a Java web application with an Angular front-end. When my coworkers ask me what NestJS is, the best thing that I can tell them is that Jersey and Angular had a baby, and that baby is one cool customer.
NestJS comes bundled with its own CLI, making it easy to build a server-side app with a standard structure. The first thing you notice is that the CLI syntax is remarkably similar to the Angular CLI. You can create a new app
new new my-app
This will build up a shell application with a default app module, an app controller, a default service, and auto-wired automated testing all throughout.
You can create a new controller
nest generate controller my-controller
This will create a new controller and auto-register it with the default app module
You can generate a service
nest generate service my-service
This will create a new service and auto-register it with the default app module.
Getting the picture? If you’re an Angular user, this will feel very similar. Once you’re done building your app, it will feel very similar to an Angular application. Of course, it is in actuality entirely different because this is a server-side application rather than a browser-based app.
The CLI is just the beginning. It gets really striking when you look at the how the apps are constructed. It is obvious that NestJS was inspired by the structure of Angular. It has:
OK, cool - the file structure is like Angular. What are you talking about with Jersey?
For those of you that have built NodeJS APIs, you’re probably used to ExpressJS and the callback-based structure of declaring routes:
router.get("/foo", (req, res) => {
res.send("bar!");
})
This works just fine, but it can get unwieldy. It gets especially tricky when you start introducing middleware like authentication. It gets even worse when you try to deal with the asynchronous world of JavaScript and you either end up in Promise Hell or CallBack Hell. Finally, this code is much harder to reason and it is in no way self-documenting. This is where NestJS took a lesson and adopted some of the techniques that developers who are comfortable with Jersey might enjoy.
API endpoints are declared and registered via decorators. So the above example would instead look like:
@Get("foo")
async getFoo(): Promise {
return "bar";
}
You can also use decorators to do things like API documentation, registration of middleware like authentication, and overrides of HTTP status codes
@Get("foo")
@ApiOperation({
summary: "Gets foo",
description: "This endpoint will retrieve foo",
})
@ApiResponse({ status: 200, description: "Record found." })
@ApiResponse({ status: 403, description: "Forbidden." })
@UseGuards(AuthGuard())
async getFoo(): Promise {
return "bar";
}
This blog post could go on forever if I let it, but the amount of stuff that NestJS has right out of the box in incredible. It includes, but is not limited to:
If you’re looking to build a greenfield app with production-quality code, I urge you to give NestJS a try. Check them out here.