Hard to phrase this question well, but I’m looking more into lacinia-pedestal :async option. Looking at the pedestal docs, they have an example of an interceptor returning a channel like so:

(interceptors/defbefore takes-time
      [context]
      (let [channel (chan)]
        (go
         (let [result (lengthy-computation (:request context))
               new-context (assoc context :response (ring-resp/response result))]
           (>! channel new-context)))
        channel))

Looking at the lacinia-pedestal async-query-executor-handler

(def async-query-executor-handler
  (interceptor
    {:name ::async-query-executor
     :enter (fn [context]
              (let [ch (chan 1)
                    resolver-result (execute-query context)]
                (resolve/on-deliver! resolver-result
                                     (fn [result]
                                       (->> result
                                            (apply-result-to-context context)
                                            (put! ch))))
                ch))}))

I’m thinking one could also run the execute-query in a thread instead, as long as the result gets written to the channel eventually

lacinia doesn't use core.async at all, what you are looking at is basically the adapter between lacinia and core.async because pedestal uses core.async

all code is run in a thread, so I am not sure what your final question is

lacinia queries always execute asynchronously, that is way execute-query returns a promise that is fulfilled later

> Lacinia queries always execute asynchronously This answers my question

thank you

in the pedestal example their code is running inside some async process. I wasn’t sure what execute-query was doing here.

There is a library (maybe lacinia) that turns graphql queries in "clojure data"? Turn user { id name } in something like {:type :user :elements [:id :name]}