[GraphQL] Subscriptions support

[carlwoodhouse]

Supporting subscriptions would allow us to notify consumers of the api that content has changed; which they might use for invalidating caching, rebuilding gatsby sites, etc.

more info:

• https://graphql-dotnet.github.io/docs/getting-started/subscriptions/
• https://github.com/graphql-dotnet/server/blob/develop/samples/Samples.Server/Startup.cs
• https://graphql.org/blog/subscriptions-in-graphql-and-relay/

[MatthijsKrempel]

We have a simular request from the organisation, any pointers to how we should proceed?

[sebastienros]

You might be able to add a subscription already

Start with something like this services.AddSingleton<ISchemaBuilder, ContentItemSubscription>(); which will give you access to the ISchema that contains access to queries, mutations and subscriptions. From that just follow the documentation from GraphQL.NET

[carlwoodhouse]

Yeah just follow what’s in the links; I think the only thing is you have to enable web sockets .. plenty of examples about

…

On Thu, 7 Nov 2019 at 19:07, Sébastien Ros ***@***.***> wrote: You might be able to add a subscription already Start with something like this services.AddSingleton<ISchemaBuilder, ContentItemSubscription>(); which will give you access to the ISchema that contains access to queries, mutations and subscriptions. From that just follow the documentation from GraphQL.NET — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4489?email_source=notifications&email_token=AADRUEB22XBYV36E2FYIEKLQSRRQHA5CNFSM4I6COKZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDNPEMY#issuecomment-551219763>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADRUEDTGUXV6SL5ERPI7KTQSRRQHANCNFSM4I6COKZQ> .

[MatthijsKrempel]

Ok, not quite familiar with it, but I will have a look.
I don't think it is as simple as adding a schema, we also have to have the middleware handling the request.

[jrestall]

The sample link @carlwoodhouse provided is really good https://github.com/graphql-dotnet/server/blob/develop/samples/Samples.Server/Startup.cs

I would suggest implementing this under its own feature such as "OrchardCore.Apis.GraphQL.Subscriptions" so that WebSockets is only enabled when subscriptions are used. So you would call AddWebSockets/UseWebSockets from a SubscriptionsStartup class like how the Users module does it here.

As for what the schema would look like for subscriptions, we need to discuss. Here's some initial options:

type Subscription {
  contentItem(where: SubscriptionWhereInput) : ContentItemSubscriptionPayload

  # OPTION 1
  blogPost(where: BlogPostSubscriptionWhereInput): BlogPostSubscriptionPayload

  # OPTION 2
  blogPost(where: SubscriptionWhereInput): BlogPostSubscriptionPayload

  # OPTION 3
  blogPostCreated : BlogPost
  blogPostUpdated: BlogPost
  blogPostRemoved: BlogPost
  blogPostPublished: BlogPost
...
}

# FILTER OPTION 1 (Simpler)
input SubscriptionWhereInput {
  # Filter for a specific mutation:
  # CREATED, UPDATED, REMOVED, PUBLISHED, UNPUBLISHED, CLONED
  mutation_in: [MutationType!]
}

# FILTER OPTION 2 (Allows for flexibility in future to filter on BlogPost specific fields.)
input BlogPostSubscriptionWhereInput {
  # Filter for a specific mutation:
  # CREATED, UPDATED, REMOVED, PUBLISHED, UNPUBLISHED, CLONED
  mutation_in: [MutationType!]
}

type BlogPostSubscriptionPayload {
  mutation: MutationType!
  node: BlogPost
}

Then create a ISchemaBuilder like public class ContentTypeSubscriptions : ISchemaBuilder similar to ContentTypeQuery that uses IObservable and ContentHandlerBase. Not sure exactly how this part would work currently.

We would actually be the first headless CMS to support graphql subscriptions once completed which would be cool! 🎉

[carlwoodhouse]

Totally agree it should be feature based due to the sockets dependency

…

On Fri, 8 Nov 2019 at 14:09, James Restall ***@***.***> wrote: The sample link @carlwoodhouse <https://github.com/carlwoodhouse> provided is really good https://github.com/graphql-dotnet/server/blob/develop/samples/Samples.Server/Startup.cs I would suggest implementing this under its own feature such as "OrchardCore.Apis.GraphQL.Subscriptions" so that WebSockets is only enabled when subscriptions are used. So you would call AddWebSockets/UseWebSockets from a SubscriptionsStartup class like how the Users module does it here <https://github.com/OrchardCMS/OrchardCore/blob/dev/src/OrchardCore.Modules/OrchardCore.Users/Startup.cs> . As for what the schema would look like for subscriptions, we need to discuss. Here's some initial options: type Subscription { contentItem(where: SubscriptionWhereInput) : ContentItemSubscriptionPayload # OPTION 1 blogPost(where: BlogPostSubscriptionWhereInput): BlogPostSubscriptionPayload # OPTION 2 blogPost(where: SubscriptionWhereInput): BlogPostSubscriptionPayload # OPTION 3 blogPostCreated : BlogPost blogPostUpdated: BlogPost blogPostRemoved: BlogPost blogPostPublished: BlogPost ... } # FILTER OPTION 1 (Simpler) input SubscriptionWhereInput { # Filter for a specific mutation: # CREATED, UPDATED, REMOVED, PUBLISHED, UNPUBLISHED, CLONED mutation_in: [MutationType!] } # FILTER OPTION 2 (Allows for flexibility in future to filter on BlogPost specific fields.) input BlogPostSubscriptionWhereInput { # Filter for a specific mutation: # CREATED, UPDATED, REMOVED, PUBLISHED, UNPUBLISHED, CLONED mutation_in: [MutationType!] } type BlogPostSubscriptionPayload { mutation: MutationType! node: BlogPost } Then create a ISchemaBuilder like public class ContentTypeSubscriptions : ISchemaBuilder similar to ContentTypeQuery that uses IObservable and ContentHandlerBase. Not sure exactly how this part would work currently. We would actually be the first headless CMS to support graphql subscriptions once completed which would be cool! 🎉 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4489?email_source=notifications&email_token=AADRUEHFSFUJYWRRR6LMI4TQSVXJPA5CNFSM4I6COKZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDSG4HQ#issuecomment-551841310>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADRUEDNH37VYGWKODZZNOLQSVXJPANCNFSM4I6COKZQ> .

