0

So I'm writing a pretty big RESTful web-app and I opted for NestJS. So far I like it, I like the modular structure with DI, and I find it very appropriate for a REST app.

My general structure is basically a number of modules for the "main" resources, and they each have their own sub-modules for their sub-resources.

I use the Repository pattern and made it so that any repository is available to any provider who whishes to get it (since it relies on a global dependency), but generally I use repositories in services related to the entity, and service functions across the module in controllers, guards, interceptors and so on.

Some resorces might be shared and so I also have some "partial" modules, instantinated in a slightly different manner from one resource to another.

Other than that, there are the "utility" modules, which I made all global for convinience, and provide general common functionality (database, authentication, 3rdParties).

The "issue" begins when sometimes, some resources need access to services in their parent-module, so a circular dependency resolution is needed. Other times a service is needed from a module that is outside this resource's module hierarchy branch, so a resource that is not "under" nor "above" this resource. I can already see the jungle of dependencies to come, with circular dependencies and basically making perhaps most of my "main" resource modules available for most other main resources.

Now I wonder why not just make all my "main" resource modules gloabl, thus all my services are available globally to anyone who wishes to inject them, plus all my sub-modules are basically also available anywhere, though you need to explicitly provide them in module definition.

Why not make all modules global, for that matter, if youv'e already leveraged the advantages of the modular approach, and make your life easier without having to define endless lists of dependencies in module definitions, and without circular dependency issues?

Am i missing something here?

I feel like I'm maybe not looking at it from the right angle..

Itay Davidson
  • 55
  • 1
  • 6

1 Answers1

0

They are called Framework for a reason, one of them is to stop you from shooting yourself in the foot. For example circular dependencies usually means bad design because two dependency should not be dependent on each other.

About Global modules surely you can define all of the as global modules by using @Global() decorator however it has some consequences.

One of them is that you allow other services to accidentally access dependency and cause unwanted change which would be very hard to track down when your project grows.

Another one is the same reason that we don't define variables globally, because they might also overlap. Also not every module is injected the same way. a Service might instantiate a dependency with different options from another service which also injects it.

omidh
  • 2,526
  • 2
  • 20
  • 37
  • IRL, sometimes you need those circularly dependant modules , and even Nest documentation states just that, and provide a way to deal with it. So simply saying that it means bad design is just the EASY, straight out of uni book mantra. Now what about making all my "main" resources global? it feels like it's omewhere in between. About the "shooting my own leg" thing - I also feel like that's not the case, I have a very reasonable spread of responsibilities inside each module separately, and across the app, and as I almost totally avoid mutations I'm not too worried about untrackable changes. – Itay Davidson Jun 29 '22 at 07:05