Routing module when create resource

[Vinicius Lourenço]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe it

Imagine you need to create cat and cat-owner resources, you will have these routes:

• GET: cats/owners
• POST: cats/owners
• GET: cats/owners/:id
• PUT: cats/owners/:id
• DELETE: cats/owners/:id
• GET: cats
• POST: cats
• GET: cats/:id
• PUT: cats/:id
• DELETE: cats/:id

For these routes to work, you need to put GET: cats/owners before cats/:id otherwise you will have problems with cats/owners being forwarded to cats/:id.

But, imagine you need to check if the cat exists, you need to import CatsModule inside CatsOwnersModule, but since the modules are created with controllers, we CatsOwnersModule resolve CatsModule, probably the controllers routes inside CatsModule will be registered first and then we will get the same error.

Describe the solution you'd like

The solution I use is to create another module, called resource.routing.module.ts, for cats and cats/owners we will have CatsRoutingModule and CatsOwnersRoutingModule, with the following content:

// inside cat.routing.module.ts
import { Module } from '@nestjs/common';
import { CatsService } from './cats.service';
import { CatsController } from './cats.controller';

@Module({
  controllers: [CatsController],
  imports: [CatsModule]
})
CatsRoutingModule {} export class

// inside cat-owner.routing.module.ts
import { Module } from '@nestjs/common';
import { CatsOwnersService } from './cats-owners.service';
import { CatsOwnersController } from './cats-owners.controller';

@Module({
  controllers: [CatsOwnersController],
  imports: [CatsOwnersModule]
})
export class CatsOwnersRoutingModule {}

Inside app.module.ts, instead of importing CatsModule, you import CatsRoutingModule, with this configuration, you can import CatsModule in any module you want without having to worry about changing the order of the routes.

My suggestion is to create another module file along with the default module with the suffix .routing.module.ts when creating a new resource.

Teachability, documentation, adoption, migration strategy

No response

What is the motivation / use case for changing the behavior?

I just want to share how we currently build NestJS APIs at my company, started using this pattern and reduced the number of issues with the route order.

If this feature has been accepted, I can create a Pull Request, I've read the code and I can figure out for myself where I need to change.

[Micael Levi L. Cavalcante]

maybe is just me but I feel the introduction of that new file too opinative. I'm pretty sure you can write your own collection that extends the @nestjs/schematics one to meet your project structure.

[Jay McDoniel]

I think this specific structure would be great in a third party library that can be used via the --collection flag of the NestJS CLI (nest g -c @h4ad/nest ownerresource cat or similar). Nest uses angular schematics under the hood, and you can see an example collection here

[Vinicius Lourenço]

I agree it sounds very opinionated, but is this the kind of problem you guys have when creating APIs? If yes, what solution did you find to solve it?

But the idea of creating a collection sounds great, but the problem is still there, should this idea of creating a new module fit better with some hint in the controller documentation or should this be outside the nestjs space in something like an article?

[Kamil Mysliwiec]

Registering all controllers in dedicated modules sounds like a huge overkill. This may make sense in some very specific scenarios, but clearly shouldn't be the default.

For further questions, [lease, use our Discord channel (support).