I hated Nest, you have to learn their "magic", it was continuously in my way instead of helping me

This is totally off topic, but I am glad to see this here. Nest.js seems really powerful on the surface, when you start reading their docs [0] everything makes sense at first. But the deeper you go, the more it sets in that the complexity introduced by its "magic" results in very little being easily reasoned about. Just look at the process for building a GraphQL API [1], for example, it starts out simply enough then goes off the deep end. Decorators, dependency injection and providers within providers all the way down.

[0]: https://docs.nestjs.com [1]: https://docs.nestjs.com/graphql/quick-start

I went down that rabbithole when I had to set up Graphql with federation. The reason it seems complicated is because they're attempting to fit bootstrap processes of different libraries into their own IoC style by writing tiny wrappers.

You end up with large blocks of config in ugly decorators but what they're doing is trying to supply that config to the underlying libs.

I consider Nestjs docs to be among the best written docs in the node community. Virtually everything you need is in there.

agree. "inversion of control" doesn't work well for the backend. Had an issue with the frontend due to what I thought was CORS. Putting a simple 'console.log' in nestjs doesn't work... had to write an 'inversion of control' custom logger to find out it wasn't a CORS error but double slashes '//auth/me' vs /auth/me because of environmental variable. A simple console.log could have fixed this but instead it took several hours of research. Really? Why? makess me think nestjs is built for billable hours and frustration... Asking for help you get treated like a jr developer.

You’re not kidding at all. I discovered a problem with their implementation of Bull queues, and the attitude of that crowd was something else.

Despite that, I quite like NestJS, but I am a bit concerned about their — and Remult’s — reliance on decorators, a standard that appears to be in flux.

I don’t get it. Of course you can use console.log?

So I spent a lot of time in the Nest ecosystem, and I wrote some nontrivial libraries with a little (not a lot) of uptake (and neither are actively maintained at this point, so these are here mostly for completeness):

https://github.com/eropple/nestjs-auth

https://github.com/eropple/nestjs-openapi3

I was pretty excited by NestJS when I ran into it because, well--I don't mind magic, when it's done right. I quite like Spring Boot, for example. But NestJS's magic is...incorrect, in a lot of ways. The DI container is a little bit scary, with oddly hardcoded ways to register interceptors into request scope (itself necessary because NestJS's logging facilities aren't--or weren't at the time--decorating requests with X-Request-Id or similar, so you had to register your own) and no way to then define interceptor order.

It also has a lot of really overlapping nouns; guards are interceptors but less capable (and @eropple/nestjs-auth didn't use them at all) and the "pipe" concept for validation was itself inscrutable. To make it usable, I ended up just doing everything with decorators and interceptors, all living in request scope. And once I'd gotten it going, it was pretty nice. But it also meant broad incompatibilities with much of the NestJS ecosystem. It was mostly just my magic, instead.

These days I use Fastify, and, well--some things never change:

https://github.com/eropple/fastify-openapi3

I haven't been following the Node ecosystem closely. However Fastify is really interesting. Why choose Fastify over Koa? I've never understood why Koa gets so little love from the Node.js community.

Fastify has, IMO, a better Typescript story than any other framework, particularly with Fastify 4. I also prefer Fastify's ergonomics around plugins as scoping to Koa's Connect-derived approach, and I don't really love having a `ctx` object as opposed to req/res (but that one is purely a taste thing).

For me, if I wanted what Koa does, Express does 90% of it and I already know it off the top of my head. And I don't really want Express because I'll have to reinvent a lot of wheels or stack a lot of sorta-compatible middleware on top of one another (Fastify's ecosystem is smaller but generally pretty cohesive).

Nothing at all wrong with Koa, to be clear--I just don't have a use for it.

Super cool. I'm gonna give Fastify a shot next time I'm in Node.js land. Thanks!

I thought nest was somewhat straight forward, minus the use of the angular module system, but I spent years using Java/Spring. That said, nest didn't have a component scan so you have to manually specify services per module.

Having spent more time using typescript and picked up functional programming similar to Haskell (via fp-ts), I wouldn't touch nest despite its popularity.

MarbleJS looks interesting. But I'd also be inclined to use express with supporting libraries.

Interviewed recently with a startup that said they're moving from Hapi over to Nest. Lol... maybe it's for the best things didn't work out.

I totaly agree. Have used it for years and still does.