aqueduct VS Nest

Aqueduct: This framework is no longer being supported by the original owners and will not be ported to null-safety for the foreseeable future. The library is so monolithic that it's a gargantuan task to maintain it, not to mention the growing dependency issues.

Why not just find new maintainer for Aqueduct or Angel ? Or pull out a reusable ORM package from them ?

Saw this about Aqueduct also losing support as it is tough to move to null-safe. https://github.com/stablekernel/aqueduct/issues/917#issuecomment-783700669

From - https://github.com/stablekernel/aqueduct/issues/917

https://github.com/stablekernel/aqueduct/issues/917#issuecomment-783700669

Wait, what? There's nothing about it being dead on the repository's page.

Nest framework TypeScript starter repository.

NestJS is a great framework. It's versatile, rock solid, and thoroughly documented. You can build pretty much any backend with it: RESTful, GraphQL, WebSocket, Microservice, etc. Among everything, building APIs above databases is still one of the top tasks of backend developers. With the rise of Prisma ORM, more and more people are pairing it with NestJS to get the job done - more efficiently and pleasantly, thanks to Prisma's superb DX.

NestJS implementation

A user has opened an issue titled Router module does't distinguish dynamic modules where he requests that NestJS allow importing modules with custom prefixes.

This also becomes a constraint when you want to run it as part of a web application using modern frameworks like Next.js or Nest.js. Since I often get questions about this, I explored possible ways on the weekends and eventually created a library to circumvent the constraints of the Receiver. At the moment, there are no plans to transfer this Bolt HTTP Runner into the 1st party SDKs. However, I intend to continue maintaining it as much as I can as an individual, so if you really want to try running it on Next.js or something similar, please use or fork this library.

In addition to the nest repository (https://github.com/nestjs/nest), where within the monorepository are the general and essential NestJS packages, which are as follows:

As to why anyone would create a stand-alone node app, it's because software needs and tastes are diverse. You might want a CLI application, and not a web API, for instance. You might find that a really complex backend application is easier to organize and maintain with a backend-first framework like nest (personally, I don't find this, but some people do). You might already have a frontend written in vue, and need a backend only. You might work at a company strongly committed to microservice architecture, who regards next as "doing too much." Or you might just be more comfortable working in a stand-alone node environment, and that's totally ok.

NestJS is an open-source framework for building efficient, scalable, and maintainable server-side applications using TypeScript. Angular inspires NestJS and uses TypeScript features like strong typing, decorators, and dependency injection to provide a robust architecture for building server-side applications.

Good application modularity is closely related to the injector tree hierarchy that Dependency Injection (DI) creates. DI injectors are sometimes referred to as DI containers, but since NestJS and Ditsmod have taken many concepts from Angular, this post will use the term "injectors" (since it does in Angular).