6
AleCx04
3y

A lot of this might be an assumption based on not enough research on both NestJS and TypeScript, so if something here is not well put or incorrect then please feel free to provide the necessary info to correct me since I care far more about getting dat booty than I do being right on the internet :D

Sooo, a year or so ago I got a hold on the Nest JS framework. A TypeScript based stack used to build microservices for node. Sounded good enough in terms of structure, it is based on the same format that Angular uses, so if you use Angular then the module system that the application has will make sense.

I attempted (last night) to play with the framework (which I normally don't since I am not that much of a big fan of frameworks and prefer a library based approach) and found a couple of things that weird me out about their selling points, mainly, how it deals with inversion of control.

My issue: This is dependency injection for people that don't really understand the concept of dependency injection. SOLID principles seem to be thrown out of the window completely due to how coupled with one another items are. Literally, you cannot change one dependency coming from one portion to the other(i.e a service into a controller) without changing all references to it, so if you were using a service specification for a particular database, and change the database, you would have to manually edit that very same service, or define another one....AND change the hardwire of the code from the providers section all the way into the controllers that use it....this was a short example, but you get the gist. This is more of a service locator type of deal than well....actual dependency injection. Oh, and the documentation uses classes rather than interfaces WHICH is where I started noticing that the whole intention of dependency injection was weird. Then I came to realize that TypeScript interfaces are meeheed out during transpilation.

Digging into the documentation I found about custom providers that could somehowemaybekinda work through. But in the end it requires far too much and items that well, they just don't feel as natural as if I was writing this in C# or Java, or PHP (actually where I use it the most)

I still think it is a framework worth learning, but I believe that this might be a bias of mine of deriving from the norm to which I was and have been used to doing the most.

Comments
  • 1
    I do agree with you.

    What I see NestJS good for is prototyping. Never have I ever whipped up a relatively complex PoC backend in such a short time as I have with Nest. I had to use all my convincing skills to keep it from going straight to prod and use something more suitable for the full specs instead.

    It’s one of those frameworks which are made so easy to use it’s almost frightening - on one hand that’s exactly what you want when testing out some ideas etc., but on the other... I have some concerns.

    Let’s put it this way: when it comes to prod applications, I’ll stick to PHP where PHP is at its best, and otherwise use some other ”real language” like C#, F# or Rust... (or even Java).
  • 0
    @100110111 I just find it do strange that people write about it and mention DI as if it were some powerful new concept when it ain't even implemented the right way and the biggest example of it. It really trips me out man 🥴
  • 0
    @AleCx04 I can imagine. I wasn’t even aware DI is one of the things people talk about when it comes to Nest.
Add Comment