How should NestJS Microservices be used in a Monorepo (nx /turbo)?

[vale python]

I've been trying to use nest js microservices in Turborepo, but I'm a bit stuck as I'm not sure if I need to use NestJs monorepo folder structure as mentioned here https://docs.nestjs.com/cli/monorepo#workspace-projects (tried running nest new my-project in apps folder of my Turborepo, and then running this cd my-project nest generate app my-app ).

I assume this is a bad practice.

Should I rather run nest new my-project nest new my-project2 nest new my-project3 in my apps folder?

Or should I use just one app in apps folder and the rest of the microservices as packages / libs?

Is there a best practice for that ?

Thanks!

[upper grotto]

I used nx monorepo before, and basically I just utilized their monorepo structure and didn't use nest monorepo style. So each app inside the apps folder will be a new nest regular application (not monorepo style).

So imo, you should run nest new project1, nest new project2, etc. Each app inside the apps folder may represent a microservice.

[vale python]

@upper grotto Thanks a lot!
Is there a particular reason why you would not use a suggested monorepo style from the docs ?

[upper grotto]

When using nx or turborepo, you already have the libs or packages directory right and you can import it right away using the custom tsconfig throughout all your different microservices.

[upper grotto]

https://www.reddit.com/r/nestjs/comments/16a4pp0/nestjs_microservices_monorepo_with_reactjs_and_nx/

Here, I've also asked similar question before, and answered by @wheat verge

[wheat verge]

To expand on my answer: nest's monorepo mode is incredibly underpowered when compared to a proper monorepo workspace management tool like Nx and Turbo. I prefer the developer experience of Nx to that of Turbo, as it handles a lot of the configuration necessary to make libraries seamlessly work together with hot reloading capabilities. If you follow the ideology and make every feature module its own library, you can really see how domain lines work and what depends on what with Nx's interactive graph as well, and it'll help you from creating circular dependencies

[sharp dragon]

@wheat verge I have a project comprised of several Nest-based microservices. Currently, each microservice is in it's own repo, but it's gotten to the point where consolidating them into a monorepo makes sense. In reading through the monorepo questions here on Discord, I became familiar with NX and have been reading up on it. I'm very interested in using it as my monorepo management tool, but I haven't found any good documentation on migrating existing Nest projects into a singular workspace with NX. Any guidance on migrating existing microservices to NX? I realize that's probably more of an NX question than Nest, but would appreciate any suggestions/gotchas/considerations to look out for specific to Nest.

[wheat verge]

What I would probably do is create an nx workspace, create the apps you need, and move the src of your microservices into the src of each respective app. Unfortunately it's going to lose the git history, but it'll all be in the same repo

[zinc mirage]

Nx is a very good monorepo manager. However, for anyone reading this thread, I'd like to also note a hidden gem of a monorepo manager called Rush, which is only a part of the Rush Stack (the major part). It's very powerful and is supported by Microsoft. I'm not sure why it isn't more popular, but I guess it is because Microsoft could care less about it being "well used". They use it and for very, very, very large code bases. Like 500GB large code bases!!! 🤯 I also know Tiktok uses Rush for their monorepos.

I got interested in Rush, because the docs spell out how to use it from the two dev roles a monorepo manager would help serve. The monorepo admin or repo maintainer and the developing developer. These tutorials got me running quite fast with Rush i.e. understanding it and why I need it. There is also the section about adding a repo to Rush, which might help you @sharp dragon.

That being said, any monorepo manager is a big can of worms to learn and get right. I've been working with Rush Stack for a couple of years now and I'm still a noob. LOL! 😄