Nestjs Circular dependency forwardRef() drawbacks

Question

Official Circular dependency says:

A circular dependency occurs when two classes depend on each other. For example, class A needs class B, and class B also needs class A. Circular dependencies can arise in Nest between modules and between providers.

While circular dependencies should be avoided where possible, you can't always do so.

What are the reasons for not using forwardRef()?

Shrovetide

Answer 1

Circular dependencies usually mean you have tightly bound logic and possibly unstable architecture that will not allow you to scale. If you really don't want to care about that, you can just sprinkle in forwardRef wherever you want, constructors and services, but that could lead to some strange, hard to resolve errors, and is generally seen as a bad practice amongst the Nest community.

Weathering

Thank you very much for your response. I was using UserService.findUser in Auth module. And using Auth module service methods in UserService. Could you please suggest a better way to handle such a case? For now, I moved the User service method to Auth module instead of using forwardRef(). – Shrovetide

Auth is usually one of the few places that I see tightly bound logic that makes sense for it to be tightly bound. I've ended up creating an AuthModule that has it's own connection to the user table and a UserModule that has another connection to the user table. Ends up duplicating some logic, but it keeps the circular reference from happening, which I appreciate. For that though, it becomes preference to an extent. – Weathering

Thank you. I got it. – Shrovetide

@JasurbekNabijonov im a little late to the party but here is what you do. you have a open rest POST 'login' where use can login as example with username/pw this endpoint gives back a jwt token. then on the endpoint where as example users/:id GET you add a guard where the guard checks if the jwt token is valid. this dosnt require a call to the db since the tokens are checked by the signing. the nestjs has really great docs about pretty much everything you need to know for building a stable a secure api: docs.nestjs.com/security/authentication – Orinasal

Answer 2

Depending on your domain, the relations between your modules would be "naturally" interdependent. Even it's true you can apply techniques to avoid that, the result sometimes is "not natural", at least for humans, and can become hardly understandable for the team, creating new issues later on the maintainance.

As a non-official alternative, I wrote a post about how to delay at maximum the resolution of the services injections (that's basically at runtime). I was hardly inspired on Java and Spring annotation @Autowired.

You can read the full post here: https://fjbarrena.dev/blog/autowired-annotation-in-nestjs

For sure this approach will have drawbacks as well, but yeah, at least for my domain works pretty well.

Hope you find it useful!

Rollick