https://kotlinlang.org logo
Title
m

Marc Knaup

12/24/2019, 12:17 PM
Building an open source GraphQL Kotlin library is fun. Anyone interested in joining? 😄 I know there is one already, but, you know… diversity. And fun 🙂
d

Dominaezzz

12/24/2019, 12:19 PM
I've been considering building a multiplatform one, mostly around the codegen side for the client. (Haven't really use GraphQL before.)
m

Marc Knaup

12/24/2019, 12:19 PM
Mine is multiplatform and supposed to cover almost everything that the JS reference implementation does.
d

Dominaezzz

12/24/2019, 12:19 PM
But I'd be interested in contributing if you start something.
m

Marc Knaup

12/24/2019, 12:20 PM
No codegen yet though. Would love to see a compiler plugin at some point. For client & server.
https://github.com/fluidsonic/fluid-graphql Still messy as everything is work-in-progress and API far from final. Even the TODO is outdated 😄
d

Dominaezzz

12/24/2019, 12:26 PM
Ha! Just how I like it. 😁
m

Marc Knaup

12/24/2019, 12:26 PM
😂
d

Dominaezzz

12/24/2019, 12:34 PM
Looks like you have a parser so far right? To parse server schemas.
m

Marc Knaup

12/24/2019, 12:34 PM
yes, parses queries and schemas
just no extensions yet
d

Dominaezzz

12/24/2019, 12:36 PM
Nice, that should be enough to actually generate client side stuff.
m

Marc Knaup

12/24/2019, 12:37 PM
You want to generate Kotlin code from server schema?
I guess simple generation is easy with KotlinPoet. Compiler plugin would be nicer but also far more difficult.
d

Dominaezzz

12/24/2019, 12:41 PM
Yeah, like data classes and stuff.
m

Marc Knaup

12/24/2019, 12:44 PM
I always wonder what is nicer to have: • Generated types for each schema only • Generated types for each query to a schema (because fields can be absent and you may not want to make ALL fields nullable for that reason) In the second case they could share a common interface.
d

Dominaezzz

12/24/2019, 12:46 PM
Hmm, that's a good point. Can make it a configuration with "reasonable defaults".
m

Marc Knaup

12/24/2019, 12:48 PM
True, it’s also possible to offer both and let the user decide.
m

mbonnin

12/27/2019, 11:19 AM
Hi, just in case,
apollo-android
has an issue open to support native and multiplatform: https://github.com/apollographql/apollo-android/issues/1455
It might not be that far actually. IIRC, one of the biggest JVM dependency was okhttp but the generated models would still be usable without the runtime
m

Marc Knaup

12/27/2019, 11:22 AM
I guess Apollo does way more than GraphQL if it needs anything related to HTTP 🙂
m

mbonnin

12/27/2019, 11:24 AM
Mostly for subscriptions and cache support but most of the codegen is usable without the HTTP parts
What would a compiler plugin bring compared to plain codegen ?
m

Marc Knaup

12/27/2019, 11:28 AM
Changes to GraphQL document/schema automatically change code and vice versa - if needed. It would be part of the normal compilation rather than relying on command line tools or Gradle integration.
👍 1
w

wakingrufus

12/30/2019, 5:30 PM
m

Marc Knaup

12/31/2019, 7:46 AM
I’ve seen that but it’s almost completely different from what I want to achieve. Most importantly: • no reflection • no automatic schema-generation from Kotlin classes (at least at runtime - maybe through a compiler plugin) And they’re focused on the server. I want to have everything around GraphQL in my library - not the client/server logic around it. •
.graphql
file parsing (requests & schemas) •
.graphql
file generation • Kotlin DSL for creating schemas and requests • request execution & validation, independent of the environment • tools for working with GraphQL ASTs
👍 1
d

Dariusz Kuc

12/31/2019, 3:42 PM
cool project
just an fyi -
graphql-kotlin-client
(generates the type safe client based on the graphql query and target schema) is WIP and should be available in 2.0.0 release (no tentative date yet)
as for the kotlin native query execution -> that is something that we want to tackle eventually in
graphql-kotlin
as well (currently it relies on
graphql-java
) but there is no ETA on this