HasuraModule with forRootAsync is not working

[rigobcastro]

When I import the HasuraModule with forRoot it works

     HasuraModule.forRoot(HasuraModule, {
         secretFactory: 'myadminsecretkey',
        secretHeader: 'x-hasura-admin-secret',
    }),

But when I import the module with forRootAsync it doesn't work

    HasuraModule.forRootAsync(HasuraModule, {
      inject: [ConfigService],
      imports: [ConfigModule],
      useFactory: async (configService: ConfigService) => ({
        secretFactory: configService.get<string>('GRAPHQL_API_AUTH_TOKEN'),
        secretHeader: configService.get<string>('GRAPHQL_API_AUTH_HEADER'),
      }),
    }),

I think it's something that I'm missing because no errors appears on the console just the RouteExplorer doesn't map the routes.

Thanks for your support.

[WonderPanda]

Hey @rigobcastro thanks for reporting this. I can confirm that the route isn't being mapped when using forRootAsync and will look into this.

As a side note, much do you leverage the ConfigService in your current application? I'm working on a new package that prevents the need to use forRootAsync in these situations because the equivalent of a ConfigService will already be bound and globally available before NestJS DI system.

This enables previously impossible patterns like dynamically configuring decorators as well.

[WonderPanda]

I found the issue. I'll have a new package version published later today just need to update some test cases so this is caught in the future

[WonderPanda]

Hey @rigobcastro thanks for reporting this. It should be fixed as of @golevelup/nestjs-hasura@0.3.3

[rigobcastro]

Thanks @WonderPanda for your fix.

I use the configService to storage secret values via environment files trying to comply with methodology https://12factor.net/config. Your idea sounds great let me know if you want a tester.

[WonderPanda]

@rigobcastro If you're still interested in testing the new config service checkout https://github.com/golevelup/ts-ecosystem/tree/master/libs/profiguration

It provides a number of benefits over the NestJS Configuration module that'll help you achieve 12factor:

• intellisense/type safety out of the box (you don't need to do get<string>(key) because we already know it's a string)
• exists outside the DI system so you can use it anywhere (even in decorators!)
• automatically coerces values to the correct datatype (no more needing to do weird conversions for boolean strings)