Graphback: PubSub engine created even when all subscriptions options on the @model are `false`

[machi1990]

• Module: graphback
• Version: 1.0.1
• Node.js / npm versions:

• Example/snippet of the model that is causing issue

  1. https://github.com/aerogear/graphback/blob/72b64ebe2b00777d831bc771b5eb052e89dd024a/packages/graphback/src/buildGraphbackAPI.ts#L126
• https://github.com/aerogear/graphback/blob/72b64ebe2b00777d831bc771b5eb052e89dd024a/packages/graphback-datasync/src/services/createDataSyncService.ts#L22

I think we can control this instantiation via the various configuration knobs we have.

[machi1990]

/cc @craicoverflow, @wtrocki
Automatically generated comment to notify maintainers

[craicoverflow]

What if the user brings their own subscriptions, either through a plugin or by writing custom resolvers.
Would it be better again to detect if there is a Subscription type in the schema, and only instantiate it in this case?

[wtrocki]

Wait - those are InMemory PubSub created in DataSync without option to override them.

[craicoverflow]

No - you do not see the lines above/below; it is the default which can be overridden.

https://github.com/aerogear/graphback/blob/72b64ebe2b00777d831bc771b5eb052e89dd024a/packages/graphback-datasync/src/services/createDataSyncService.ts#L21-L25

[machi1990]

What if the user brings their own subscriptions, either through a plugin or by writing custom resolvers.
Would it be better again to detect if there is a Subscription type in the schema, and only instantiate it in this case?

Makes sense, but it's much better for us to advocate the usage of configuration knobs i.e I do not see the point of a user bringing in their own CRUD subscription even if all the subscription options are disabled. That's sounds like by passing our setup and in this case,the users are in the land of their own and can instantiate the pubsub engine as they see fit.

[craicoverflow]

Appears to be closed by https://github.com/aerogear/graphback/pull/2139 - @machi1990 can you confirm?

[machi1990]

Appears to be closed by #2139 - @machi1990 can you confirm?

Good catch. Yes, this has been fixed by #2139, thanks to @RinkiyaKeDad