Help with circular modules dependencies

[velvet falcon]

I'm working on a NestJS REST API that will maintain a study platform.

I initially have three modules: a user module, an authentication module, and a career module.

The authentication module handles the following use cases: Register user, login user, and logout user.

The user module handles the following use cases: Create user, retrieve all users, retrieve a user by ID.

In the Career module, I handle the following use cases: Create a career, retrieve all careers, and retrieve a user's careers.

I'm experiencing a circular dependency problem in my modules. When creating a user in the user module, it receives the user data and a career ID, which it must obtain from the career module. When retrieving a user's careers in the career module, it receives a user ID, which it must obtain from the user module.

I don't know how to approach, manage, and resolve this circular dependency problem.

[solar moss]

So, there are a couple of ways to address this. I'd consider the best way for now to be to not think of the users as users, but as students (assuming that is what the main users are). So, you should have a "student (management)" module. It pulls in the user and career module and also leaves open any other future needs for tasks required to happen for student management.

The other "force it" kind of methodology and solution to circular references is to use forwardRefs. However, these should be used sparingly, as circular dependencies are usually a mistake in application logic and not a necessity. 🙂 Your modules should form a tree - not a graph (if they can). 🙂

[velvet falcon]

Thanks Scott, so you recommend creating a new module to manage "student use cases"?

[solar moss]

The answer is yes, however, I'd like to expand on that some to clarify. Use cases are the drivers of features of your application, right? They represent the business problems needing solving. And use case logic, in almost all cases, is found in "services", which are one type of provider in a Nest module. And, to build out the rest of the feature (so it works in Nest) you'd need other Nest components such as Guards, Pipes, Entities/Models, Repositories, factories, helpers, etc. also put into that module, so the feature is complete.

I hope that makes sense. 🙂

[velvet falcon]

Yes sir.

My project looks like this, where my "use cases" are my providers where I use my domain, entities, repos, services (like crypt or jwt), etc.

This is my user module

[solar moss]

Ok. Oh boy. How did you come up with that file system structure? Reminds me of an article I read a day or so ago and had to tell the author he was ruining Nest's whole purpose.

As I tried to point out, services are "use cases" in Nest. They hold the operative business logic for your application. crypt or jwt would be better as helpers or utilities. There is nothing in Nest called Domain or Presenters. Top level modules build out the domains. Presenters aren't ever used AFAIK. Nest doesn't follow the Model-View-Presenter pattern. At best, it can follow the MVC pattern.

Have a read of my article on file system structure for a Nest project. That's how you should be thinking, when working with Nest and should also help with future circular dependencies, because your modules and sub-modules (if you need them) are done as Nest prescribes, will then better show that tree of dependencies I mentioned in the file system too.

Currently, with your file structure, the mental model of how Nest is being "built" is much, much harder to reason about. It will also be almost impossible for any other dev, who knows Nest, to dig in and start working on your code base quickly. The first thing that will hit their mind is "WTF?" and well, we all know what that means in terms of code quality. Right?

😄

Btw, this is that article.

[velvet falcon]

Thank you sir.

I'm going to read you article and try to improve my implementation.

Thank you for your time, sir.

😀

[velvet falcon]

do u have the repo of you article?

[solar moss]

Not officially no. 🙂 I'm thinking about writing a follow-up article on further Nest functionality and will add a repo, if I write it.