Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2021-03-30

Channels

#pathom
<
2021-03-30
>
fjolne09:03:36

hi, i've been playing with p3 recently and found a weird behaviour on nested inputs resolvers: they mess up indicies in some way, both not working by themselves and making other resolvers invisible. here's a repro: http://nextjournal.com/fjolne/pathom3-nested-input-issue

fjolne09:03:14

i tried looking through pathom viz snapshots, but the logs did't make much sense: some existing relationships are marked as unreachable when I add nested inputs resolver

roklenarcic10:03:46

Has anyone tried to expose a bunch of resolvers as a GraphQL interface? I see examples where GraphQL is called by pathom, but never the other way around… It could be useful when you need to expose it to other frameworks/languages

jmayaalv10:03:36

@U66G3SGP5 For pathom2 there is https://github.com/denisidoro/graffiti for pathom3 there is still nothing available yet, there is an open discussion with ideas to achieve something similar https://github.com/wilkerlucio/pathom3/discussions/18

roklenarcic12:03:45

Interesting… thanks

wilkerlucio20:03:42

awesome, thanks, I'll have a look as soon as possible

dehli20:03:34

is there anything special needed to get batch resolvers working with the parallel parser in pathom2? i’m running into some issues when i follow the docs here: https://blog.wsscode.com/pathom/v2/pathom/2.2.0/connect/resolvers.html#_n1_queries_and_batch_resolvers.

wilkerlucio20:03:38

nothing special about parallel parser there, what issue you are facing?

dehli21:03:59

Hmmm, I’ll keep digging. A query i have that normally takes ~20s (without batch) ends up having a lot of Insufficient resolver output in the response. The basic resolver shape looks like this (which works when I have batch? false ) 

(if (sequential? input#)
  (->> input#
       (mapv get-fn#)
       promesa.core/all
       cljs.core.async.interop/<p!
       (mapv out-fn#))

  (->> (get-fn# input#)
       cljs.core.async.interop/<p!
       out-fn#))

wilkerlucio21:03:34

note this may be an error in your batch output

wilkerlucio21:03:54

it must match exactly the input in number of items and order, otherwise you will have broken results

dehli21:03:18

thanks! that’s a helpful tip!

dehli12:03:23

After digging into this more it seems to be due to there being two resolvers that can get to the same key. With batch it keeps spitting out insufficient resolver output (referencing the resolver that shouldn’t be used) and without batch, pathom can appropriately get to the right resolver.

dehli12:03:17

what’s strange is my basic query is below. The first one appropriately returns :user/id however the second one has the insufficient resolver output which must be for :user.session/started-at since it takes as input :session/id and :user/id. 

;; Works with batch and non-batch
[{[:user/id "foo"]
  [{:user/staff 
    [:user/id]}]}]

;; Doesn't work with batch, works with non-batch
[{[:user/id "foo"]
  [{:user/staff 
    [:user/id
     {(:>/session {:session/id "bar"})
      [:user.session/started-at]}]}]}]