4 ms·

I don't have as much experience working with Nest.js as you do, but I can see some validity in some of the things you mention. Nest.js tries to have "answers"

by adamkl 6y ago

I don't have as much experience working with Nest.js as you do, but I can see some validity in some of the things you mention. Nest.js tries to have "answers" for everything (i.e. CQRS, MQTT, Kafka, etc., etc., etc), but I do wonder how well implemented these answers are (vs. checking of a list of "completed" features.. Their documentation certainly looks impressive when it comes to breadth). I think if you stick to the core concepts of MVC with some simple DI (and if you are building something that pushes the limits of that DI system, maybe its too big), Nest.js can take a team of developers new to Node.js and enable them to quickly build well structured applications (certainly with higher quality than the average express applications I've seen in the wild). Do I think its the perfect swiss-army knife of Node.js server side development? No, but for a team of regular developers, I think it fills an important void in the Node.js landscape (the same void that was filled by Spring MVC in Java). As with everything tech related, it all depends on the use case.

eropple 6y ago
I don't disagree with anything you've said. But, that said, I feel like there's a brick wall there for NestJS users and I feel like the incentives of the NestJS core team are hard to ascertain. Uncertainty creates risk; if you're comfortable with that level of risk, that's great. I'm growing to not be comfortable with it. If there was a roadmap and a set of principles for governance I'd feel much better about it, but I also have trouble seeing that ever actually happen. > I do wonder how well implemented these answers are Not well, tbh. "Microservices", as mentioned, are useless. CQRS is fundamentally misunderstood. Their OpenAPI 3 libraries (and I will cop to some bias here, my frustration with their OAS implementation got to the point where I wrote a better one[0]) are implemented in a developer-unfriendly way that's totally separated from validation so there's a ton of diplication of work. (And let's not even talk about validation! `class-validator` is a mess. "Pipes" are pretty silly as a concept. Fastify uses `ajv` under the hood; there's not a great reason why everybody else doesn't, too.) As you say: checkmarks. A lot of checkmarks. But then you pick up the corner of the carpet and the subfloor's chewed through. [0] - https://github.com/eropple/nestjs-openapi3 https://github.com/eropple/nestjs-openapi3

by adamkl 6y ago

eropple 6y ago

I don't disagree with anything you've said. But, that said, I feel like there's a brick wall there for NestJS users and I feel like the incentives of the NestJS core team are hard to ascertain. Uncertainty creates risk; if you're comfortable with that level of risk, that's great. I'm growing to not be comfortable with it. If there was a roadmap and a set of principles for governance I'd feel much better about it, but I also have trouble seeing that ever actually happen. > I do wonder how well implemented these answers are Not well, tbh. "Microservices", as mentioned, are useless. CQRS is fundamentally misunderstood. Their OpenAPI 3 libraries (and I will cop to some bias here, my frustration with their OAS implementation got to the point where I wrote a better one[0]) are implemented in a developer-unfriendly way that's totally separated from validation so there's a ton of diplication of work. (And let's not even talk about validation! `class-validator` is a mess. "Pipes" are pretty silly as a concept. Fastify uses `ajv` under the hood; there's not a great reason why everybody else doesn't, too.) As you say: checkmarks. A lot of checkmarks. But then you pick up the corner of the carpet and the subfloor's chewed through. [0] - https://github.com/eropple/nestjs-openapi3 https://github.com/eropple/nestjs-openapi3