[sebastienros]

I think you can only provide subs for

• a specific content item, or a list of content items, by identifiers
• a list, or anything where we manage the collection (list part, taxonomy term)
• any content item, with a set of filters that can be computed in memory (predicates): content type, status, author, stereotype

Because a query (sql or lucene) would be too complex to handle.

I'd like to hear about scenarios for subscriptions, and see how these points would solve them.

[rserj]

I'd like to hear about scenarios for subscriptions

Since Orchard Core an Application framework rather than just a CMS. Because of its multitenancy support, modularity, and great rendering engine, we have plans to use Orchard Core as FrontBack as a middleman between React client app and other backend services. We have non-CMS related scenarios where we need to send notifications from backend services to client React app, we use to use SignalR in the first Orchard for this purpose.

[rserj]

I dig a little bit further.
The problem is: Graphql-dotnet still relies on Single instance Schema. But we use ISchemaFactory.GetSchemaAsync()
we need it because if schema gets changed we can rebuild one plus each module can register their own ISchemaBuilder to modify the schema.
We had such problem with single-instance schema before, please see
#2164
graphql-dotnet/server#107
It is still a problem with Subscriptions, their approach doesn't fit for ours, so we have to implement and support some services

These are places in Startup.cs where a single schema is used:
https://github.com/graphql-dotnet/server/blob/develop/samples/Samples.Server/Startup.cs

I see multiple ways to adopt current implementation to our's

1. We have to reimplement the next services to use our's factory approach for Subscriptions

• GraphQLWebSocketsMiddleware<TSchema>
  https://github.com/graphql-dotnet/server/blob/develop/src/Transports.Subscriptions.WebSockets/GraphQLWebSocketsMiddleware.cs

• WebSocketConnectionFactory<TSchema>
  https://github.com/graphql-dotnet/server/blob/develop/src/Transports.Subscriptions.WebSockets/WebSocketConnectionFactory.cs

• DefaultGraphQLExecuter<TSchema>
  https://github.com/graphql-dotnet/server/blob/develop/src/Core/Internal/DefaultGraphQLExecuter.cs
  I have a concern about this one, cause it is under .Internal namespace.

2. Try to embrace it by using a hack by registration services in our Startup.cs like

 services.AddTransient(typeof(IGraphQLExecuter<Schema>), provider =>
                    new DefaultGraphQLExecuter<Schema>(
                            provider.GetService<ISchemaFactory>().GetSchemaAsync().Result as Schema, 
                            provider.GetService<IDocumentExecuter>(),
                            provider.GetService<IOptions<GraphQLOptions>>(),
                            provider.GetServices<IDocumentExecutionListener>(),
                            provider.GetServices<IValidationRule>()));

3. Another way to create a Decorator and register one as Single Instance schema like

public class SchemaDecorator : Schema
   {
       public SchemaDecorator(IServiceProvider serviceProvider)
       {
           var dependencyResolver = serviceProvider.GetService<IDependencyResolver>();
           var factory = dependencyResolver.Resolve<ISchemaFactory>();
           var schema = factory.GetSchema().Result;
           .....// continue replace fields from our factory

and use it like in
https://github.com/graphql-dotnet/server/blob/develop/samples/Samples.Server/Startup.cs
instead of ChatSchema use SchemaDecorator

4. We can contact to graphql-dotnet dev and ask for solution/fix

5. Switch to Hot Chocolate https://hotchocolate.io here is comparisons
   https://www.reddit.com/r/graphql/comments/dpnqdx/hotchocolate_vs_graphqlnet/
   Justification for HotChocolate as opposed to GraphQl.Net ChilliCream/graphql-platform#392
   performance comparison:
   https://chillicream.com/blog/2019/06/05/hot-chocolate-9.0.0#performance

cc: @sebastienros

[sebastienros]

Are you sure hotchocolate would solve the issue?

[carlwoodhouse]

I’d love to switch to hot chocolate; I’ve been using it away from ocore and it’s a much better library; data loaders, Di support etc out of the box and tons of other features. the perf is much better too. However .. Can’t say if it would fix this or not; as didn’t look into it. The upgrade to ocore would be massive. I know this cos I started on a poc branch several months ago. It would be a major breaking change to anyone who has written their own graph types etc. So would need serious thought.

…

On Thu, 13 Aug 2020 at 18:30, Sébastien Ros ***@***.***> wrote: Are you sure hotchocolate would solve the issue? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4489 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADRUEE4L7CDLRQ6V4Y2SCTSAQPMLANCNFSM4I6COKZQ> .

[michaelstaib]

The upcoming version 11 solves your issues, as I understand.

https://chillicream.github.io/hotchocolate/blog/2020/07/16/version-11

The new schema configuration API allows full async creation and update of dynamic schemas since Hot Chocolate supports schema stitching we reworked version 11 to be able to push schema changes to the GraphQL Gateway dynamically. Schema stitching/schema federation and standard schemas become the same and let you fuse multiple sources and update them on the fly.

If you guys need help, let us now.

And sorry for barging in on this issue :) I just saw it linked to another issue on our project.