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 and operator overloading. Many more are not, however. These include:
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