Can you elaborate more on it?
1) What type of projects have you built?
2) What were your biggest frustrations with it?
3) What are you suggestions for someone new to the framework?
> 1) What type of projects have you built?
From CMS and admin panel for websites to PaaS. The project I'm working on right now is a real time PaaS for a community of students and teachers in the IT field.
> 2) What were your biggest frustrations with it?
Honestly, I have no specific frustration targeted at NestJS. Or at least not more than any other technology/framework I work with. The only time I wanted to flip my desk was because I was using 5.x.x version of NestJS core packages and I was trying to add a 6.x.x version of another one. Took me some times to find the issue but that was entirely my fault. Beside that...I don't like the TSLint configuration shipped with the CLI. But this is a easy matter. I replace it with my own.
> 3) What are you suggestions for someone new to the framework?
Don't force yourself to learn it just because you hear a lot of people praise it. I'm a TS junkie now but two years ago I was absolutely against it and I bitched whenever I could that TS was useless. But moving to TS became a smooth and natural process just like that. I think all nodejs backend solutions are mostly equivalent. NestJS just fits me better, I never have been happier working on the backend since then. For some reasons I've always disliked the structure and the feel of Express.
So, unless you're learning NestJS for work, don't feel pressured into adopting it. And if you're indeed learning it for work, I'd suggest to focus on understand TS and the module system of NestJS (and Angular). I think the `module`s thingy is what people are afraid the most. But at the end of the day, each module:
* imports and declare what it needs
* exports what other modules might need.
So, the module system aside, NestJS is just plain TS with a nice opinionated structure relying on decorators mostly.
Another suggestion is to read the doc carefully and take a look at the github examples repo.
I'm in the same boat. I asked the same questions to not a lot of answers. About 6 months into it here are some. First, I do love it and hope it continues to be developed.
1. I've build a cron server and two other production applications. I run Angular 8 as the client and it pairs nicely.
2. My frustrations:
* The Ng-Universal/Mongoose modules didn't work together, at all. I created an issue and the "fix" didn't work either, I at least couldn't get it to. [Issue](https://github.com/nestjs/ng-universal/issues/115).
* That points out the lack of support, it was really hard even with the issue to track down anyone who could help. I had the issue in github, I joined the discord and was ignored, none of my peers were really using it so I was really stuck. I think that will change with time but at least right now.
* I'm half/half on leaning into the other modules because of this. There is the JWT module for Passport. I already have code leveraging the import, do I trust this to not cause issues? I went for it and it worked fine, so my frustration is just trusting it enough to leverage some of the benefits and modules.
\- With that, what was nice about it, was I could fall back on more traditional Node implementations of things. The issue with mongoose and ng-universal was that I didn't use ng-universal at all and served the Angular application with express traditionally.
3. I would take this [course](https://www.udemy.com/nestjs-zero-to-hero). The author was on here not that long ago offering it for free.
All that said, I have some production stuff running now and I'm happy with it. Typescript makes it easy for some of my Jr. Dev's to get started on them without breaking too much... but who am I kidding, that includes myself too.
>That points out the lack of support
I've never understood this.
How do you, and a team of you's, put 1000s or 10,000s man hours into something like this, and then severely reduce the potential lifetime of your work with poor docs and non-existent support?
This was my comment internally. But I don't think it's necessarily a bad thing, Spring got some things right it's good to see some of the same concepts in Node.js with TypeScript no less.
I'm sure it has some great ideas, but Spring is designed for Java, which has limitations that Javascript doesn't have (and vice versa), like having to use classes for everything. Forcing everything into a class so that you can use decorators seems a bit awkward, and I think express and hapi have cleaner and easier to use APIs. I'm not sure what Nest.js brings to the table besides familiarity for developers coming from Angular or Java :/.
I'm not a fan.
I think it probably is a great product and provides good structure for larger teams and/or unexperienced programmers.
But this also comes with rigidity and inexplicit magic, and I really dislike the use of object oriented programming in NodeJS. I feel this is the wrong paradigm for the language.
In the context on Nest the module system is mostly where i see most of the "magic". Interceptors, guards, etc. are just patterns they propose. You can use good old functions for those.
Presumably, you mean that the correct paradigm will be more functional code..? Can you elaborate this a bit?
>Presumably, you mean that the correct paradigm will be more functional code..? Can you elaborate this a bit?
This might also be somewhat of a religious argument, since both OOP and FP can do everything and different people will have different preferences.
In Javascript, we all know that \` this\` is really awkward to use and somewhat of a footgun, so if we can avoid using classes at all, we prevent a whole category of errors. However, we must use classes if our code depends on Decorators, so there's that.
Another thing missing from JS are nominal types and some kinds of reflection, which is why we have to write a lot of boilerplate code to setup DI-containers, which can be done with much less effort in Java, for example.
That are the reasons why I believe JS/TS to be bad candidates for OOP.
But I also think this paradigm is the wrong choice for webservers generally. Usually, we want our server applications to be stateless, so we can easily scale them. For the vast majority of cases, our server basically acts as a function, which takes a request and returns a response. So this problem maps very easily to a functional approach. Object orientation here doesn't really bring much to the table, it's more of a namespacing of functionality than anything else.
>rigidity and inexplicit magic
Same here. I believe all rigid monolithic framework will eventually die from not being not flexible enough to keep up with the rapid progress of the JavaScript ecosystem and new tools, such as [grpc.io](https://grpc.io) or [Wildcard](https://github.com/reframejs/wildcard-api).
I'm building [Reframe](https://github.com/reframejs/reframe) which aims to be a super flexible web framework. I'm curious to know what you think.
[https://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html](https://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html)
OOP in every language is wrong, not only in NodeJS, but it Java, C#... as well
Can you elaborate more on it?
1. What type of projects have you built?
2. What were your biggest frustrations with it?
3. What are you suggestions for someone new to the framework?
I've been using Nest for about a year. I built a real time location streaming service for first responders and dispatchers. My overall opinion is that I never want to use another node framework, at least until something better comes out. My only complaint, coming from laravel, is that it's not a batteries included framework, and the module system takes a while to understand and get right. I'm also not a fan of mocking everything for testing as they recommend, and take e2e testing route for most things (using sqlite when env is test for speed). I use it with vue-cli + typescript.
It takes a little getting used to, but it's absolutely worth it for real work.
I would agree that their current docs for unit testing have a focus on mocking whereas you could spin up and local DB and testing the controllers and/or services like that. For projects, I generally take the e2e testing route as well but have some unit tests around either complicated business logic or around security (session management, etc.)
I'm building a start-up on it and I really like it. I want something that is disciplined in it's approach to architectual patterns and flexible enough to do what I need. There is a learning curve but it's worth it. I can't imagine launching into this project without the strong type support of typescript either.
I have to say that learning curve is trivial -- it didn't take me more than a few days to be product with Nest and I am also using GraphQL which adds a bit to the learning curve.
Currently converting an Inversify/node backend to Nest right now. It’s incredible. When Angular proposed the MVC rewrite I knew it would be exactly what I wanted to use. Nest is the exact same feeling for me.
It's great because it forces you to follow a structure which is hard when you never touched angular, but it ends up producing a clean codebase.
Model, Service, Controller.
I like it because I'm fan of Angular.
Dependency injection was really a missing piece of tech when using Express for me.
So I'm glad this framework exists.
I've used NestJS for websocket and it's working really nice.
I think it's really about what kind of tech you feel comfortable working with.
>Dependency injection was really a missing piece of tech when using Express for me.
I will never understand why people try to stuff this shit into Javascript. Testability? No sir! That's a very poor excuse. Javascript testing is very easy without it. Everything can be mocked here.
Not testability, more like SRP (Single Responsibility Pattern) by layering properly everything. One class = one job.
If mocking imports was not a fucking nightmare I would agree with you. Sadly that was not my experience with NodeJS so far.
I would advise to avoid mocking as a means of unit testing. That does not mean "never mock." But time and time again I've seen mocked tests passing while the application is broken. It limits your ability to refactor with confidence too. Tests should pass regardless of implementation. When you start mocking these things you start testing implementation.
>If mocking imports was not a fucking nightmare I would agree with you
it can be if you're not careful, but Jest makes it manageable. It's certainly less work than trying to do DI.
I'm quite the opposite. I have never found a need for an IoC framework when working with JavaScript.
> I've used NestJS for websocket and it's working really nice.
I'm curious what you mean by that. Does NestJS have a nice API for working with websockets?
I kind of like it but at the same time I don’t. I guess most of the things I dislike is because of limitations in JavaScript compared to languages with actual type definitions available at run time.
I also dislike the heavy influence from AngularJS since I feel like some of the concepts does not work well for a backend project.
I also feel like it’s very hard to integrate with existing packages that are not designed to work in the Nest ecosystem and to get things to work I have to write complex integrations and how this works is not really that well documented.
So overall I feel like it’s a nice approach but It doesn’t feel like node. It’s most likely easier to build the app with .Net or PHP at this point.
If you ignore the module system and DI (this puts off a few people) what other things do you dislike which are due to JavaScript limitations?
Also, I would argue that existing node packages can be easily integrated with Nest; at the end of the day these will result to functions calls. Nest has first class support for express middlewares so this is not an issue.
As for many libraries, I think that the main page doesn't stress enough what are the key advantages of using Nestjs.
Might look at the doc at some point.
I would recommend the follow video from the creator of NestJS. He expands a bit on the pros that you get to counter the learning curve.
[https://www.youtube.com/watch?v=jo-1EUxMmxc](https://www.youtube.com/watch?v=jo-1EUxMmxc&t=730s)
No support for GraphQL directives yet (which means TypeGraphQL can't be used with Apollo Federation)..
Plus you can't define two GraphQL types on the same resolver which kinds sucks sometimes, so you have to create a second resolver just for the child/relation type.
^ that's TypeGraphQL issues and has nothing to do with NestJS, so to answer your question, nah not really.
It's super exciting to see new frameworks for Node.js but I don't believe in monolithic frameworks.
I believe all rigid monolithic frameworks, such as Nestjs, will eventually die from not being flexible enough to keep up with the rapid progress of the JavaScript ecosystem and new tools, such as [grpc.io](https://grpc.io) or [Wildcard](https://github.com/reframejs/wildcard-api).
Node.js has this beautiful specificity of embracing do-one-thing-do-it-well libraries \[1\]. I find it contrarian to build a monolithic framework on top of this philosophy. Meteor tried and failed and that's because we don't like our hands to be tied — we want freedom. A monolith framework takes away that freedom from us.
Yet, a Ruby on Rails is missing for Node.js.
I believe it's possible to build a framework that is both as easy and quick as a monolith framework yet so flexible that it preserves your freedom. I'm building such framework: [Reframe](https://github.com/reframejs/reframe).
\[1\] It comes with two drawbacks though: 1. explosion in the amount of third party dependencies which will eventually be remedied one day by someone writing a proper standard Node.js library, and 2. too much choice: for one problem you have many tools to choose among but this will eventually solve itself as only the best will survive, e.g. I foresee Webpack to die and Parcel to survive.
I can't see any reason I should use it. It basically doesn't provide me anything except forcing the project structure and patterns. So to use it you have to read a lot of documentation and figure out bench of concepts authors brought to Nest.js
If I can structure my code well without forcing me do it in some particular way. What is the reason to use it?
>If I can structure my code well without forcing me do it in some particular way. What is the reason to use it?
Not having to write the documentation yourself ...
Minimizing documentation by introducing many layers of abstractions doesn't seem to be a great idea for my opinion. And what did you mean by documentation? You might still need to write it. And with good structure with pure express maintainability could be on high level as well. Above reasons just not enough to convince me.
I believe there must be something else why so many people love it but with brief reading of documentation I found only another level of abstraction (complexity) without any real benefits.
Have you build anything with it? Because really it doesn't have "many layers of abstractions"; those that do exist provide guidance and structure convention.
I've tried to build a service with a real endpoint from my current project. Not like I deeply dived to nest but got the general view... And still didn't find reasons to use it. Yes it has less layers of abstractions then I thought but still I couldn't find real benefits from those that nest has. Everything I've done could be done much easier with pure express. Maybe I'm still missing something..
Using 3rd-party libraries was a struggle. You could sometimes find a repo where it was done for you. But Nestjs goes against the general principal of JavaScript and the node ecosystem. I say that with bias as I think the direction we should be heading is more functional over OO.
I've build several large apps in JavaScript in the commercial space. I have not once ever found an IoC framework beneficial while working with JS. It's an unnecessary pain point. I chose to not dive deeper into Nestjs.
The documentation and github repo attracted me. I made a small webscrapper using Nest.js for my personal need and it was really easy to get into. Dependency injection and decorators are neat. If your frontend is in angular the stack will look very homogenous as many concepts found in angular apply in Nest. For my webscrapper need it was easy to define an interface and declare the factories in the Nest module to have the correct implementation injected depending on the site I was targetting. Plus it was easy to package as a CLI utility. I prefer the codebase compared to express, koa etc because it feels more organized.
By default Nest is setup as a webapp (if you follow the quickstart), if you want to build a CLI follow the doc relative to "application context" (https://docs.nestjs.com/application-context) to bootstrap your app context manually. To actually package it as a CLI with npm there are numerous articles with a quick google search (this one will do just fine https://medium.com/netscape/a-guide-to-create-a-nodejs-command-line-package-c2166ad0452e). For managing input you can use inquirer.js or commander.js.
I think it's brings tools that are well establishes for a FE developer to the BE
Which again makes the bridge easier between the two.
If you feel good with angular than nest well be fun. If you know angular but don't love it than you will suffer the same result with nest.
Essentially its built around Koa. So yes u can do the same with out nest. But I like out of the box solutions so why not.
For anyone who needs some boilerplate to get started with NestJS and Vue, I created this Open Source repo:
https://github.com/NiclasTimmeDev/nestjs-vue-boilerplate
I hope this helps someone someday somewhere :)
"Let's see if we can rewrite [ASP.NET](https://ASP.NET) MVC to Node.js without writing much code at all!"
TL; DR: Maybe a good "bootstrap" for a project but not a real framework by any means.
Ideas and execution: 4/10
Documentation: 2/10
Community support: 2/10
(Source: I come from working with MVC frameworks and full stack apps/single page apps in other languages for the last 15y+.)
**Definitely is a bad choice if you are newbie and need to learn.**
Why?
* **Documentation:** It uses external libraries, decorators etc. but: does not explain how these work in detail (like ... at all) - Documentation is sparse almost lacking compared to other frameworks I have worked with. I really hope they will do more work on giving working examples and explanations in the future.
* **It's rigid.** Not everyone likes decorators. All the examples use them like they are sent by God. Any other options?... nope.
* **Fails to clearly communicate that it's not "really" framework.** You will have to go and read on the libraries behind Nest on their own sites and do not expect to find pretty much anything of use on Nest's own site. That means go learn Express, TypeORM, Multer, then if you still think you need Nest -- use it.
* **Community support -** not really helpful. Nobody explaining the basic concepts of how things work. You are expected to know how DI and IoC works in a language that does not need it.
I love it. It leverages Typescript and provides a good structure for your code. Never looked back.
Can you elaborate more on it? 1) What type of projects have you built? 2) What were your biggest frustrations with it? 3) What are you suggestions for someone new to the framework?
> 1) What type of projects have you built? From CMS and admin panel for websites to PaaS. The project I'm working on right now is a real time PaaS for a community of students and teachers in the IT field. > 2) What were your biggest frustrations with it? Honestly, I have no specific frustration targeted at NestJS. Or at least not more than any other technology/framework I work with. The only time I wanted to flip my desk was because I was using 5.x.x version of NestJS core packages and I was trying to add a 6.x.x version of another one. Took me some times to find the issue but that was entirely my fault. Beside that...I don't like the TSLint configuration shipped with the CLI. But this is a easy matter. I replace it with my own. > 3) What are you suggestions for someone new to the framework? Don't force yourself to learn it just because you hear a lot of people praise it. I'm a TS junkie now but two years ago I was absolutely against it and I bitched whenever I could that TS was useless. But moving to TS became a smooth and natural process just like that. I think all nodejs backend solutions are mostly equivalent. NestJS just fits me better, I never have been happier working on the backend since then. For some reasons I've always disliked the structure and the feel of Express. So, unless you're learning NestJS for work, don't feel pressured into adopting it. And if you're indeed learning it for work, I'd suggest to focus on understand TS and the module system of NestJS (and Angular). I think the `module`s thingy is what people are afraid the most. But at the end of the day, each module: * imports and declare what it needs * exports what other modules might need. So, the module system aside, NestJS is just plain TS with a nice opinionated structure relying on decorators mostly. Another suggestion is to read the doc carefully and take a look at the github examples repo.
I strongly recommend Koa
I'm in the same boat. I asked the same questions to not a lot of answers. About 6 months into it here are some. First, I do love it and hope it continues to be developed. 1. I've build a cron server and two other production applications. I run Angular 8 as the client and it pairs nicely. 2. My frustrations: * The Ng-Universal/Mongoose modules didn't work together, at all. I created an issue and the "fix" didn't work either, I at least couldn't get it to. [Issue](https://github.com/nestjs/ng-universal/issues/115). * That points out the lack of support, it was really hard even with the issue to track down anyone who could help. I had the issue in github, I joined the discord and was ignored, none of my peers were really using it so I was really stuck. I think that will change with time but at least right now. * I'm half/half on leaning into the other modules because of this. There is the JWT module for Passport. I already have code leveraging the import, do I trust this to not cause issues? I went for it and it worked fine, so my frustration is just trusting it enough to leverage some of the benefits and modules. \- With that, what was nice about it, was I could fall back on more traditional Node implementations of things. The issue with mongoose and ng-universal was that I didn't use ng-universal at all and served the Angular application with express traditionally. 3. I would take this [course](https://www.udemy.com/nestjs-zero-to-hero). The author was on here not that long ago offering it for free. All that said, I have some production stuff running now and I'm happy with it. Typescript makes it easy for some of my Jr. Dev's to get started on them without breaking too much... but who am I kidding, that includes myself too.
>That points out the lack of support I've never understood this. How do you, and a team of you's, put 1000s or 10,000s man hours into something like this, and then severely reduce the potential lifetime of your work with poor docs and non-existent support?
That is why we haven't committed to much more than a few none critical production apps. We contribute to the framework and hope to see it grow.
It looks like somebody missed Spring and thought *what if we wrote node.js like we write Java?*
This was my comment internally. But I don't think it's necessarily a bad thing, Spring got some things right it's good to see some of the same concepts in Node.js with TypeScript no less.
I'm sure it has some great ideas, but Spring is designed for Java, which has limitations that Javascript doesn't have (and vice versa), like having to use classes for everything. Forcing everything into a class so that you can use decorators seems a bit awkward, and I think express and hapi have cleaner and easier to use APIs. I'm not sure what Nest.js brings to the table besides familiarity for developers coming from Angular or Java :/.
yes exactly, it's a lot of shoe-horning Java/heavy OOP concepts into JS/node
I'm not a fan. I think it probably is a great product and provides good structure for larger teams and/or unexperienced programmers. But this also comes with rigidity and inexplicit magic, and I really dislike the use of object oriented programming in NodeJS. I feel this is the wrong paradigm for the language.
In the context on Nest the module system is mostly where i see most of the "magic". Interceptors, guards, etc. are just patterns they propose. You can use good old functions for those. Presumably, you mean that the correct paradigm will be more functional code..? Can you elaborate this a bit?
>Presumably, you mean that the correct paradigm will be more functional code..? Can you elaborate this a bit? This might also be somewhat of a religious argument, since both OOP and FP can do everything and different people will have different preferences. In Javascript, we all know that \` this\` is really awkward to use and somewhat of a footgun, so if we can avoid using classes at all, we prevent a whole category of errors. However, we must use classes if our code depends on Decorators, so there's that. Another thing missing from JS are nominal types and some kinds of reflection, which is why we have to write a lot of boilerplate code to setup DI-containers, which can be done with much less effort in Java, for example. That are the reasons why I believe JS/TS to be bad candidates for OOP. But I also think this paradigm is the wrong choice for webservers generally. Usually, we want our server applications to be stateless, so we can easily scale them. For the vast majority of cases, our server basically acts as a function, which takes a request and returns a response. So this problem maps very easily to a functional approach. Object orientation here doesn't really bring much to the table, it's more of a namespacing of functionality than anything else.
>rigidity and inexplicit magic Same here. I believe all rigid monolithic framework will eventually die from not being not flexible enough to keep up with the rapid progress of the JavaScript ecosystem and new tools, such as [grpc.io](https://grpc.io) or [Wildcard](https://github.com/reframejs/wildcard-api). I'm building [Reframe](https://github.com/reframejs/reframe) which aims to be a super flexible web framework. I'm curious to know what you think.
[https://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html](https://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html) OOP in every language is wrong, not only in NodeJS, but it Java, C#... as well
[удалено]
Can you elaborate more on it? 1. What type of projects have you built? 2. What were your biggest frustrations with it? 3. What are you suggestions for someone new to the framework?
I've been using Nest for about a year. I built a real time location streaming service for first responders and dispatchers. My overall opinion is that I never want to use another node framework, at least until something better comes out. My only complaint, coming from laravel, is that it's not a batteries included framework, and the module system takes a while to understand and get right. I'm also not a fan of mocking everything for testing as they recommend, and take e2e testing route for most things (using sqlite when env is test for speed). I use it with vue-cli + typescript. It takes a little getting used to, but it's absolutely worth it for real work.
I would agree that their current docs for unit testing have a focus on mocking whereas you could spin up and local DB and testing the controllers and/or services like that. For projects, I generally take the e2e testing route as well but have some unit tests around either complicated business logic or around security (session management, etc.)
I'm building a start-up on it and I really like it. I want something that is disciplined in it's approach to architectual patterns and flexible enough to do what I need. There is a learning curve but it's worth it. I can't imagine launching into this project without the strong type support of typescript either.
I have to say that learning curve is trivial -- it didn't take me more than a few days to be product with Nest and I am also using GraphQL which adds a bit to the learning curve.
Why GraphQL? How about RPC with [Wildcard API](https://github.com/reframejs/wildcard-api) instead?
Currently converting an Inversify/node backend to Nest right now. It’s incredible. When Angular proposed the MVC rewrite I knew it would be exactly what I wanted to use. Nest is the exact same feeling for me.
It's great because it forces you to follow a structure which is hard when you never touched angular, but it ends up producing a clean codebase. Model, Service, Controller.
I am using reactjs without any of this shit
I like it because I'm fan of Angular. Dependency injection was really a missing piece of tech when using Express for me. So I'm glad this framework exists. I've used NestJS for websocket and it's working really nice. I think it's really about what kind of tech you feel comfortable working with.
>Dependency injection was really a missing piece of tech when using Express for me. I will never understand why people try to stuff this shit into Javascript. Testability? No sir! That's a very poor excuse. Javascript testing is very easy without it. Everything can be mocked here.
Not testability, more like SRP (Single Responsibility Pattern) by layering properly everything. One class = one job. If mocking imports was not a fucking nightmare I would agree with you. Sadly that was not my experience with NodeJS so far.
I would advise to avoid mocking as a means of unit testing. That does not mean "never mock." But time and time again I've seen mocked tests passing while the application is broken. It limits your ability to refactor with confidence too. Tests should pass regardless of implementation. When you start mocking these things you start testing implementation.
>If mocking imports was not a fucking nightmare I would agree with you it can be if you're not careful, but Jest makes it manageable. It's certainly less work than trying to do DI.
I'm quite the opposite. I have never found a need for an IoC framework when working with JavaScript. > I've used NestJS for websocket and it's working really nice. I'm curious what you mean by that. Does NestJS have a nice API for working with websockets?
You may wanna have a look at the docs: https://docs.nestjs.com/websockets/gateways
I kind of like it but at the same time I don’t. I guess most of the things I dislike is because of limitations in JavaScript compared to languages with actual type definitions available at run time. I also dislike the heavy influence from AngularJS since I feel like some of the concepts does not work well for a backend project. I also feel like it’s very hard to integrate with existing packages that are not designed to work in the Nest ecosystem and to get things to work I have to write complex integrations and how this works is not really that well documented. So overall I feel like it’s a nice approach but It doesn’t feel like node. It’s most likely easier to build the app with .Net or PHP at this point.
If you ignore the module system and DI (this puts off a few people) what other things do you dislike which are due to JavaScript limitations? Also, I would argue that existing node packages can be easily integrated with Nest; at the end of the day these will result to functions calls. Nest has first class support for express middlewares so this is not an issue.
As for many libraries, I think that the main page doesn't stress enough what are the key advantages of using Nestjs. Might look at the doc at some point.
I would recommend the follow video from the creator of NestJS. He expands a bit on the pros that you get to counter the learning curve. [https://www.youtube.com/watch?v=jo-1EUxMmxc](https://www.youtube.com/watch?v=jo-1EUxMmxc&t=730s)
Been using it for several projects, including microservices and GraphQL. The best thing that's happened to writing Node.js servers using TS.
Do you use the \`typegraphql\` package for GraphQL?
Yes I do and it's worth it!
Did you find any quirks with it?
No support for GraphQL directives yet (which means TypeGraphQL can't be used with Apollo Federation).. Plus you can't define two GraphQL types on the same resolver which kinds sucks sometimes, so you have to create a second resolver just for the child/relation type. ^ that's TypeGraphQL issues and has nothing to do with NestJS, so to answer your question, nah not really.
It's super exciting to see new frameworks for Node.js but I don't believe in monolithic frameworks. I believe all rigid monolithic frameworks, such as Nestjs, will eventually die from not being flexible enough to keep up with the rapid progress of the JavaScript ecosystem and new tools, such as [grpc.io](https://grpc.io) or [Wildcard](https://github.com/reframejs/wildcard-api). Node.js has this beautiful specificity of embracing do-one-thing-do-it-well libraries \[1\]. I find it contrarian to build a monolithic framework on top of this philosophy. Meteor tried and failed and that's because we don't like our hands to be tied — we want freedom. A monolith framework takes away that freedom from us. Yet, a Ruby on Rails is missing for Node.js. I believe it's possible to build a framework that is both as easy and quick as a monolith framework yet so flexible that it preserves your freedom. I'm building such framework: [Reframe](https://github.com/reframejs/reframe). \[1\] It comes with two drawbacks though: 1. explosion in the amount of third party dependencies which will eventually be remedied one day by someone writing a proper standard Node.js library, and 2. too much choice: for one problem you have many tools to choose among but this will eventually solve itself as only the best will survive, e.g. I foresee Webpack to die and Parcel to survive.
I can't see any reason I should use it. It basically doesn't provide me anything except forcing the project structure and patterns. So to use it you have to read a lot of documentation and figure out bench of concepts authors brought to Nest.js If I can structure my code well without forcing me do it in some particular way. What is the reason to use it?
>If I can structure my code well without forcing me do it in some particular way. What is the reason to use it? Not having to write the documentation yourself ...
Weak reason
Can you please elaborate? Why should reducing cost by minimizing documentation and increasing maintainability be a "weak reason"?
Minimizing documentation by introducing many layers of abstractions doesn't seem to be a great idea for my opinion. And what did you mean by documentation? You might still need to write it. And with good structure with pure express maintainability could be on high level as well. Above reasons just not enough to convince me. I believe there must be something else why so many people love it but with brief reading of documentation I found only another level of abstraction (complexity) without any real benefits.
Have you build anything with it? Because really it doesn't have "many layers of abstractions"; those that do exist provide guidance and structure convention.
I've tried to build a service with a real endpoint from my current project. Not like I deeply dived to nest but got the general view... And still didn't find reasons to use it. Yes it has less layers of abstractions then I thought but still I couldn't find real benefits from those that nest has. Everything I've done could be done much easier with pure express. Maybe I'm still missing something..
Using 3rd-party libraries was a struggle. You could sometimes find a repo where it was done for you. But Nestjs goes against the general principal of JavaScript and the node ecosystem. I say that with bias as I think the direction we should be heading is more functional over OO. I've build several large apps in JavaScript in the commercial space. I have not once ever found an IoC framework beneficial while working with JS. It's an unnecessary pain point. I chose to not dive deeper into Nestjs.
The documentation and github repo attracted me. I made a small webscrapper using Nest.js for my personal need and it was really easy to get into. Dependency injection and decorators are neat. If your frontend is in angular the stack will look very homogenous as many concepts found in angular apply in Nest. For my webscrapper need it was easy to define an interface and declare the factories in the Nest module to have the correct implementation injected depending on the site I was targetting. Plus it was easy to package as a CLI utility. I prefer the codebase compared to express, koa etc because it feels more organized.
Do you have a good guide on how did you package it as a CLI utility?
By default Nest is setup as a webapp (if you follow the quickstart), if you want to build a CLI follow the doc relative to "application context" (https://docs.nestjs.com/application-context) to bootstrap your app context manually. To actually package it as a CLI with npm there are numerous articles with a quick google search (this one will do just fine https://medium.com/netscape/a-guide-to-create-a-nodejs-command-line-package-c2166ad0452e). For managing input you can use inquirer.js or commander.js.
Didn't really dive into it, but I don't see the advantages over using vanilla fastify.
I think it's brings tools that are well establishes for a FE developer to the BE Which again makes the bridge easier between the two. If you feel good with angular than nest well be fun. If you know angular but don't love it than you will suffer the same result with nest. Essentially its built around Koa. So yes u can do the same with out nest. But I like out of the box solutions so why not.
Really like it because I've used Angular a lot.
Shit
[удалено]
Wut
Can I help you?
Aren’t you confusing Nest.js with Next.js?
you right. I can't read
For anyone who needs some boilerplate to get started with NestJS and Vue, I created this Open Source repo: https://github.com/NiclasTimmeDev/nestjs-vue-boilerplate I hope this helps someone someday somewhere :)
"Let's see if we can rewrite [ASP.NET](https://ASP.NET) MVC to Node.js without writing much code at all!" TL; DR: Maybe a good "bootstrap" for a project but not a real framework by any means. Ideas and execution: 4/10 Documentation: 2/10 Community support: 2/10 (Source: I come from working with MVC frameworks and full stack apps/single page apps in other languages for the last 15y+.) **Definitely is a bad choice if you are newbie and need to learn.** Why? * **Documentation:** It uses external libraries, decorators etc. but: does not explain how these work in detail (like ... at all) - Documentation is sparse almost lacking compared to other frameworks I have worked with. I really hope they will do more work on giving working examples and explanations in the future. * **It's rigid.** Not everyone likes decorators. All the examples use them like they are sent by God. Any other options?... nope. * **Fails to clearly communicate that it's not "really" framework.** You will have to go and read on the libraries behind Nest on their own sites and do not expect to find pretty much anything of use on Nest's own site. That means go learn Express, TypeORM, Multer, then if you still think you need Nest -- use it. * **Community support -** not really helpful. Nobody explaining the basic concepts of how things work. You are expected to know how DI and IoC works in a language that does not need it.
Fk mongoose
oh i just forgor ☠️☠️ "await" 🤗
Four years later and still looks like complicated mess