Flow return type in Subscription causes an exception when booting up Spring Server

[serandel]

I'm trying to use the support for Flow in subscriptions, to avoid having to convert them to publisher as a last step in my functions. (Which seems to work perfectly fine, btw.)

If I write my subscription like

class ProductSubscription(private val productRepository: ProductRepository) : Subscription {
    fun getAllLive(code: String? = null): Flow<List<Product>> = // whatever...
}

then I get this when executing bootRun:

[com/expediagroup/graphql/server/spring/NonFederatedSchemaAutoConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [graphql.schema.GraphQLSchema]: Factory method 'schema' threw exception; nested exception is com.expediagroup.graphql.generator.exceptions.InvalidSubscriptionTypeException: Schema requires all subscriptions to be public and return a valid type from the hooks. ProductSubscription has PUBLIC visibility modifier. **The function return type is Flow**

After reading the documentation, I reckon that the schema generation is using NoopSchemaGeneratorHooks. So I'm trying to enable FlowSubscriptionSchemaGeneratorHooks by creating this class:

package com.example

class ProductSchemaHooksProvider : SchemaGeneratorHooksProvider {
    override fun hooks(): SchemaGeneratorHooks = FlowSubscriptionSchemaGeneratorHooks()
}

and creating a src/main/resources/META-INF/services/com.expediagroup.graphql.plugin.schema.hooks.SchemaGeneratorHooksProvider file with this content:

com.example.ProductSchemaHooksProvider

Nevertheless, nothing seems to change, and I still get the same error. Am I even going the right way about enabling this? The documentation just says that:

graphql-kotlin-spring-server provides automatic support for Kotlin Flow through FlowSubscriptionExecutionStrategy that supports existing Publishers and relies on Kotlin reactive-streams interop to convert Flow to a Publisher.

Any help would be very appreciated! :)

GraphQL-Kotlin: 6.0.0-alpha5
Spring Boot: 2.7.1
Java: 17

[serandel]

I got it working by providing this bean in my app:

class ProductSchemaGeneratorConfig(@Value("\${graphql.packages[0]}") supportedPackages: String) : SchemaGeneratorConfig(
    supportedPackages = listOf(supportedPackages),
    hooks=FlowSubscriptionSchemaGeneratorHooks())

Should this perhaps be the default?

[serandel]

The graphqlGenerateSDL Gradle task doesn't work though :(

[dariuszkuc]

Generate SDL task relies on the SchemaGeneratorHooksProvider to locate the appropriate hooks. Make sure that hooks are available on the classpath.

[serandel]

I had it on my project and pointed at by the src/main/resources/META-INF/services/com.expediagroup.graphql.plugin.schema.hooks.SchemaGeneratorHooksProvider file, with no success. Is there anything I'm overlooking here?

[dariuszkuc]

It seems correct. If you got a sample github repo I can take a look.

[serandel]

Thanks, it's in a company repo. Let's see if I can extract a minimum example...

[samuelAndalon]

Hello we will take a look at this, in the meantime have you looked at
https://opensource.expediagroup.com/graphql-kotlin/docs/schema-generator/execution/subscriptions ?

TLTR;

you just have to have the return type wrapped in an implementation of a reactive-streams Publisher

so for now -- if you data fetcher / resolver returns a flow you can just simply interop to Flux

[serandel]

Yes, with Reactive Streams it works without any problem. I would be very keen on having Flow as the return type of my bean functions and be able to test them with Turbine, though.

Thanks for your help!

[dariuszkuc]

Hello 👋
Indeed, while the spring-server automatically configures the FlowSubscriptionExecutionStrategy it currently won't work without specifying the FlowSubscriptionSchemaGeneratorHooks. The reason why default logic/hooks were not updated to support Flow is because the schema-generator can be used without spring-server support and plain graphql-java doesn't know anything about the Flow, i.e. if we update the lib to automatically support Flow it would still blow up at runtime as the default subscription execution strategy wouldn't know what to do about it. I think in spring-server we can default to use FlowSubscriptionSchemaGeneratorHooks (instead of no-op one).

As a side note - instead of re-creating the whole config object you should be able to just create the hooks bean and it should autowire everything for you. I'll update the docs to reflect this.

There are a few caveats though that may or may not be problematic for you

• subscriptions are not supported by the Apollo Federation
• spring-server implements old deprecated subscriptions-transport-ws protocol and not the new graphql-ws prototcol

Personally I'd double check whether you really need subscriptions as they do have a number of drawbacks and in most cases @defer/@stream or live queries might be a better fit.

[serandel]

Thanks a lot for all the info, as a GraphQL newbie I wasn't aware of much of that!

I'll change the way I override the NoOp hooks in Spring, but I reckon it could already be the default in spring-server in a future release, to align with the FlowSubscriptionExecutionStrategy.

Your comments about the drawbacks of subscriptions are very interesting. Could I bother you with a couple of extra questions?

• Is there any technical reason (apart from having the time and manpower to do it, of course) to not use graphql-ws in spring-server?
• @defer/@stream are supposed to be short-lived and used for incremental loading, which is not my use case. Live queries are exactly what I want though. My concern is that they're not part of the standard yet, even if they've been defined for over five years. The differences with subscriptions are not that big from a client POV either. (I like the syntax better, but that's hardly a problem.) What reasons do you think would make live queries preferrable over subscriptions? Are they transparent to Apollo Federation?

[dariuszkuc]

FYI #1479

Is there any technical reason (apart from having the time and manpower to do it, of course) to not use graphql-ws in spring-server?

We implemented subscriptions a while back and never got around to updating it. Contributions are always welcome!

What reasons do you think would make live queries preferrable over subscriptions? Are they transparent to Apollo Federation?

Yeah they will be supported by Apollo (they are not yet). If you are using websockets then the biggest problem with subscriptions is the very long lived connections - eg if you have 1000 clients your server will need to keep 1000 connections open. IMHO it is rather hard to scale. With live queries you could simply do HTTP polling which may not be as efficient as web sockets but eliminates the need to keep constant connections open.

[serandel]

We implemented subscriptions a while back and never got around to updating it. Contributions are always welcome!

That's why I was asking. No promises, though. ;)

What reasons do you think would make live queries preferrable over subscriptions? Are they transparent to Apollo Federation?
Yeah they will be supported by Apollo (they are not yet). If you are using websockets then the biggest problem with subscriptions is the very long lived connections - eg if you have 1000 clients your server will need to keep 1000 connections open. IMHO it is rather hard to scale. With live queries you could simply do HTTP polling which may not be as efficient as web sockets but eliminates the need to keep constant connections open.

Thanks again for your insights!