Global config service

[Goopil]

Hi,

In many projects, I have a relative similar config options for each module. For example, I mainly use paging cursor. I find it tedious to replicate each config in every module.

Would it be a good idea to address this with an optional general config at the AppModule level ?

This could also open the door to specify a replacement for the query service (soft delete inclusion for exemple)

What do you think ?

[TriPSs]

I indeed notice the same, think this would be a good idea.

Other question for you regarding doing the same a lot of times: I always (like 99% of the time) disable the following options on relations:

  disableUpdate: true,
  disableRemove: true,

What would you think: add that to the "global" config or if other ppl also always disable it make that the default?

[Goopil]

I did some various things, but have no luck so far.

I did find many things (that i wasn't aware when i first wrote this discussion)

1. The forRoot is called a lot after the forFeature. It make sens as a sub module would be ready before the model calling it
2. The current implementation is splitted in 2 phases. I would call them config time and runtime.
   The config time is done before the module using the forFeature is ready (no access to IOC container whatsover... only the defined configuration in the forFeature) and a runtime phase when the server is booted.

we can't leverage configuration from anywhere as the module defining the resolvers should have already all the service, resolvers & assemblers defined and ready when the onModuleInit live cycle hooks is called (the only place we could have both the module def and the container. Sadly too late)

I tried multiple things. From the static props (fail has there is no correspondance between forFeature call)
I also tried adding a service that resolve each defined createResolver at the earliest but this still happen to late.

lastly, i'm not sur that moving all the config layer to the runtime would be a good idea. I'm not event sure that it would work. Apollo need to have all the resolvers defined and ready before booting to generate the schema properly.

I feel a bit stuck on this point. And this tell me why the original owner didn't propose a forRoot already.

What is you pick on this ?

[Goopil]

Do you have other ways to explore perhaps ?

[TriPSs]

Can't think of something yet, will try to explore a bit and comeback hopefully with something. Thanks already for the work you put in!

[Goopil]

Well no worries, I was the one suggesting this. Of course, I would try to implement it. I should be the one thanking you to keep this projet alive ;)

I will keep trying as time pass But will also focus on other idea.

Let's keep in touch on this point has we find new idea

[Diluka]

I have an idea that may not be very plausible. We define a static variable on NestjsQueryGraphQLModule. Then use it in NestjsQueryGraphQLModule.forFeature.

for example

export class NestjsQueryGraphQLModule {
  // add a static default opts object
  public static defaultResolverOpts = {};

  public static forFeature(opts: NestjsQueryGraphqlModuleOpts): DynamicModule {
    const coreModule = this.getCoreModule(opts)
    const providers = this.getProviders(opts)
    const imports = opts.imports ?? []

    // do something like this
    for(const resolverOpts of opts.resolvers) _.defaultDeep(resolverOpts, NestjsQueryGraphQLModule.defaultResolverOpts);

    return {
      module: NestjsQueryGraphQLModule,
      imports: [...imports, coreModule],
      providers: [...providers],
      exports: [...providers, ...imports, coreModule]
    }
  }
}