graphql

orestis 2020-06-11T13:50:08.173800Z

Posted by accident to #pedestal — does anybody else have trouble with lacinia-pedestal 0.13.0 and :ide-connection-params ?

orestis 2020-06-11T13:57:52.174400Z

(->>
   (lacinia/graphiql-ide-response {:ide-path "/_graphiql"
                                   :ide-connection-params {:some "thing"}})
   :body
   (clojure.string/split-lines)
   (filter (fn [s] (re-find #"connectionParams" s))))

orestis 2020-06-11T13:58:10.174600Z

returns (" connectionParams: --NO-MATCH--")

orestis 2020-06-11T14:45:18.175300Z

Turns out it was a problem on my end — AOT compiled deps meant I had .class files from 0.12 that had a newer timestamp than the 0.13 jar.

orestis 2020-06-11T14:45:35.175700Z

So I was using the 0.13 graphiql.html file but the 0.12 interpolation 🙂

hlship 2020-06-11T16:11:48.176Z

Ouch! The merits of lein clean ...

hlship 2020-06-11T16:12:14.176400Z

Do you find that AOT compilation helps server startup enough to offset the problems it often causes?

hlship 2020-06-11T16:12:33.176700Z

We deploy as Uberjars but w/o AOT.

kwrooijen 2020-06-11T19:17:47.180800Z

Hi, does lacinia support qualified keyword fields? The spec only accepts simple-keywords. If I want to return my maps I need to transforms them to simple keywords. e.g. I have {:person/id 123 :person/name "foo"} . But before I return that, I have to transform it into {:id 123 :name "foo"} . Is there a easy way to handle this? It would be great if I could actually return qualified keywords to the frontend, but that's probably a limitation of graphql

kwrooijen 2020-06-12T08:32:47.181400Z

I'm wondering if there's a way to convert the map automatically to simple-keywords, since returning qualified-keywords doesn't seem like an option

2020-06-12T10:41:42.181600Z

Maybe this is what you are looking for: https://lacinia.readthedocs.io/en/latest/resolve/attach.html#resolver-factories

2020-06-12T10:42:57.181800Z

Bit hazy on the details tho

kwrooijen 2020-06-12T12:28:51.182Z

Thanks, I'll take a look at that

defa 2020-06-12T14:24:31.182200Z

Just an idea, haven’t tried that… when you create lacinia’s GraphQL schema, you attach you resolvers. There you could wrap all resolvers with a function that will handle the mapping. Here you have endless possibilities like, stripping the namespace part of all map keys that are keywords or use a map where you define these mappings (e.g. {:person/id :person :person/name :name})

defa 2020-06-12T14:26:24.182500Z

… or use GraphQL directives to specify this mapping in the schema. I did something like that for checking authorisation. If you are interested in details, I can put something together…

defa 2020-06-12T14:27:28.182700Z

are you using lacinia-pedestal? You might also put that into an interceptor.

defa 2020-06-12T14:32:46.182900Z

If GraphQL compatibility is not an issue you might look at https://github.com/wilkerlucio/pathom which gives you the full potential of EDN an thus namespaced keys.

2020-06-11T21:30:40.180900Z

Well; in the schema, how would that look?

2020-06-11T21:32:59.181100Z

I’m pretty sure that GraphQLs schema definition requires fields to be ‘the usual’ identifier shape (e.g. doesnt start with a number, and then lettters, numbers and underscores), so colons are probably out of the question 🙂