Comment by adamkl | Hacker News Reader

Comment by adamkl | Hacker News Reader

Nest.js is a great framework, with excellent documentation, but it can be quite heavy weight (from a coding and concepts perspective) and alienating to JavaScript devs without a background in C#/Java.

Its basically Spring/.Net MVC implemented in TypeScript. That makes it a great choice for .Net/Java developers who are transitioning to coding for Node.js, but for anyone without that background, it comes with a steep learning curve (Dependency Injection, Inversion Of Control, Aspect Oriented Programming... all the usual suspects of "enterprise" application development).

I'd say its positioned to become very popular (and you can see its trending strongly upwards on npmtrends.com) because so many enterprises are transitioning towards Node.js. Its like a cozy blanket for ex .Net/Java developers.

I always find it amusing that that Nest.js is a back-end framework, that was inspired by a front-end framework, which was inspired by a back-end framework. (Nest.js -> Angular -> Spring MVC). :-)

Strongly agree - as someone much more comfortable within the node ecosystem, there's several libraries I'd rather use in place of Nest's choices. However it makes a great starting point for people not aware of the other options and who need an opinionated bootstrap.

If anyone's wondering my current template is routing-controllers, class-validator, tssyringe, and sequelize-typescript.

Separate issue, but if anyone can suggest a different query builder / orm in typescript that'd be truly appreciated. Imo typeorm is too much of an abstraction and sequelize works but requires custom types ever since v5

Until yesterday, I would've voted Prisma. There was actually a Show HN post recently that debuted Zapatos: https://news.ycombinator.com/item?id=23273543. The top comment also mentions mammoth: https://github.com/Ff00ff/mammoth. Probably going to switch over to one of them as they're closer to raw to raw SQl and well typed.

I like MikroORM, but haven't yet used it in a production environment.

Class-validatdor puts you in a deep hole, though. Consider ajv; it's what Fastify uses under the hood. (Honestly, just consider Fastify. It's great.)

I just wanted to link to eropple's comment[0] as he provides a good counterpoint to the discussion of the merits of Nest.js

[0]: https://news.ycombinator.com/item?id=23302463

The dependency injection seems to miss the point of dependency injection though. I'd love to be proven wrong but, in the documentation, under the providers section [0], they seem to be wiring CatsService directly as a concrete implementation because, I guess, interfaces are erased in compile time. In C# such problems don't exist. Weird, as they also mention SOLID.

[0]: https://docs.nestjs.com/providers

Its true that, by default, you use a Class when wiring up the DI container because as you guessed, the interfaces are erased during transpilation.

You can still achieve the loose coupling of DI by using custom providers [0]. Basically, this approach is the full syntax for defining providers and gives you the most flexibility (inject based on Class or token, provide factories, simple values, class instances, etc).

[0]: https://docs.nestjs.com/fundamentals/custom-providers#custom...

Then why not use libraries like io-ts [0] to define interfaces, which survive the compilation, can test untyped objects against the given schema and could also be used as DI tokens. Still, depending on structural typing here feels like a hack, but I never did this so maybe someone with experience in a large codebase can chime in.

Anyway, IMHO, Typescript isn't designed for dependency injection in mind. Microsoft also has a DI library [1] but it feels like too much wiring to compensate for the lack of compiled interfaces.

[0]: https://github.com/gcanti/io-ts

[1]: https://github.com/Microsoft/tsyringe

I'd say that tsyringe is about the same level of "wiring" that one would see with a Nest.JS module. The major difference being it handles the implicit wiring a bit better. Nest.JS will freak out if you don't explicitly tell it what to do. (could be a good thing?)

I'm sorry, but I'm going to have to strongly disagree on your first point.

I've used Nest.js extensively over the past year or so and I find the documentation extremely lacking. Sure there might be a lot of hello-world style examples, but advanced or sometimes even basic usage is often not well documented and the actual API itself is completely undocumented (you might have an example of 1 way to call a function, but that's it).

You often have to piece together examples from various "Documentation" pages, which should really be called Examples, or dive deep into source code to find the list of functions or parameters that are available.

Another pain point is that I sometimes ran into extremely hard to diagnose issues with Nest. I had to add Swagger documentation to a project recently, which uses previous version of Nest.js (v6). It turns out that the latest version of @nestjs/swagger is not compatible with this version of Nest.js, but the docs don't mention which version you should install to get it working.

I installed the library as described in docs for Nest.js v6 and used their example to include it in the project. When I started the application, it didn't print any errors or really produce any useful output at all (besides all the DI logs and the fact that initialization was successful). Instead, the application simply fails to print "Application Started" and it just doesn't listen on a port.

I fixed that by comparing release dates of older @nestjs/swagger versions with release date of NestJS version that we were using. There's nothing to go on in cases like this and whenever something like this happens (multiple times over the past year for us), you can probably imagine how frustrating that is.

With TypeORM, we also frequently run into issues that haven't been addressed in years[1], missing functionality in their query builder[2] and strange behavior in general.

I commented about this previously[3], also I should point out that I appreciate the effort they are making, but I would recommend that anyone considering using Nest.js in production takes a hard look and really evaluates whether it supports all of their use cases. In our case, it looked really good on the surface, but once we got deeper into the project it started showing a lot of its warts. Expect to do a lot of babysitting with this framework if you venture outside of their narrowly documented use-cases.

[1] https://github.com/typeorm/typeorm/issues/2065

[2] https://github.com/typeorm/typeorm/issues/296

[3] https://news.ycombinator.com/item?id=21962492

This definitely takes me back to the early AngularJS days where the ONLY thing one could do was read the source. Any questions on forums would result in, "did you read the source???". I personally HATED reading the source for that project. It was like reading source code from someone who left your company in anger 5 years before you arrived.

Reply on news.ycombinator.com