These are chat archives for graphql-java/graphql-java

4th
Sep 2018
Shrikant
@ShiniIn
Sep 04 06:10

I am using 9.0 and my response values are changed into (?) characters. For example
"data": {
"StudentCreate": {
"identity": {
"customId": "???(????????????"
}
}
}

where value of custom id is 的資料(解釋內文之英文單字均可再.

Brad Baker
@bbakerman
Sep 04 06:10
@ShiniIn - again what frameworks are you using
for excample to turn the ExecutionResult into a JSON object
I suspect its there
Shrikant
@ShiniIn
Sep 04 06:12
I am using spring framework and returning response by converting to hashMap
from the api fecthers
Brad Baker
@bbakerman
Sep 04 06:15
have you debugged it while inside the fetchers - does it change values in the graphql engine data fetchers or is it later when the ExecutionResult result = graphql.execute(query) is turned into a map on the HTTP wire
I still strongly suspect its your layer (Jackson?? something else??) that creates JSON / HTTP responses
Shrikant
@ShiniIn
Sep 04 06:18
Okay let me debug the whole flow once if still I need your help i will revert back
Shrikant
@ShiniIn
Sep 04 07:29
@bbakerman thanks actually there was issue in my controller only I have set the contenet type but not the char encoding
it was resolved after that
Brad Baker
@bbakerman
Sep 04 07:29
:)
Serhii Makhov
@Deadid
Sep 04 09:01
Hi guys! We want to use graphql-java library in our project! How it is possible to map types from graphqls file to existing POJO's? Is it possible with only graphql-java library or I should add something like spqr or what?
Bojan Tomić
@kaqqao
Sep 04 09:10
If you already have the schema in SDL (and prefer to keep it that way) and the POJOs, you do not need SPQR (as it generates the schema from Java classes).
You wire each field individually to a resolver function (modeled by the DataFetcher class), so you decide the mapping to your Java code at that point. For trivial fetchers that only call a getter, you don't need to wire anything.
Serhii Makhov
@Deadid
Sep 04 10:01
thank you
Bojan Tomić
@kaqqao
Sep 04 10:31
E.g.
return RuntimeWiring.newRuntimeWiring()
     //find a book (POJO) using your existing code
    .type("QueryRoot", typeWiring -> typeWiring
        .dataFetcher("book", env -> callYourCodeThatReturnsBookPOJO())
    )
    .type("Book", typeWiring -> typeWiring
        //you can skip this one because it only calls a getter
        .dataFetcher("author", env -> ((Book)env.getSource()).getAuthor())
    )
@Deadid hope that helps
Brad Baker
@bbakerman
Sep 04 10:51
btw new graphql-java 10 allows POJO looking methods (get/is) to take DataFetchingEnvironment as a parameter
so you can get more context into your pojos if need be
eg
   public String getFieldNamedX(DataFetchingEnvironment env) {
        ...
Arnab Datta
@arnabkd
Sep 04 12:59
How does graphql-java respond to things like name: String! @fake(type: firstName) (the annotation)? I am thinking of putting those annotations in place to support graphql-faker for our frontend dev
Serhii Makhov
@Deadid
Sep 04 14:13
Does datafetchers work with reactive types?
Bojan Tomić
@kaqqao
Sep 04 14:24
@Deadid You can only use CompletableFuture for regular fetchers and Publisher for subscriptions
So if you want to use Rx or Reactor or whatever, you'll have to map them to CompletableFuture
Serhii Makhov
@Deadid
Sep 04 14:42
Could you provide example pls?
@kaqqao
Bojan Tomić
@kaqqao
Sep 04 15:08
Of what? You'll have to be more specific.
they use reactive streams as way to get data back from a subscription
HOWEVER graphql-java data fetchers (aka field resolvers) DONT support reactive types
you can give back a reactive list of names and have it automitacially converted into a list type in graphql (by the framework)
reactive is viral - once it supports a truly reactive set of type then it tends that ALL of it must be reactive to get value
how can however turn your reactive values into CompleteableFutures really easily
rxjava for example might do CompletableFuture<List<Integer>> future = Futures.fromObservable(observable)
graphql will handle that CF - it is virally built on top of CompleteableFuture
Brad Baker
@bbakerman
Sep 04 22:21
reactor is even easier : CompletableFuture<List<Integer>> mono.toFuture()