hello, I think you can make it work with some aliases, just keep the two resolvers you mentioned first, and add:

[(pc/alias-resolver ::api/input ::aaa/input)
 (pc/alias-resolver ::api/input ::bbb/input)
 (pc/alias-resolver ::aaa/output ::api/output)
 (pc/alias-resolver ::bbb/output ::api/output)]

Aren't aliases for the case when the 2 sides of it look the same? In my case there have to be mappings.

It works fine when I only have the ::aaa/output -> ::api/output resolver but when I add the ::bbb/output -> ::api/output one I'm no longer getting the aaa case resolved

It might be something with how my parser is set up

ah, you right

for the input you should do a routing like you mentioned

and for output you can use alias

complete example:

; A adds 10
(pc/defresolver a-output [{:keys [a/input]}]
  {:a/output (+ input 10)})

; B multiplies by 2
(pc/defresolver b-output [{:keys [b/input]}]
  {:b/output (* input 2)})

; lets give evens to A, odds to B
(pc/defresolver input-selector [{:keys [api/input]}]
  {::pc/output [:a/input :b/input]}
  (if (even? input)
    {:a/input input}
    {:b/input input}))

(def register
  [a-output
   b-output
   input-selector
   (pc/alias-resolver :a/output :api/output)
   (pc/alias-resolver :b/output :api/output)])

(def parser
  (p/parser
    {::p/env     {::p/reader               [p/map-reader
                                            pc/reader2
                                            pc/open-ident-reader
                                            p/env-placeholder-reader]
                  ::p/placeholder-prefixes #{">"}}
     ::p/mutate  pc/mutate
     ::p/plugins [(pc/connect-plugin {::pc/register register})
                  p/error-handler-plugin
                  p/request-cache-plugin
                  p/trace-plugin]}))

(comment
  (parser {} [{[:api/input 16] [:api/output]}]) ; => 26
  (parser {} [{[:api/input 17] [:api/output]}]) ; => 34
  )

Thank you kindly. It is certainly something with my parser setup then, as the above example does not work with it but it does in your code

@U08BJGV6E you can also use another helper if you need a custom output mapping instead of 1-to-1 https://blog.wsscode.com/pathom/v2/pathom/2.2.0/connect/resolvers.html#_single_attribute_resolvers or just make everything explicit https://nextjournal.com/a/9KJX2jnmNJBppKKFXHu3mb/edit?token=A7nh9jzVddEhHZTjGinr3Khttps://nextjournal.com/a/9KJX2jnmNJBppKKFXHu3mb/edit?token=A7nh9jzVddEhHZTjGinr3K

Thank you. Cannot access your second link there, perhaps you sent me the wrong one

ah, sorry, right https://nextjournal.com/a/9KJX2jnmNJBppKKFXHu3mb

Thank you very much.

Running my resolvers with these parsers works, so I'll need to dig into that. We're using the parallel parser but I haven't familiarized myself with its configuration yet, but it seems the problem lies there somewhere.

i've had some weird problems with parallel parser, which made me to switch to a regular one; those were hardly reproducible though so I doubt that's it for one thing you can check whether you have pc/open-ident-reader included

::p/reader [p/map-reader
             pc/reader3
             pc/open-join-context-reader
             pc/open-ident-reader
             p/env-placeholder-reader]

looks like I do

ah, reader3 is experimental, it doesn't work as expected in this case

Well, drat. I'll need to look into why we started using it then 😄

@U08BJGV6E parallel parser has its quirks, and maybe its a bug related to that, in the reality of Pathom 2 parallel parser is that the overhead it adds is just too high for most applications

unless you have a really big amount of parallelizable things (and are willing to pay some premium on the servers), its usually more efficient (in speed and cost) to stay with reader2

and about reader3, yeah, that's was an experiment and it is outdate in Pathom 2 (it was the bases for Pathom 3, but in Pathom 3 it evolved a lot since)

Thank you. I'll check back in the history why we use reader3 but it being outdated is a definite warning sign.

WRT parallel, what do you mean by really big amount? In this current case I'm working on there are some library calls that take a significant amount of time and we would prefer to parallelize calls to them.

I suggest you do a few comparisons and check the final time

if they are close, stick to serial, since its also easier to debug

Thank you

@U08BJGV6E JFYI there’s also async-parser, which allows to return core.async channels and has lower overhead than parallel-parser IIRC

Thank you, I'm actually experimenting with that 🙂

Thanks you for your help so far. Mind if I ask what is the recommended reader to be used with async-parser? (and parallel-parser for that matter) I've just been getting into pathom lately

Let me rephrase a bit: if I use the async-parser, should is my best choice of reader the async-reader2?

yes, async-reader2 with async parser