# Type-safe GraphQL for Kotlin **URL:** \ **Category:** Uncategorized\ **Created:** [July 13, 2020, 2:55am UTC](https://discuss.kotlinlang.org/t/type-safe-graphql-for-kotlin/18433 "2020-07-13T02:55:08Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![rsmckinney](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/rsmckinney/32/7752_2.png) [@rsmckinney](https://discuss.kotlinlang.org/u/rsmckinney)\ **Post date:** [July 13, 2020, 2:55am UTC](https://discuss.kotlinlang.org/t/type-safe-graphql-for-kotlin/18433/1 "2020-07-13T02:55:08Z")
Hey guys. I’ve recently enabled the [Manifold](https://github.com/manifold-systems/manifold) Java compiler plugin for use with Kotlin and other JVM languages. I’ve got a sample [Kotlin application](https://github.com/manifold-systems/manifold-sample-kotlin-app) that could use some more experienced Kotlin eyeballs for review and comment. The application’s focus is GraphQL, however its purpose is to demonstrate how Kotlin can use Manifold to directly and type-safely access other resource types such as JSON, GraphQL, XML, Templates, Javascript, etc. My experience with Kotlin is limited, however, so feedback from Kotlin folks would be great. Thanks! > Note, only Manifold’s core [metaprogramming](https://github.com/manifold-systems/manifold/tree/master/manifold-core-parent/manifold) project is designed for use with Kotlin. Manifold extension projects are currently Java-only features. ---
**Author:** ![AlexeySoshin](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/alexeysoshin/32/5976_2.png) [@AlexeySoshin](https://discuss.kotlinlang.org/u/AlexeySoshin)\ **Post date:** [July 19, 2020, 9:35am UTC](https://discuss.kotlinlang.org/t/type-safe-graphql-for-kotlin/18433/2 "2020-07-19T09:35:07Z")
Not clear how this solution is different from [KGraphQL](https://github.com/aPureBase/KGraphQL), for example. Code such as ```auto val data = execute.getData() ``` in the example also doesn’t convince me much in type-safety of that solution. If the goal of the solution is to generate _type-safe clients_, that’s fine, but it should be stated somewhere. Looking at the [Manifold](https://github.com/manifold-systems/manifold) itself, it seems like this plugin may be useful to Java developers, but most of the features it provides already exist in Kotlin, so some examples of how a Kotlin developer could benefit from it would be nice. ---
**Author:** ![rsmckinney](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/rsmckinney/32/7752_2.png) [@rsmckinney](https://discuss.kotlinlang.org/u/rsmckinney)\ **Post date:** [July 19, 2020, 6:45pm UTC](https://discuss.kotlinlang.org/t/type-safe-graphql-for-kotlin/18433/3 "2020-07-19T18:45:28Z")
GraphQL _ **is** _ itself a DSL, we don’t need yet another DSL to approximate it inside Kotlin as with KGraphQL. The central goal of Manifold is to bridge DSLs _directly_ and type-safely to the language via the type system. Thus what is unique about Manifold is that it provides _ **direct** _ access to GraphQL. There are no code generation steps. No DSLs. No data classes to maintain. No annotations. In the IDE you can make changes to GraphQL and instantly use the changes with code completion etc. in Kotlin without a compilation step. You can rename/refactor GraphQL references from Kotlin and GraphQL files as well as find usages, navigate, etc. So it’s quite a bit different. Manifold GraphQL is probably best for client usage. But it is really a means of working directly with GraphQL types and queries, regardless of context. For instance, the sample app uses it for data/setup on the server and for queries and mutations on the client. The execute.getData() call is the server’s one call to access the results of executing a query. Since that is the central dispatch of all results, there is no “type-safety” to be had; it’s just data at this point. At a high level Manifold is divided into two components: Type Manifolds and Extensions. As you point out the extensions target Java exclusively and a few of the them are already supported in Kotlin, such as [extension methods](https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-ext#extension-classes-via-extension) and [operator overloading](https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-ext#operator-overloading). Many more are _not_, however. These include: - [Unit expressions](https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-ext#unit-expressions) - [Preprocessor / Conditional compilation](https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-preprocessor) - [Structural typing](https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-ext#structural-interfaces-via-structural) - [Type-safe reflection](https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-ext#type-safe-reflection-via-jailbreak) - [Integrated templates](https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-templates) The sample GraphQL application demonstrates the other half of Manifold – the Type Manifold. These are Java _type system_ extensions which make them accessible, albeit indirectly, from Kotlin. Read more about type manifolds here: [https://github.com/manifold-systems/manifold/tree/master/manifold-core-parent/manifold](https://github.com/manifold-systems/manifold/tree/master/manifold-core-parent/manifold) ---
**Author:** ![darksnake](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/darksnake/32/2479_2.png) [@darksnake](https://discuss.kotlinlang.org/u/darksnake)\ **Post date:** [July 20, 2020, 11:29am UTC](https://discuss.kotlinlang.org/t/type-safe-graphql-for-kotlin/18433/4 "2020-07-20T11:29:01Z")
> [@rsmckinney](#): > > , we don’t need yet another DSL to approximate it inside Kotlin I am not sure I agree with it. HTML is DSL as well and JSON. But we still need language interface for them. ---
**Author:** ![rsmckinney](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/rsmckinney/32/7752_2.png) [@rsmckinney](https://discuss.kotlinlang.org/u/rsmckinney)\ **Post date:** [July 20, 2020, 6:06pm UTC](https://discuss.kotlinlang.org/t/type-safe-graphql-for-kotlin/18433/5 "2020-07-20T18:06:04Z")
Type manifolds are not an either/or proposition; definitely not a panacea. However, in my view many use-cases involving DSLs are better suited with type manifolds. Generally, if the DSL duplicates the _system of record_, it’s probably better as a type manifold. For instance, if an API is published as JSON, GraphQL, or what have you, type manifolds are likely more suitable. The main idea is to avoid reinventing the wheel with redundancies such as in-language DSLs, instead keep it simple and use the primary DSL directly. Regarding HTML, I would say a DSL is sometimes the inversion of the right solution. For many cases it’s probably best to use a type-safe template where HTML is the base content with Kotlin as the embedded logic, see [Manifold templates](http://manifold.systems/manifold-templates.html). Again, the idea is to use the _real_ DSL – use HTML! Type-safely embedding other languages such as JSON, GraphQL, and HTML directly in Kotlin as declarations and expressions is also quite useful. [Manifold fragments](https://github.com/manifold-systems/manifold/tree/master/manifold-core-parent/manifold#embedding-with-fragments-experimental) achieve this with Java: ![image](https://us1.discourse-cdn.com/flex019/uploads/kotlinlang/original/2X/0/0903dac213321c0801b4fe1457f165da48b5ca28.png)