@wilkerlucio is it a "undefined" behavior? If there is 2 resolvers to resolve :a, one is "global", the other need a input :i The pc/reader3 will prefer "the first one", where "the first one" is "the first inserted in the index" (aka the register order matters, with I think is bad) Sample case

(let [register [(pc/resolver
                  `user-name-by-id
                  {::pc/input  #{:user/id}
                   ::pc/output [:user/name]}
                  (fn [_ {:user/keys [id]}]
                    {:user/name (str "user-" id)}))
                (pc/resolver
                  `current-user-name
                  {::pc/output [:user/name]}
                  (fn [_ _]
                    {:user/name "current"}))]
      parser-1 (p/parser {::p/plugins [(pc/connect-plugin {::pc/register register})]})
      parser-2 (p/parser {::p/plugins [(pc/connect-plugin {::pc/register (reverse register)})]})
      env {::p/reader               [p/map-reader
                                     pc/reader3
                                     pc/open-ident-reader
                                     p/env-placeholder-reader]
           ::p/placeholder-prefixes #{">"}}]
  {:parser-1 (get (parser-1 env [{[:user/id 1] [:user/name]}]) 
                  [:user/id 1])
   :parser-2 (get (parser-2 env [{[:user/id 1] [:user/name]}])
                  [:user/id 1])})
=> {:parser-1 {:user/name "user-1"}, :parser-2 {:user/name "current"}}

I've never used Pathom before but it seems like a natural fit for my usecases to access a bunch of data in ElasticSearch. One of usecases is to serve autocomplete in the UI. I don't see any reason NOT to use Pathom for this usecase (except, possibly, performance). Am I wrong?

@markaddleman in the end pathom is just a glue to compose information across your system, I have used pathom with ES before, don't see any reason not to 🙂