@karlstefan can you explain your problem in a bit more details and/or post your schema (and resolvers)?

Anyone here got experience with lacinia? I'm writing a graphQL proxy for a REST api, and I'm having problems traversing the REST endpoint and building tree data based on the response.

Yes

Give me asec

I have some (limited) experience with Lacinia

but hopefully enough to answer your query

Uhm, what paste tool do you prefer for edn files?

@karlstefan I tend to use gist

@hmaurer https://gist.github.com/Karl-Stefan/80e8e5d6e406b46136a5a7f7687654d2

It works for the first level

@karlstefan can you paste your resolvers too please?

@hmaurer https://gist.github.com/Karl-Stefan/0d56f06c0c50d16eafa454f2c9f7ab3f

(you can put multiple files in a single gist by the way :p)

can you also paste a sample reply from your API?

oh, thanks hehe

Yes!

also when do you use the read-object-key resolver?

https://gist.github.com/Karl-Stefan/d019b604dec21df56c496b7622012e1b

The api is constructed with different 'model roots', which correspons to whatever domain the data belongs to. If the client/request-backend is called with nil it returns all of them in a hashmap.

This works, I've tested it.

But building the three from object { children { object { children ... etc does not

When the endpoint answers a call for an rid, and the object has children, it is returned as an array with of objects, and they all have the keys :rid :name :id

Somehow the object does not resolve children objects

can you tell me what the result of (get :body) is in read-object-rid?

(what the value returned by the resolver is)

Thats the body of an REST call, contains json data that is converted to a hashmap

(get :status) would yeild i.e 200 for OK or 401 for auth fail

so it contains the data that’s under the object key?

or is it wrapped in data -> object -> ...

as in https://gist.github.com/hmaurer/79c838966dff65b94d9c6a7102c9f7eb#file-response-L1

oh nevermind sorry, that’s your reply from the graphql API

I meant to ask if you could paste the response from your backend API

then one you call with client/request-backend

just to see the json structure there

Oh, sure I'll show what a curl does. (I'm not sure how to pipe output in the REPL)

a curl will do 🙂

https://gist.github.com/Karl-Stefan/948e39921de8c6ab08a5da8366c48ab2

Thats an object which has children

There is a lot going on in that output, but only the rid, and children are relevant properties

oh hang on, actually I think the issue is pretty simple

you cannot have a resolver for an object

the key :resolve under an object has no meaning

I didn’t spot it at first

https://gist.github.com/hmaurer/79c838966dff65b94d9c6a7102c9f7eb#file-schema-edn-L35

Ah

resolvers only make sense on fields (or queries, which are essentially fields)

so you need to put a resolver on :children

which will be given the array of children

under :Object?

yes

hang on

I see, so just to be clear, I put the resolver under :object {:Object and not :queries ?

try this https://gist.github.com/hmaurer/79c838966dff65b94d9c6a7102c9f7eb#gistcomment-2202869

the resolver should be here:

:children {:type (list Object) :resolve :my-resolver}

(under the Object)

you need to have one under queries too, to get the initial object from the API

but after that (to traverse nested children), it will use the field resolver

I see, lemme try! 😄

I'm probably being stupid now, but I need a new resolver for this, right?

yes

the one I posted in a comment

(I did’t try it though, maybe I got it slightly wrong)

(yes to you needing a new resolver, not being stupid :p)

To recap:

(1) get rid of :resolve :resolve-read-object-rid under :object :Object in your edn schema

(2) add :resolve :my-resolver (or whatever other name you want) under :object :Object :fields :children

then register a resolver under :my-resolver mapping to the following function (which I hopefully got right):

(fn [context args _value]
  (map (fn [val]
              (:body (client/request-backend (:rid val)))) _value)

I think the resolver function is wrong, the repl throws an "Unsupported binding form" error

ah I missed a parentheses maybe?

(fn [context args _value]
  (map (fn [val]
              (:body (client/request-backend (:rid val)))) _value))

(defn read-objects-rid [context args _value] (map (fn [val (:body (client/request-backend (:rid val))) _value])))

Oh

hold on

[val …

my bracket matcher at work

parinfer?

Yes

haha

"message": "Field resolver returned a single value, expected a collection of values.",

from graph i QL

@karlstefan are you sure you got the resolver right?

counting brackets

😄 are you sure you are using read-objects-rid and not read-object-rid too? @karlstefan

Haha, yes

Lets see now

It seems to be working somehow, but its stuck in an infinite loop hitting the API

well, that’s progress

I am not sure how it could be stuck in an infinite loop though

Thats a tricky one

But I got something to go on now, thanks a lot for your help!

I see the problem now

I'm requesting an enormous tree

@hmaurer Do you know whats passed in _value in the reducer?

@karlstefan the value under children in the api payload

@karlstefan ah hang on, no, sorry

_value will be the full object

instead of mapping over _value, try to map over (:children _value)

as in

(fn [context args _value]
  (map (fn [val]
              (:body (client/request-backend (:rid val)))) (:children _value)))

It works!

I think with the previous (wrong) code your client/request-backend was being called with nil as argument

which blew everything up

yes

🎉

hehe

Thanks! 😄

you’re welcome

This is my first attempt at clojure, very excited!

It’s a fun language 🙂

So remember: resolves are always placed on fields, and they get passed the value of their containing object

(queries are fields on a root “Query” object)

(and mutations are fields on a root “Mutation” object)

i see, so args in args and their value in _value

Whats the context for then, if you dont mind me asking

@karlstefan passing down some stuff to all resolvers. For example, you might want to pass down a database connection, the authentication status, etc

@hmaurer I see 🙂

Where would I specify what to pass down?

when calling execute

http://lacinia.readthedocs.io/en/latest/overview.html#executing-queries

see, there they are passing two nil arguments

it’s one of them; I can’t remember which

ah, it’s the last one

> The two nils are variables to be used executing the query, and an application context.

e.g. (execute schema query nil {:answer 42})

and you would then be able to retrieve :answer in resolvers on the first argument

note that if you printed out the first argument you would see a lot more than :answer

that’s because Lacinia uses the context for its own bookkeeping

you don’t need to care about that for now, but it does contain some useful stuff for more advanced use-cases

I'll read up in the docs! 🙂 Thanks again for your time!