nrwl / nx

Smart Monorepos · Fast CI
https://nx.dev
MIT License
23.63k stars 2.36k forks source link

Libs and NestJs #1661

Closed johannesschobel closed 3 years ago

johannesschobel commented 5 years ago

Prerequisites

Please note that this is not an issue, but rather some questions on best-practice when developing a full-stack application with nrwl/nx.

First of all, i would like to thank you for this awesome package - i really (!) really like the approach and the code-base.

As i would like to use nrwl/nx for my upcoming project, i was more than happy to see that you added nestjs as backend framework :+1: As i am currently mainly focussing on the backend side, these questions refer to explicitly to the combination nrwl/nx + nestjs

I once read an article from @vsavkin , where he said that apps should only be some kind of "empty shells" that bundle libs together. Keeping this in mind, i thought it would be a good idea to start right away and create a lot of libs.

In this context, i used the following command to bootstrap new / empty libs:

ng g @nrwl/workspace:lib NAME
# when it asked about the folder to create the lib, i entered "api" to get the proper folder structure i want!

For example, i created a libs/api/account that manages the accounts, i added an libs/api/auth that manages everything related to authentication with various providers (e.g., google, jwt, oauth, ...), and a lib/api/profile to store user-profiles (i.e., an account has one profile assigned, one profile belongs to one account: there is a @OneToOne() relationship between those models).

When i developed the account.entity.ts and profile.entity.ts models (remember, both are in separate packages), i quickly ran into Circular Dependency Warnings, because the Account requires the Profile and vice versa).

Going further, i have an CurrentUser decorator that resolves the currently logged in user (via JWT tokens, for example). This decorator, in turn, returns the logged in Account. This decorator, however, is then used in the libs/api/account module in order to protect some specific routes - so there is another circular dependency.

Finally, if you go deeper, there may be another use-case where you have a circular dependency with

User > Article > Comment > User

Is there something fundamentally wrong with this appoach? I.e., should i use libs for such features? Or should those "modules" (with controllers, dtos, entitites, models, ...) all be moved to the apps/ folder. And libs/ are more for angular applications?

I am really struggling with these questions, because actually there is no "real world example" for this setup. Maybe the nrwl/nw team or community can provide a sophisticated example?

I am aware of the https://github.com/xmlking/ngx-starter-kit starter repository - however, the author puts everything that is related to the API into the apps/api folder..

All the best and thank you so much for your help!

creadicted commented 5 years ago

I planned to write this morning - more or less - the same issue / question. I have a project that was pre-nestjs support in nx and there I structured my projects outside of the libs folder. And uses nodemon for compilation. https://github.com/creadicted/nx-modular-nest-backend I never got the circular dependencies issues and import order errors. Then I upgraded and planned to use the nx building support. With that I thought I have a lot of features I do not need to build my own or use other libraries. (config, debugger, compilation, ...). But I struggle with the Issues form @johannesschobel. As soon as I use the libs folder as intended I run in to those kinds of errors. Most of the circular dependency errors come form barrel files. But I need barrel files since deep imports are not allowed. So either we need a different configuration for something like (libs/backend/... ) or another way of handling libs in nestjs. Is anyone working with two nestjs apps in apps/... and libraries in libs/ and has a configuration that works?

demisx commented 4 years ago

I’m surprised how little info there is on structuring a backend API project in Nx. I see many questions to go unanswered. The examples are very trivial at best. This is very frustrating.

Ponjimon commented 4 years ago

I'm also facing this issue. If there is no solution to be found, I need to scrap the idea of using nx entirely, which I really want to avoid :/

Ponjimon commented 4 years ago

Still relevant

FrozenPandaz commented 4 years ago

Hi, sorry about this.

This was mislabeled as stale. We are testing ways to mark not reproducible issues as stale so that we can focus on actionable items but our initial experiment was too broad and unintentionally labeled this issue as stale.

tommyc38 commented 4 years ago

@johannesschobel I created a lib called data which lives at the bottom of my front end code and back end code. This library only holds type definitions. By doing this approach, you never run into circular dependencies when you have instance where one lib imports another lib that imports a model definition from the importing lib (e.g. circular dependency). I was running into the same issue when I was using Nx for angular....once I moved all models to its own lib, I haven't had this issue since. Let me know your thoughts.

github-actions[bot] commented 3 years ago

This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs. If we missed this issue please reply to keep it active. Thanks for being a part of the Nx community! 🙏

github-actions[bot] commented 1 year ago

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.