Today I tried to make a very simple GraphQL subscription and hit some dead ends. Details in thread.

Hey guys, a quick question - would it be possible for graphql-kotlin to be able to verify compatibility with existing schema? I really like the fact we can derive the schema from the code (definitely the way forward), but I wonder if we could have a mode which can tell us if the schema is the same as expected supplied schema or how they differ ... if this does not exists, how difficult this might be to be added?

I did some preliminary testing with kotlin 1.5.0 and the upcoming co-routines 1.5.0-RC and the latest expedia graphql 4.1. It looks like there is a bit of breakage. Some errors about functions that no longer exist in co-routines that look like they are being called from graphql. 1.4.3 is fine. We have some other issues as well blocking the upgrade (latest kotlinx serialization looks like it breaks stuff, one of our test libraries doesn't work with kotlin 1.5) so we are rolling back for now. Early days of course, but you might want to start testing with this on a branch.

In my understanding graphql-kotlin does not support persisted queries out of the box. How difficult it would be to add this support?

in spring server.. how can i set up a "filter" that can introspect all incoming graphql requests? i need to add spans with sleuth/brave and just cannot figure out where to hook into edit: found it.. this sample hould help me get started: https://github.com/ExpediaGroup/graphql-kotlin/blob/master/examples/server/spring-[…]rver/spring/instrumentation/TrackTimesInvokedInstrumentation.kt still not quite sure how to only extract the query name..

Hi, I wanted to understand how apollo GQL plugin works for android and iOS. Do they share the same codebase for generating the platform specific code? I wanted to build something which generate the code for both the platform at compile time. Any leads would be appreciated. Is there anyway to achieve the same thing by sharing the common codebase?

Is there a way to use a 3rd party annotation (ie, one that I can't directly annotate with @GraphQLDirective) as a directive? If not, what would need to get built out to make that possible? (Does @Deprecated just have explicit special handling that makes that one work?)

I just ran into a

com.expediagroup.graphql.generator.exceptions.TypeNotSupportedException

during schema generation where apparently one of my functions returns Unit which is not allowed. The problem is it does not tell me where the error is. Is there a way to get more detailed errors? Once I know where the error is, I can fix it. It would be helpful to improve this as this seems to happen a lot to me. In this case, complete mystery where the error is.

I’m trying to figure out how to “connect” my

KotlinDataLoader

and my custom context derived from

SpringGraphQLContext

. Is there any way to use the custom context from the dataloader itself?

Is there a way to serialize and re-use the GraphQLSchema object across process boundaries? I'm trying to reduce app startup time, and was thinking distributing a pre-built GraphQLSchema with my app would be one way to do that, as creating the schema seems to be the bulk of my startup time currently.

I have a question regarding nullable items, specifically interested in functions which return completable futures. At this point it seems every time a given function returns a nullable value (or nullable type of CF), when the dependency fails, the query returns null and then details in the error field in the response. Failures for the non-nullable types fail the whole query. I guess this works for most of the cases, but what if I need to fail the query completely in the case it given function return a nullable object? Pretty much need to differentiate between a regular value (which can be nullable) and the actual failure -> fail the whole query and not return null). Is something like this doable?

Hey all, wondering if anyone can provide a little guidance re: adding single headers to apollo graphql calls in Kotlin? Don't really want this to be a global header so trying to avoid the interceptor pattern.

interface TourService {
    @POST("/")
    suspend fun toursQuery(
        @Header("Authorization") auth: String,
        @Header("Content-Type") content: String = "application/json",
        @Body body: String): List<Tour>
}

object ApolloBuilder {
    private const val BASE_URL = "<https://somewhere.com>"
    private fun getApollo(): ApolloClient {
        return ApolloClient.builder()
            .serverUrl(BASE_URL)
            .build()
    }
}

I assumed that the

@Header

annotation would magik things in 😄

Thinking this may be more a ktor problem. I made a horrible work-around:

class KtorGraphQLRequestParser(
    private val mapper: ObjectMapper
) : GraphQLRequestParser<ApplicationRequest> {
    @Suppress("BlockingMethodInNonBlockingContext")
    override suspend fun parseRequest(request: ApplicationRequest): GraphQLServerRequest = try {
        val rawRequest = request.call.receiveText()
        val encoded = rawRequest.toByteArray(Charsets.ISO_8859_1)
        val decoded = String(encoded, Charsets.UTF_8)
        mapper.readValue(decoded, GraphQLServerRequest::class.java)
    } catch (e: IOException) {
        throw IOException("Unable to parse GraphQL payload.")
    }
}

I have a custom scalar type of

ClosedRange<LocalDate>

. I have defined and registered a

Coercing<ClosedRange<LocalDate>, String>

(and via debugger confirmed the coercer is being called at runtime), but I get a Jackson exception when parsing an Input:

Caused by: com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Cannot construct instance of `kotlin.ranges.ClosedRange` (no Creators, like default constructor, exist): abstract types either need to be mapped to concrete types, have custom deserializer, or contain additional type information
 at [Source: UNKNOWN; line: -1, column: -1] (through reference chain: my.MyInput["range"])

Any idea why that would be happening?

Hejhej! 🙂 I'm currently using the GraphQL-Client for Github GraphQL api - and as the Github GraphQL Endpoint is protected, I want to download the schema and use it directly. Fortunately there is

schemaFileName

- added with

5.0.0-alpha.1

17 days ago ( https://github.com/ExpediaGroup/graphql-kotlin/commit/a6b957c999398c741cdfbc955fb86243ea211094 ) 🙌 The version

5.0.0-alpha.1

was not released due problems with maven central ( https://github.com/ExpediaGroup/graphql-kotlin/releases/tag/5.0.0-alpha.1 ) one should use the

5.0.0-alpha.2

- but last version of graphql gradle plugin I found is

5.0.0-alpha.0

=> https://search.maven.org/artifact/com.expediagroup/graphql-kotlin-gradle-plugin/5.0.0-alpha.0/jar Was there a problem publishing the

5.0.0-alpha.2

and is there an alternative artifactory somewhere to test the

5.0.0-alpha.2

?

What's roughly the schedule for getting 5.0 out at this point? We are using 4.x currently but it kind of makes upgrading spring, kotling, co-routines, etc. a bit tedious due to the outdated versions of those that 4.x still uses. 5.x seems to fix that so we'd like to either switch to that or maybe it would be possible to get a maintenance release for 4.x? We got it working with kotlin 1.5.10 and co-routines 1.5.0. But going beyond that, it seems stuff starts breaking. I tried this last week with the latest spring boot and co-routines 1.5.1 and suddenly we got a lot of schema errors. It compiles and builds fine but our tests fail due to this.

I'm converting a jaxrs system which heavily depends on converting exceptions thrown in the code to status codes. I'm trying to do something similar in Graphql by returning a specific specification and having all queries/mutations return class that "implements" that specification. Basically, all classes get an

error: CommonErrorClass?

. It will be a bit hackish, but with some automatic schema validation it should work reliably. The problem is, I can figure out how to turn an

Exception

into a custom specification?

Is there a BoM published for graphql-kotlin somewhere?

I'm using

graphql-kotlin

together with a webserver called Armeria that has support for graphql-java (and an example for graphql-kotlin). The problem is that there is no way to get the

RequestContext

in suspend functions, nor to use the Dispatchers provided by Armeria in an easy way. I've solved it by extending and overriding methods in

FunctionDataFetcher

. It seems that

runSuspendingFunction

has parameters for at least

CoroutineContext

, so does that mean there are plans for greater configurability? E.g. by allowing the specification of a

CoroutineContext

in the constructor of

FunctionDataFetcher

or something similar? I doubt the problem is unique to Armeria, since I can't figure out how to pass the context through to suspending methods without byte-code instrumenting graphql-kotlin runtime?

I am having some difficulties with directives for FIELD_DEFINITION. I created a custom KotlinSchemaDirectiveWiring and set up hooks. I see that the KotlinSchemaDirectiveWiring.onField is called for the annotated fields. In onField I set a wrapped datafetcher, but that doesn't seem to be used.

Hello, I am looking for an example on how to implement query directive. Documentation mentions two query directive

@skip

and

@include

and I am trying to implement

@skipCache

query directive. The idea is that if request/client annotates field with

@skipCache

the server will always recalculate the latest values (instead of using cached one).

Hi, I am seeing an issue with `AttributeOverrides`:

@AttributeOverrides(value = {
    @AttributeOverride(name = "timestamp", column = @Column(name = "tstmp")),
    @AttributeOverride(name = "id", column = @Column(name = "userid"))
})

I am getting

an annotation cannot be used as the annotations argument

I saw that 5.0.0 was released. Thanks for that. The deprecation of Long and Double was something I had to work around a bit. We definitely need Long/Double numbers and not floats/ints. Using those is a bit of an antipattern in Kotlin unless you really know you don't need the precision. I would love some feedback on what the drawbacks are of this. I understand that javascript treats all numbers as 64 bit floats. Which raises the question why Doubles are not supported anymore since that is actually the closest thing Kotlin and Java have to what javascript supports natively. That translates as a 2^53 Long. So I understand why Longs were removed. We use Longs to send around timestamps in milliseconds after the epoch for that, Javascript's Doubles provide enough precision but Java's 32 bit Int doesn't. Json actually specify precision, which is why you can get frameworks like Jackson to deal with big ints and big decimals pretty easily. Beyond the limitations of javascript, are there any other concerns here? Not an issue for us because we actually use kotlin-js in the browser as well. So beyond bugs in kotlinx serialization (which we use for our multi platform graphql client), this won't affect us.

@Component
class FormationGraphqlHooks : SchemaGeneratorHooks {
    override fun willGenerateGraphQLType(type: KType): GraphQLType? {
        return when (type.classifier as? KClass<*>) {
            Long::class -> longScalar
            Double::class -> doubleScalar
            else -> null
        }
    }
}

private val longScalar = GraphQLScalarType.newScalar().name("Long")
    .coercing(object : Coercing<Long,Any> {
    override fun serialize(dataFetcherResult: Any): Any {
        return dataFetcherResult
    }

    override fun parseValue(input: Any): Long {
        return input as Long
    }

    override fun parseLiteral(input: Any): Long {
        return input as Long
    }
}).build()

private val doubleScalar = GraphQLScalarType.newScalar().name("Double")
    .coercing(object : Coercing<Double,Any> {
        override fun serialize(dataFetcherResult: Any): Any {
            return dataFetcherResult
        }

        override fun parseValue(input: Any): Double {
            return input as Double
        }

        override fun parseLiteral(input: Any): Double {
            return input as Double
        }
    }).build()

Hello everyone, we would appreciate some help with the problem below. I am using expedia graphql-kotlin library and dataloaders approach in particular to resolve types, but I am stack on the mutation implementation. I want to use already defined data loader for returning the result type( i want to be able to return full object, not just the part which changed) , but I need to chain the mutation call to happen before resolving the type. Soomething like

class ConsumerMutation(
    private val mutateDefaultConsumerAddressUseCase: MutateDefaultConsumerAddress
) : Mutation {

    @GraphQLDescription("Updates default consumer address.")
    fun setDefaultConsumerAddress(env: DataFetchingEnvironment, addressId: String): CompletableFuture<Consumer> 
        return mutateDefaultConsumerAddressUseCase.setDefaultConsumerAddress(env.getContext(), addressId).flatMap {
            //want to reuse ConsumerDataLoader for result fetching
            env.getValueFromMonoDataLoaderWithContext(ConsumerDataLoader::class, addressId).toMono()
        }.toFuture()
    }
}

Do you have any suggestions on how to use dataLoaders inside mutations or is it even a right pattern?

hello! I've been developing with the alpha3 version of graphql-kotlin. For various reasons I am stuck using java 8, and it's a project that isn't fully migrated to kotlin. When I try to pull 5.0.0, I get an error related to the target version of java. Is java 8 not supported with this release? Or is there maybe some setting I may be missing? Thanks!

`Variant 'apiElements' capability com.expediagroup:graphql-kotlin-ktor-client:5.0.0 declares an API of a library, packaged as a jar, and its dependencies declared externally, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm':
                 - Incompatible because this component declares a component compatible with Java 11 and the consumer needed a component compatible with Java 8

Is anyone else seeing this “Illegal reflective access” warning after upgrading to 5.1.x, or know the right way to prevent it?

Hi there, I was wondering, do you already have any plans on how to deal with the

GraphQLContext

changes in

graphql-java

? Will

graphql-kotlin

simply use graphql-java’s

GraphQLContext

as passing custom object definitions seems to be deprecated?

Hey guys, a quick question - is there any possibility to host two different schema in the same graphql-kotlin service (specifically in springboot)? I.e, one schema would live on

/graphql

endpoint and other schema would live on

/other_graphql

endpoint. Is something like this possible? If yes, can you give me some pointers how to do this?