I got a basic setup for Micronaut up with version ...
# graphql-kotlin
d
I got a basic setup for Micronaut up with version 4, nice job in all the abstractions! Just wondering about the subscriptions part... there wasn't anything in the Ktor example for that.
j
subscriptions seem to still be tied to server implementations -- there's a jetty+coroutines one here based on latest graphql-kotlin 3.x release https://github.com/trib3/leakycauldron/tree/main/graphql/src/main/kotlin/com/trib3/graphql/websocket in addition to the spring+webflux one, if that's helpful at all. would be interesting to see if moving to a javax.websocket based one could be made to work on multiple server implementations?
d
The docs seem to state that:
Subscriptions require a more indepth knoweldge of how the specific server library handles protocols and streaming. Since we can only support 
Publisher
 from 
graphql-java
 in this common library, we can not provide any common logic for subscriptions. Therefore you will still need to implement the route and request handling for subscriptions separately if you are not using a provided server implementation.
Micronaut has a non-blocking version using Publisher... does that mean that it would be easier to implement? https://docs.micronaut.io/latest/guide/index.html#websocketServer
s
It may be pretty straight forward to implement. If you are looking for an examples you can check out the subscription support in
graphql-kotlin-spring-server
. It’s just that subscription have to know more about how to handle web sockets and use the specific spring
WebSocketSession
to read and send data https://github.com/ExpediaGroup/graphql-kotlin/tree/master/servers/graphql-kotlin-[…]ain/kotlin/com/expediagroup/graphql/server/spring/subscriptions
👍🏼 1
I suppose we could maybe move some of the logic for how we handle the
graphql-ws
subprotocol defined by Apollo but even then it is still a lot of code tied to using Jackson and caching the spring specific sessions to send requests back and have custom hooks on top of spring specific events
j
yeah there's opportunity for reuse of core protocol and logic, separate from the websocket server impl, would probably just need to introduce an interface/adapter layer for the above. really either of the above impls are good and well tested to start from. its been a bit since I've dug into the details but a fresh set of eyes on a micronaut impl might suggest the best way for code reuse between servers.
👍🏼 1
d
I'm really currently looking into my options, but if it's as easy to implement as the http version currently is... it might be another good tool in our pockets!
j
(also note that auth gets even more interesting/underspecified than the websocket protocol transport itself, that's where I've done more recent work)