Subscription support

[jeggy]

Copied from: pgutkowski#27

[nidomiro]

Subscription-definition (on the server side) should look like the following example (from jeggy):

data class MyNormalValueClass(val value: String)
class MyTypeEvent(val value: MyNormalValueClass) : PubSubEventSealedClass()

...

val pubsub = PubSub<MyTypeEvent, MyNormalValue> { event: MyTypeEvent ->
  // This callback would be called once every event and sent to all subscriptions
  event.value
}


mutation("add") {
  resolver<MyNormalValueClass> { value: String ->
    val returnValue = MyNormalValueClass(value)
    pubsub.publish(MyTypeEvent(returnValue))
    returnValue
  }
}

subscription<MyNormalValueClass>("listenToAdds") {
  pubsub.iterator()
}

The Client will send a subscriptionquery and will receive a stream of data as response:

schema.execute("subscription { numbers }").forEach(::println)
// Output:
// 1
// 2
// ...

[nidomiro]

I'm currently working on this and it's really hard to accomplish.
I find myself rewriting lots of code - maybe I'm going the wrong route...

[jeggy]

@nidomiro yeah, rewriting lots of code sounds like the right route, but we should be careful before doing so.

I can see you started on a Flow implementation, which I really like 👍

But I think it's probably a bit too early to implement this. I would love to have the #37 and probably alongside a spring module implemented. And by having those resolved before starting on flows or something else, we will then have more concrete examples on how the full implementation of GraphQL from server side all the way to the client will work.

[jeggy]

@nidomiro I can see you are investigating ways on how to solve this. If you are considering making big changes to the internal setup. One other thing I would love to keep in mind when designing some new structure is the DataLoader(#19)

[nidomiro]

By implementing this feature I learn a lot about the lib.
Maybe I'll create a pullrequest for my Changes which doesn't affect the already implemented subscriptionsupport.
I'm looking forward for KTor and Spring support, but I plan do the subscription implementation. I learn a lot by doing so.

My activity was low and will be for a couple of weeks, because I have much to do at work.

[nidomiro]

Merging won't be an option... I tried, but because the files where moved I would have to copy every change manually to the new location...
I will redo the changes manually at the new structure :(

[gklijs]

@nidomiro I recently added subscriptions to micronaut, and didn't had to change any existing code. So if you had to rewrite a lot of code that sounds a bit worrying. There is also https://github.com/apollographql/subscriptions-transport-ws/blob/master/PROTOCOL.md which some of the clients kind of suspect as how it should work.

There is also https://github.com/excitement-engineer/ktor-graphql/tree/master/src/main/kotlin/ktor/graphql but I think have a pure Kotlin implementation will better and more performant. I'm going to give it a try using http://adavis.info/2018/02/graphql-api-in-kotlin.html as inspiration. Fist to get just the query working, then maybe to implement subscriptions.

[nidomiro]

@gklijs Thanks for your input. Maybe rewriting a lot is not the right way. Maybe I need to think about the problem for a bit longer.
My current idea is, that I just need to trigger a new "Query-Fetch" if the subscription triggers.

[gklijs]

How I did it, is having a separate controller, that instead of using a http request and response, uses a websocket. From that controller you can re-use a lot of the code since resolving the querie, etc works just the same as if it was a http request. Once you resolve and it turns out it was a query or mutation you can return those to the client. When it's a subscription it needs some more magic, since you need to subscribe to the publisher.

[markgitset]

Are subscriptions still not yet supported?

[jeggy]

Still not really supported 😞

But I'm including this in a bigger update that I'm currently working on. Where the results from schema.execute will not just return a String anymore, but rather a ExecutionResult object which you then can get the result directly from in String format or in the case of subscriptions you would get access to a Kotlin Flow.

This is still all work in progress, so any ideas of how this API should look are welcome.

[gklijs]

This is seen as the new/updated protocol. https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md so following that will probably means is compatible with most client implementations.

[ESchouten]

@jeggy In what stage is this update at this moment? Any way we could help/contribute?

[IceBlizz6]

Would be great to have proper subscription support.
Is there any progress being made on this?

[IceBlizz6]

@jeggy Would appreciate an update on this.
How far are we from getting full subscription support?

[code-slayer-007]

I see messages like subscriptions are not fully supported yet. Does that mean there is partial support?
If yes, does anyone have any sample code of subscription implementation?
@jeggy

[IceBlizz6]

Would love to get a reply from jeggy on this, but i strongly suspect that this project has been abandoned.
You may want to consider changing to a different library.
Kotlin is compatible with java, so you can also use GraphQL libraries written in java.

If you prefer to stick with KGraphQL and you want subscription support then you could try to take some code from graphql-kotlin.
That was my strategy, and it worked out well for us.
Take a look here:
https://github.com/ExpediaGroup/graphql-kotlin/blob/master/servers/graphql-kotlin-spring-server/src/main/kotlin/com/expediagroup/graphql/server/spring/subscriptions/ApolloSubscriptionHooks.kt