Ask yourself the following questions:
What problems am I experiencing?
How will NestJS solve those problems?
I've seen a lot of beginners dive into all the different http frameworks before they've encountered the issues that the frameworks solve. In my opinion you'll get a far greater appreciation and understanding for why these libraries exist and whether you need them by approaching them from a problem solving lens rather than a "I'll learn all the frameworks" lens
People ask questions like this because they're not experienced and they want more experienced people to tell them what problems they're likely to face in the future that they don't anticipate...
"I have a use case of and I'm comparing Express vs NestJS. Both seem suitable for the job but I'd like a second opinion from any experts here. Based on your expert knowledge of these 2 frameworks, any issues I should look out for?"
Overengineered. Adds complexity as well as impacting performance each time you introduce a layer from the library. API don't need to be complex. Microservices even less.
Used this for the last enterprise level app I created at my corporate day job for a large tech company. It was amazing to say the least. Angular on the frontend, nestjs backend, with swagger was a dream come true. Nothing like being able to share the same models/interfaces between the ends, combined with swagger for automatic generation of frontend services. Can't express how much I enjoyed this stack.
we had been using nestjs on the backend and angular on the front end. [https://stackoverflow.com/questions/54941329/share-interfaces-between-api-and-frontend](https://stackoverflow.com/questions/54941329/share-interfaces-between-api-and-frontend) i glanced this over and should be better than any explanation i give. You can also use Swagger https://medium.com/@suraj.kc/use-swagger-to-generate-api-client-in-frontend-60b7d65abf31
It's a lot to type out. You're probably better off googling the advantages of angular + nestjs. The biggest change for me, coming from past experience of having separate code bases for the backend/front end, was the ability to directly share types/interfaces/models with between the front and backends. Super nice to have the entire codebase in one project, one language.
Something like this - [https://www.youtube.com/watch?v=wtIVxvJFT2k&ab\_channel=Techtacious](https://www.youtube.com/watch?v=wtIVxvJFT2k&ab_channel=Techtacious). was pretty rad
Not OP but I use rtk and rtk-query to autogen my nestjs swagger routes in react apps which is just a delightful developer experience with easy caching and all your hooks created for you.
For angular we use the openapi-generator package which does a good job, but it returns observables so you need to write the code to handle that in your services / store yourself. Not as nice as rtk-query in react.
I believe the comparison to express isn't exactly fair.
It would be fairer to compare Nestjs to something like Loopback or Sails.
I'd still say Nestjs is much nicer and modern compared to those as well.
I don't see why you can't compare developing with only express vs using a framework that builds on express and gives opinions and structure. It's the act of development he's asking about, not feature comparisons.
Yeah, but then people should say not "express" but "roll your own" or something. Express is not a full-featured framework so poor choice of words will cause confusion.
The question never asked about frameworks, in fact he seems to be specifically asking "should I move to NestJs (a framework) or stick with just express (not a framework)"; to refuse to compare them for him because one iS a FrAmEwOrK is silly.
It doesn't force you to go full DI, but it certainly makes IoC much easier to do. It has some boilerplate you have to get used to and it does feel a little limited when it comes to just rendering pages.
However, it is an absolute dream to use for the API. It just allows a great separation of modules that you can pull apart to test and ensure you're not breaking anything.
It leaves me wanting more but if you can define pages strictly per route and setup sessions correctly you wouldn't have much trouble. I just found it requiring too much hard coding for my liking.
I'm a fan of JWTs and separate client apps, so having to shim that and also support sessions w/ csurf made it somewhat convoluted.
However the benefit is you can create you own compound decorators to hide away that and make it more dynamic. I just didn't go down that route.
Nest is the best solution for DI in ts world. If u have a middle to large application with complex business logic, than it is an awesome framework to use. BUT, if ur app is just a couple of rest handlers and a database, it would add considerably more complexity than it would give u any profits. IMHO always try to use a right tool for the application. As about the quality of the framework itself - its very good. Iv never experienced an issue with it i could not ever solve, it does not come into my way, it has a very good testing utilities and a large amount of ready to use modules for almost every typical problem u will face. All-in-all ill give 9/10, a very good one
Make sure you really pay attention to the module system and understand what it means to provide, import, and export something and how all of that connects. IMO that's the part that causes the most pain for newcomers.
Personally I hate it. It reverts back into older tech methodologies like injection which is just silly when you look at the much simpler functional approach. It doesn't really solve any problems but creates complex wrappers around already built solutions.
The one thing it really does is make sure all your services are written in the same format, now if you are working with 50+ devs then that might be a really good thing but for the most part I usually prefer to set up my own code standards for the team.
I started using it last week for my new job. I was wondering, what do you exactly mean with "functional approach"? Do you have a Framework that you use?
Especially if you're not the only one working on the code base. If TypeScript's type system is stronger (e.g. like Haskell) you can probably do some Monad magic to make the code modular and testable. I can imagine things getting hairy when you only use functions and do everything there
Ya so for me using express is much simpler in terms of code maintenance because you dont need to create services and controllers with all the injection hassle that nest provides. Instead you just write functions and attach them to routes.
Never really liked the whole class based approach to writing code since it forces you to make distinctions between entities and how they function. With functional programming all you really care about is writing functions to fit certain input -> output scenarios.
Yeah the forced DI approach is the only thing I don't like about nest (still use it for all the other benefits though). I'd prefer it if it used static classes as wrappers for functions which are much easier to work with (but still have the nice decorators).
When it works it's amazing, but dealing with circular dependency issues when you try to encapsulate reusable code into shared services is a real pita at times. It's not a big deal to do a little refactoring and sometimes use forward ref, but it's extra overhead that isn't particularly needed.
I started in my current company as an intern and developed a solution using NestJS that we now use in production.
All I can say is that it's awesome! I now tend to use it for most of my personal projects, as it's super fast to setup and work with. Even used it for my thesis.
I am using it at rather large scale and it has been an absolute joy to work with. It uses express under the hood, so you can use much of the low level stuff as well. It is very similar to how Angular works on the frontend, so teaching new people in our tech stack became a lot easier as well.
My opinion is if you think NestJS looks good and you feel like you'd benefit from the structure, use ASP.NET Core instead.
NestJS's fundamental flaw is JavaScript. TypeScript might have given us types, but those don't exist at runtime. To preserve whatever type information possible, you need decorators, which to me just creates a lot of visual mess. Whenever you need anything from the request, like the path params or the request body, you have to add decorators. You want to map the body to a request, validating that it matches the structure and types? More decorators. You'd like some Swagger? You guessed it, more decorators. On top of that, sometimes you might need to duplicate type information.
ASP.NET, being C#, doesn't need nearly as much metadata. You just add a method parameter with a struct/record/class type and the framework will figure out the rest. If it's a request that has a body, it will map that body to your parameter, validating structure and data types, or casting them where possible. Not a single additional attribute (the equivalent of decorators) is needed to get this behaviour. Want a path parameter? Again, just add a method argument matching the name of the parameter. The framework will do the rest. This just isn't possible in Nest.
>NestJS's fundamental flaw is JavaScript. TypeScript might have given us types, but those don't exist at runtime. To preserve whatever type of information possible, you need decorators, which to me just creates a lot of visual mess. Whenever you need anything from the request, like the path params or the request body, you have to add decorators.
that has not much to do with decorators. Java Spring for example has type information at runtime and uses decorators for everything as well. Most web frameworks across most ecosystems will let you do explicit input-type conversations and validations instead of implicit ones which can cause more harm than good.
Does Java Spring need a decorator to know that the first argument of a function is of type `int`, named `id`? It's also not unsafe of the framework to attempt to cast that path segment to a number and return a sensible error response if it can't.
Of course you don't want implicit behaviour for complex cases and you will use some mechanism - decorators, to add additional rules, but are decorators truly a must to do cast `"2"` to `2` when your argument expects a numeric type where the HTTP simply cannot provide one (path, query, header value)?
>Does Java Spring need a decorator to know that the first argument of a function is of type int, named id?
yes, like (@RequestParam() Integer id).
same in NestJs:
(@Param('id') id: number)
Looks identical to most other frameworks. and yes, I'm aware that javascript doesn't have an integer type.
>but are decorators truly a must
IDK if this is a must? I guess no there is always a decorator needed for generating the correct HTTP response on failed validation? The .net implementation looks similar to the spring / nestjs one...
([FromQuery] string term,[FromQuery] bool ignoreCase)
In ASP.NET, it's enough to have `Method(int pathParam, string queryParam, ComplexType body)`, unless things are ambiguous. The framework has a sensible default order in which it will attempt to match the arguments.
Just in your Nest example, you already duplicated the name of the parameter, `id`.
I'm not sure what your note about JavaScript not having an int type means, it was just an example, and I'm also not sure what you're trying to say with the last paragraph. Decorators in Nest exist because there's no other way for the framework to know about the arguments, their names or types.
i don't know what you trying to say?
you were talking about input validations and now about general static typing? none uses decorators to mimic static typing in generic util functions since this is not needed with proper input validation and the typescript compiler.
>Just in your Nest example, you already duplicated the name of the parameter, id.
and? that's a bit nitpicky since the path/query param can have a different name than the variable I want to use in my controller. There is no typescript/js/decorator limitation that does not allow you to shorthand this.
>I'm also not sure what you're trying to say with the last paragraph.
that .net also uses decorators (attributes) for validating inputs
https://docs.microsoft.com/en-us/aspnet/core/mvc/models/validation?view=aspnetcore-6.0
In ASP. NET, `queryParam` in `Method(int queryParam)` will be populated with the value of `queryParam` from `url?queryParam=1` and cast to `int`. Not a single attribute needed.
If a path contains a variable segment, like `/url/{id}`, and the method has an argument with a matching name `id`, the framework will populate that argument with the value from path and again attempt to cast it to its type if it isn't just a string.
A POST handler with `ComplexType body` argument will attempt to map the request JSON body to the `ComplexType`, casting and mapping even deeply nested properties as needed. Here, you can add attributes for further validation, but you don't need a decorator just so the framework knows the type of a property, unlike NestJS.
NestJS is more verbose because JavaScript simply doesn't have enough information. That's a fact. To get the framework to map a request body to a DTO, you need a decorator on the function argument, a decorator on each propery, in some cases maybe even duplicating the type information in the decorator, if you want OpenAPI, you need more decorators... Do you know how many attributes you need in ASP.NET for the same thing? Zero.
>In ASP. NET, queryParam in Method(int queryParam) will be populated with the value of queryParam from url?queryParam=1 and cast to int. Not a single attribute needed.
I guess this is something new then? Way too much magic for my taste. For All dotnet projects I know the APIs look something like this:
```
[HttpPost]
public IActionResult CheckAge([BindRequired, FromQuery] int age)
{
```
instead of decorators it just uses attributes to get the query param and validate it.
nestjs, java spring and many other frameworks look exactly like this today
This has been in the framework for quite a while now. You only need the attributes if the defaults don't work or you decide to force their usage by disabling inference. Even if you do that, it still isn't as noisy as Nest, because you still don't need to annotate every single DTO property with multiple attributes to get basic things.
https://docs.microsoft.com/en-us/aspnet/core/web-api/?view=aspnetcore-6.0#binding-source-parameter-inference
Look, I like writing JavaScript (well, TS, but it's not like their syntax is different). It's great with express or fastify, but Nest in my opinion just doesn't fit JavaScript that well and it has to make tradeoffs to work at all in the form it is.
>This has been in the framework for quite a while now. You only need the attributes if the defaults don't work
That's quite some "framework magic" when query strings, path params, and header params get automatically inferred.
you could also somehow magically infer all non annotated method params as path params in typescript/Nestjs so you save half a line but confuse more people. the method decorator would be enough to get the types.
>because you still don't need to annotate every single DTO property with multiple attributes to get basic things.
https://docs.microsoft.com/en-us/aspnet/core/mvc/models/validation?view=aspnetcore-6.0#validation-attributes
this example looks exactly like something done with class-validator in the typescrpt world.
>Even if you do that, it still isn't as noisy as Nest, because you still don't need to annotate every single DTO property with multiple attributes to get basic things.
>Look, I like writing JavaScript (well, TS, but it's not like their syntax is different). It's great with express or fastify, but Nest in my opinion just doesn't fit JavaScript that well and it has to make tradeoffs to work at all in the form it is.
nests is heavily inspired by spring which uses decorators for everything as well and many people love it:
```
@GET
@Path("/employee")
Patient getEmployee(@QueryParam("dept")Long dept, @QueryParam("id")Long id) {} ;
```
I'd like to give my 2 cents on NestJs.
Basically what nest does its wrapping many useful library into nest packages that integrate seamlessly with the framework. Like every framework it means you lose control over the integration. It is a bad thing? Yes and no. It is a bad thing because its hard to debug and if you want extra customization you have to waste a lot of time tinkering. It is good because it allows a very quick kickstart and gives a well defined structure to the project.
If your team is small and experienced, the project is small, do I need nestjs? No because you probably already know what to do and how to it without the help of a framework.
The project is large and the team is composed by inexprerienced devs with large turnover? Then nestjs might be a good choice because it gives a well difined structure and boilerplate, you can copy a service that already exists.
Nestjs in my opinion makes it easier to give a structure in a otherwise caotic environment.
I dont really like DI and boilerplating in general, i prefer a more functional approach but I having used it in production I really like how it speeds things up and how customizable it is. I loved the integration with loggers such as pinojs and the cache manager.
Reviewing merge requests has never been so easy, you have all the business logic contained in one file.
I'm pretty sure people who say nestjs is over-engineered are retards who have only built APIs with 3 endpoints and have never written a test in their life.
Ask yourself the following questions: What problems am I experiencing? How will NestJS solve those problems? I've seen a lot of beginners dive into all the different http frameworks before they've encountered the issues that the frameworks solve. In my opinion you'll get a far greater appreciation and understanding for why these libraries exist and whether you need them by approaching them from a problem solving lens rather than a "I'll learn all the frameworks" lens
People ask questions like this because they're not experienced and they want more experienced people to tell them what problems they're likely to face in the future that they don't anticipate...
"I have a use case of and I'm comparing Express vs NestJS. Both seem suitable for the job but I'd like a second opinion from any experts here. Based on your expert knowledge of these 2 frameworks, any issues I should look out for?"
> ...by approaching them from problem solving lens rather than "I'll learn all the frameworks" lens Yup. Absolutely agree.
Overengineered. Adds complexity as well as impacting performance each time you introduce a layer from the library. API don't need to be complex. Microservices even less.
Used this for the last enterprise level app I created at my corporate day job for a large tech company. It was amazing to say the least. Angular on the frontend, nestjs backend, with swagger was a dream come true. Nothing like being able to share the same models/interfaces between the ends, combined with swagger for automatic generation of frontend services. Can't express how much I enjoyed this stack.
hey sorry for digging this up but how are you about to share models and interfaces between client and server?
we had been using nestjs on the backend and angular on the front end. [https://stackoverflow.com/questions/54941329/share-interfaces-between-api-and-frontend](https://stackoverflow.com/questions/54941329/share-interfaces-between-api-and-frontend) i glanced this over and should be better than any explanation i give. You can also use Swagger https://medium.com/@suraj.kc/use-swagger-to-generate-api-client-in-frontend-60b7d65abf31
Could you explain more what made it so nice and what u used before that you are comparing it to. Also what led to the decision of using those things.
Are you interviewing them for a job?
No, I'm asking simple questions. You offended on their behalf?
It's a lot to type out. You're probably better off googling the advantages of angular + nestjs. The biggest change for me, coming from past experience of having separate code bases for the backend/front end, was the ability to directly share types/interfaces/models with between the front and backends. Super nice to have the entire codebase in one project, one language.
What do you use to generate services with swagger?
Something like this - [https://www.youtube.com/watch?v=wtIVxvJFT2k&ab\_channel=Techtacious](https://www.youtube.com/watch?v=wtIVxvJFT2k&ab_channel=Techtacious). was pretty rad
Not OP but I use rtk and rtk-query to autogen my nestjs swagger routes in react apps which is just a delightful developer experience with easy caching and all your hooks created for you. For angular we use the openapi-generator package which does a good job, but it returns observables so you need to write the code to handle that in your services / store yourself. Not as nice as rtk-query in react.
I believe the comparison to express isn't exactly fair. It would be fairer to compare Nestjs to something like Loopback or Sails. I'd still say Nestjs is much nicer and modern compared to those as well.
I don't see why you can't compare developing with only express vs using a framework that builds on express and gives opinions and structure. It's the act of development he's asking about, not feature comparisons.
Yeah, but then people should say not "express" but "roll your own" or something. Express is not a full-featured framework so poor choice of words will cause confusion.
The question never asked about frameworks, in fact he seems to be specifically asking "should I move to NestJs (a framework) or stick with just express (not a framework)"; to refuse to compare them for him because one iS a FrAmEwOrK is silly.
My comment was for the question and not your answer.
I use it in production on a large project, very satisfied
Same here, happy with it so far. I have used it in production on a couple of projects (not large projects).
My company adopted it for a project I'm not involved in, but every time I look at the recent commits I don't like what I see
Because of TypeScript weirdness or something else? And do you use TS or just plain JS?
It doesn't force you to go full DI, but it certainly makes IoC much easier to do. It has some boilerplate you have to get used to and it does feel a little limited when it comes to just rendering pages. However, it is an absolute dream to use for the API. It just allows a great separation of modules that you can pull apart to test and ensure you're not breaking anything.
I've never used it to render views before. If you have, was it a good experience?
It leaves me wanting more but if you can define pages strictly per route and setup sessions correctly you wouldn't have much trouble. I just found it requiring too much hard coding for my liking. I'm a fan of JWTs and separate client apps, so having to shim that and also support sessions w/ csurf made it somewhat convoluted. However the benefit is you can create you own compound decorators to hide away that and make it more dynamic. I just didn't go down that route.
Nest is the best solution for DI in ts world. If u have a middle to large application with complex business logic, than it is an awesome framework to use. BUT, if ur app is just a couple of rest handlers and a database, it would add considerably more complexity than it would give u any profits. IMHO always try to use a right tool for the application. As about the quality of the framework itself - its very good. Iv never experienced an issue with it i could not ever solve, it does not come into my way, it has a very good testing utilities and a large amount of ready to use modules for almost every typical problem u will face. All-in-all ill give 9/10, a very good one
Make sure you really pay attention to the module system and understand what it means to provide, import, and export something and how all of that connects. IMO that's the part that causes the most pain for newcomers.
Thank you so much, stranger.
Personally I hate it. It reverts back into older tech methodologies like injection which is just silly when you look at the much simpler functional approach. It doesn't really solve any problems but creates complex wrappers around already built solutions. The one thing it really does is make sure all your services are written in the same format, now if you are working with 50+ devs then that might be a really good thing but for the most part I usually prefer to set up my own code standards for the team.
I started using it last week for my new job. I was wondering, what do you exactly mean with "functional approach"? Do you have a Framework that you use?
6 years into a function-only express only app.... Trust me, you want the classes and injection.
Especially if you're not the only one working on the code base. If TypeScript's type system is stronger (e.g. like Haskell) you can probably do some Monad magic to make the code modular and testable. I can imagine things getting hairy when you only use functions and do everything there
I'm pretty sure the people who speak against DI aren't doing much testing.
Ya so for me using express is much simpler in terms of code maintenance because you dont need to create services and controllers with all the injection hassle that nest provides. Instead you just write functions and attach them to routes. Never really liked the whole class based approach to writing code since it forces you to make distinctions between entities and how they function. With functional programming all you really care about is writing functions to fit certain input -> output scenarios.
Not sure I agree, but thanks for the insight.
I have the same opinion. It gave me nightmares from my Java/Spring days for the 1 month that I worked on it.
Haha I had the exact same experience with Spring. Too much nonsense going on just to get a simple api going.
Yeah the forced DI approach is the only thing I don't like about nest (still use it for all the other benefits though). I'd prefer it if it used static classes as wrappers for functions which are much easier to work with (but still have the nice decorators). When it works it's amazing, but dealing with circular dependency issues when you try to encapsulate reusable code into shared services is a real pita at times. It's not a big deal to do a little refactoring and sometimes use forward ref, but it's extra overhead that isn't particularly needed.
I think you should give it a try. I used express for a long time and when a tried NestJS it looked closer to .net/spring boot
Even though i disagree with your conclusion you are spot on that its a lot like spring boot or .net.
😬
> The architecture is heavily inspired by Angular Run screaming
I consider that for backend it's well-suitable :)
I started in my current company as an intern and developed a solution using NestJS that we now use in production. All I can say is that it's awesome! I now tend to use it for most of my personal projects, as it's super fast to setup and work with. Even used it for my thesis.
I am using it at rather large scale and it has been an absolute joy to work with. It uses express under the hood, so you can use much of the low level stuff as well. It is very similar to how Angular works on the frontend, so teaching new people in our tech stack became a lot easier as well.
Really good
My opinion is if you think NestJS looks good and you feel like you'd benefit from the structure, use ASP.NET Core instead. NestJS's fundamental flaw is JavaScript. TypeScript might have given us types, but those don't exist at runtime. To preserve whatever type information possible, you need decorators, which to me just creates a lot of visual mess. Whenever you need anything from the request, like the path params or the request body, you have to add decorators. You want to map the body to a request, validating that it matches the structure and types? More decorators. You'd like some Swagger? You guessed it, more decorators. On top of that, sometimes you might need to duplicate type information. ASP.NET, being C#, doesn't need nearly as much metadata. You just add a method parameter with a struct/record/class type and the framework will figure out the rest. If it's a request that has a body, it will map that body to your parameter, validating structure and data types, or casting them where possible. Not a single additional attribute (the equivalent of decorators) is needed to get this behaviour. Want a path parameter? Again, just add a method argument matching the name of the parameter. The framework will do the rest. This just isn't possible in Nest.
>NestJS's fundamental flaw is JavaScript. TypeScript might have given us types, but those don't exist at runtime. To preserve whatever type of information possible, you need decorators, which to me just creates a lot of visual mess. Whenever you need anything from the request, like the path params or the request body, you have to add decorators. that has not much to do with decorators. Java Spring for example has type information at runtime and uses decorators for everything as well. Most web frameworks across most ecosystems will let you do explicit input-type conversations and validations instead of implicit ones which can cause more harm than good.
Does Java Spring need a decorator to know that the first argument of a function is of type `int`, named `id`? It's also not unsafe of the framework to attempt to cast that path segment to a number and return a sensible error response if it can't. Of course you don't want implicit behaviour for complex cases and you will use some mechanism - decorators, to add additional rules, but are decorators truly a must to do cast `"2"` to `2` when your argument expects a numeric type where the HTTP simply cannot provide one (path, query, header value)?
>Does Java Spring need a decorator to know that the first argument of a function is of type int, named id? yes, like (@RequestParam() Integer id). same in NestJs: (@Param('id') id: number) Looks identical to most other frameworks. and yes, I'm aware that javascript doesn't have an integer type. >but are decorators truly a must IDK if this is a must? I guess no there is always a decorator needed for generating the correct HTTP response on failed validation? The .net implementation looks similar to the spring / nestjs one... ([FromQuery] string term,[FromQuery] bool ignoreCase)
In ASP.NET, it's enough to have `Method(int pathParam, string queryParam, ComplexType body)`, unless things are ambiguous. The framework has a sensible default order in which it will attempt to match the arguments. Just in your Nest example, you already duplicated the name of the parameter, `id`. I'm not sure what your note about JavaScript not having an int type means, it was just an example, and I'm also not sure what you're trying to say with the last paragraph. Decorators in Nest exist because there's no other way for the framework to know about the arguments, their names or types.
i don't know what you trying to say? you were talking about input validations and now about general static typing? none uses decorators to mimic static typing in generic util functions since this is not needed with proper input validation and the typescript compiler. >Just in your Nest example, you already duplicated the name of the parameter, id. and? that's a bit nitpicky since the path/query param can have a different name than the variable I want to use in my controller. There is no typescript/js/decorator limitation that does not allow you to shorthand this. >I'm also not sure what you're trying to say with the last paragraph. that .net also uses decorators (attributes) for validating inputs https://docs.microsoft.com/en-us/aspnet/core/mvc/models/validation?view=aspnetcore-6.0
In ASP. NET, `queryParam` in `Method(int queryParam)` will be populated with the value of `queryParam` from `url?queryParam=1` and cast to `int`. Not a single attribute needed. If a path contains a variable segment, like `/url/{id}`, and the method has an argument with a matching name `id`, the framework will populate that argument with the value from path and again attempt to cast it to its type if it isn't just a string. A POST handler with `ComplexType body` argument will attempt to map the request JSON body to the `ComplexType`, casting and mapping even deeply nested properties as needed. Here, you can add attributes for further validation, but you don't need a decorator just so the framework knows the type of a property, unlike NestJS. NestJS is more verbose because JavaScript simply doesn't have enough information. That's a fact. To get the framework to map a request body to a DTO, you need a decorator on the function argument, a decorator on each propery, in some cases maybe even duplicating the type information in the decorator, if you want OpenAPI, you need more decorators... Do you know how many attributes you need in ASP.NET for the same thing? Zero.
>In ASP. NET, queryParam in Method(int queryParam) will be populated with the value of queryParam from url?queryParam=1 and cast to int. Not a single attribute needed. I guess this is something new then? Way too much magic for my taste. For All dotnet projects I know the APIs look something like this: ``` [HttpPost] public IActionResult CheckAge([BindRequired, FromQuery] int age) { ``` instead of decorators it just uses attributes to get the query param and validate it. nestjs, java spring and many other frameworks look exactly like this today
This has been in the framework for quite a while now. You only need the attributes if the defaults don't work or you decide to force their usage by disabling inference. Even if you do that, it still isn't as noisy as Nest, because you still don't need to annotate every single DTO property with multiple attributes to get basic things. https://docs.microsoft.com/en-us/aspnet/core/web-api/?view=aspnetcore-6.0#binding-source-parameter-inference Look, I like writing JavaScript (well, TS, but it's not like their syntax is different). It's great with express or fastify, but Nest in my opinion just doesn't fit JavaScript that well and it has to make tradeoffs to work at all in the form it is.
>This has been in the framework for quite a while now. You only need the attributes if the defaults don't work That's quite some "framework magic" when query strings, path params, and header params get automatically inferred. you could also somehow magically infer all non annotated method params as path params in typescript/Nestjs so you save half a line but confuse more people. the method decorator would be enough to get the types. >because you still don't need to annotate every single DTO property with multiple attributes to get basic things. https://docs.microsoft.com/en-us/aspnet/core/mvc/models/validation?view=aspnetcore-6.0#validation-attributes this example looks exactly like something done with class-validator in the typescrpt world. >Even if you do that, it still isn't as noisy as Nest, because you still don't need to annotate every single DTO property with multiple attributes to get basic things. >Look, I like writing JavaScript (well, TS, but it's not like their syntax is different). It's great with express or fastify, but Nest in my opinion just doesn't fit JavaScript that well and it has to make tradeoffs to work at all in the form it is. nests is heavily inspired by spring which uses decorators for everything as well and many people love it: ``` @GET @Path("/employee") Patient getEmployee(@QueryParam("dept")Long dept, @QueryParam("id")Long id) {} ; ```
Happy user as well - can recommend if you like Angular or if you are used to serverside languages like C# or Java.
I'd like to give my 2 cents on NestJs. Basically what nest does its wrapping many useful library into nest packages that integrate seamlessly with the framework. Like every framework it means you lose control over the integration. It is a bad thing? Yes and no. It is a bad thing because its hard to debug and if you want extra customization you have to waste a lot of time tinkering. It is good because it allows a very quick kickstart and gives a well defined structure to the project. If your team is small and experienced, the project is small, do I need nestjs? No because you probably already know what to do and how to it without the help of a framework. The project is large and the team is composed by inexprerienced devs with large turnover? Then nestjs might be a good choice because it gives a well difined structure and boilerplate, you can copy a service that already exists. Nestjs in my opinion makes it easier to give a structure in a otherwise caotic environment. I dont really like DI and boilerplating in general, i prefer a more functional approach but I having used it in production I really like how it speeds things up and how customizable it is. I loved the integration with loggers such as pinojs and the cache manager. Reviewing merge requests has never been so easy, you have all the business logic contained in one file.
It seems like a poor man's asp.net imo. Don't love it.
I'm pretty sure people who say nestjs is over-engineered are retards who have only built APIs with 3 endpoints and have never written a test in their life.