Explore different Graphql servers

[ESchouten]

With KGraphQL development being stale since august 2021 and the developer going AWOL, other graphql server libraries should be considered.

Update JUNE 2022: KGraphQL author seems to have returned, looking for maintainers

Possible candidates:
Kaguya
GraphQL Kotlin
Possible official KTOR Graphql support post 2.0 release

[LSafer]

I might add my implementation https://github.com/cufyorg/kaguya 😗

It is a kotlin-friendly wrapper for graphql-java with ktor integration

You might try the template https://github.com/cufyorg/ktor-graphql-template

[ESchouten]

@LSafer Looks very nice and clean! Will definitely investigate your library further soon, added it to the list above.

[Francynox]

@ESchouten I worked for a graphql-kotlin implementation.
If you want to take a look at it it is in my fork

[ESchouten]

@Francynox very impressive! What's your impression of graphql-(java/kotlin)? How does it compare to kgraphql? Do you like it?

[Francynox]

sure, i want to make a list of pros and cons of the things saw in the library

Pros

• maintained by a dedicated team of developers, at least that's what it says in the repository. I think ExpediaGroup use this library in production too
• subscription support
• very powerful schema generator that allows many customizations

Cons

• wrapper of a Java library, I don't think it's a problem... but it's not "pure" kotlin
• I have the impression that it is a little bit slower in executing requests compared to KGraphql
• with the current implementation of usecases schema generation takes a lot of work, a change in schema generation could result in further changes (not sure about that)

Final tought
in general i think the library is stable and his strength is definitely the schema generator; I think it has to be preferred over KGraphql as, in my opinion, its future is a bit uncertain.

[ESchouten]

@Francynox I agree with your points
It seems a bit more powerful which might enable (or make easier) things like customizing parameter names, which are now a0, a1 etc.

The main thing I dislike about the library is how complex it is and how much more boilerplate is involved. The only thing we're using GraphQL for is the typed API, GraphQL is not integrated into our system.

Basically what I described in #18, btw what's your opinion on this statement + issue #18?

[LSafer]

@Francynox

I have the impression that it is a little bit slower in executing requests compared to KGraphql

No, its not. At least, not like what you think

KGraphQL uses reflection for invoking the resolver and it really rely on it, to the degree you can't escape it!

I don't know about the speed of kotlin reflection but it must be slower than no reflection.

[Francynox]

@ESchouten

The main thing I dislike about the library is how complex it is and how much more boilerplate is involved. The only thing we're using GraphQL for is the typed API, GraphQL is not integrated into our system.

You're corerct, but i think with a library like this we can integrate Graphql by adding things like recirsive queries only by manipulating the schema and the dataFetcher
However, I don't know how much work it would actually take!

Basically what I described in #18, btw what's your opinion on this statement + issue #18?

Unfortunatelly i don't know much about OpenAPI but i think if we can add recursive queries successfully it would be nice to have Rest and Graphql both working

@LSafer

I don't know about the speed of kotlin reflection but it must be slower than no reflection.

You must be right! I have not tested the speed of KGraphql and graphql-kotlin properly, mine was just an on-screen impression, expecially with the LoginUser query

[ESchouten]

@Francynox I'm already serving a REST API in a separate project, will add it tomorrow or the day after. OpenAPI will come later, heard the Ktor team approximate late summer release.