r/nestjs

TL;DR: Is there already a good framework/starter-kit for designing good maintainable frontend/backend monorepos? I'm not talking about bundlers like turborepo or NX, neither I'm talking about t3-stack or better-t-stack, I'm talking more of a very strict paradigm to design typescript frontend/backend monorepos.

I am currently slowly migrating a vibe-coded prototype to an actual production-ready product and I'm noticing how I'm slowly starting to hate the freedom TS/JS gives you, the fact that you can shape your codebase how you wish, the first refactoring I did was migrating all those scattered small sloppy ts files to domain services/sub-services, providing strong hiearchy (Java/C# like), but then noticed that I wasn't leveraging monorepo's features the fullest, so I had to modularize everything, but here I don't know what to do anymore, I don't think I was the only one facing this issue, and I can't migrate to another language 'cause we just can't afford it. The architecture I've thought of was to divide domains in packages and make packages have a strict structure both folder-wise and code-wise:

@acme/foo/
├── app/
│   ├── services/
│   │   └── foo/
│   │       ├── index.ts
│   │       └── types.ts
│   └── routers/
│       └── index.ts
├── data/
│   ├── models/
│   │   └── index.ts
│   └── index.ts
└── web/
    ├── components/
    │   ├── Foo.svelte
    │   └── Bar.svelte
    └── index.ts

But I feel I'm reinventing something someone must have already figured out, but I don't know where to search anymore...

I am about to embark on a large multi application project, and am back to weighing the pros and cons of each framework.

In my opinion, Nest is the only Node backend worth running, due to its strictly typed, opinionated nature. It keeps things organized and maintainable. Native GraphQL support is super nice as well.
That said, Symfony is so good, predictable, and honestly relaxing to use and maintain due to it's debugging capabilities.

Here are my two cents for the pros and cons. I am curious to hear what you all have to say on the topic.

NestJS

Pros:

• Database connections remain open over multiple requests, managing connection limits.
• Background task processing without Supervisor.
• Written with Typescript.
• Native GraphQL support.
• Dynamic type definition with class inheritance, allowing for strictly typed dynamic inheritance.
• Elegant, Rails like event and request interception.
• Modules based approach feels organized, and easy to navigate.

Cons:

• Module import and exports are both confusing and tedious.
• Needs dedicated processor (Not a bad thing, just has a slightly increased cost).
• Confusing and/or incomplete documentation.
• Smaller community.
• Async processing can cause database lockups if not careful.
• Errors will take down the entire thread. One funny request and the process goes down for everyone potentially.
• Debugging and logging. While there, I find them to be not quite as nice as Symfony.

Symfony

Pros:

• Can be cheap as chips to host.
• Doctrine.
• Independent service definitions that can easily be injected.
• Auto-wiring & dependency injection is an absolute pleasure to work with.
• Well written, highly complete, and easy to understand documentation.
• Native third party bundles, and well defined ways to create your own bundles.
• Native "dump" feature.
• Logging and Debugging is super clear, controllable, and provides useful information without clutter.

Cons:

• PHP (While I love, Javascript is arguably much nicer to write)
• Higher memory requirements for a single instance
• Non-devs sticking their nose up at you because you use PHP. It's a real concern if you are trying to sell the service. Business folks like hiring a person that knows Javascript for both front and back.
• Event listeners and subscribers feel detached, and are non-intuitive.

I'm building a system using a microservices architecture in a NestJS monorepo. I used to work with TypeORM, but I'm trying to switch to Prisma (still learning it) because it feels way cleaner and I won’t end up with a million entity.ts files.

My plan is to have one database per microservice, with each app having its own schema. The problem is… I can't get this setup working properly.

Also, I really don’t want to duplicate code by creating a separate PrismaService for every app.

Has anyone dealt with something similar? How are you handling Prisma in a monorepo with multiple microservices without repeating a bunch of code?

Any tips or patterns I should look into?

Hi all, I'm considering nestJS for greenfield fintech core. I've been looking into the migratedb "magic" and it does not make me conmfortable yet. It assumes things such as module naming and also I'm not into with auto-generated SQL DDL commands to be executed on multi-giga or tera byte tables with sharding, etc.
I would just like to read and learn from your own experience, both success and errors, and any alternatives that worked for you.

I'm a junior developer, and I have a question about handling circular dependencies.

Let's say I have Module A and Module B. Initially, A imports B, but then I need to add an endpoint where B also imports A. To avoid using forwardRef() and creating a circular dependency, I thought about introducing Module C, which imports both A and B and coordinates the interaction.

Here's an example:

• ProductModule imports OrderModule because it needs to check whether a product has any pending orders before allowing it to be deleted.
• Later, I want to implement POST /orders, which also needs to validate products before creating an order. That would require OrderModule to import ProductModule, creating a circular dependency.

To avoid this, I created a CheckoutModule (or CheckoutService) that imports both ProductModule and OrderModule and orchestrates the logic. This removes the circular dependency.

My confusion is about the API route. Since the orchestration now lives in the CheckoutModule, should the endpoint be:

• POST /checkout, because that's where the orchestration happens?
• Or POST /orders, with the checkout(or any) controller living inside CheckoutModule even though the route is /orders?

More generally, when you introduce an orchestration module to break circular dependencies, should your API routes follow the orchestration module, or should they still be organized around the resource being created (/orders in this case)?

I'm interested in what the common or recommended practice is.

Got some advice recently that NestJS "isn't industry standard" and "barely anyone uses it" anymore, especially compared to other backend frameworks. This didn't match what I'd researched myself, so wanted a reality check from people actually building with it.

For context — I'm evaluating a SaaS platform built on NestJS 11 + TypeScript + TypeORM + PostgreSQL, and trying to figure out if that was a reasonable tech choice or something I should be worried about going forward.

Is NestJS genuinely fading in adoption, or is this just someone's personal bias/lack of exposure to it? Curious what people actually building production backends are seeing in the field right now.

Hi everyone,

I have an Android-based device (not a typical phone, but it runs Android), and I need to run a backend application developed in Nest.js directly on the device. The application connects the device to cloud services and acts as a local agent.

I know that Termux can be used to install Node.js and run Nest.js applications, but I'm looking for other approaches that might be more suitable for production or embedded deployments.

Some questions I have:

• Are there alternatives to Termux for running a Node.js/Nest.js application on Android?
• Can Node.js be bundled directly into an Android app and run in the background?
• Has anyone used solutions like NodeMobile, embedded Node.js, or native Android services for this?
• What would be the recommended approach for deploying a long-running Nest.js service on an Android device?

The device is dedicated hardware, so I have control over what gets installed. I'm looking for a reliable solution that can automatically start on boot and run continuously in the background.

I'd appreciate hearing about any production deployments or recommended architectures.

Thanks!