It's common for clients to make the same EQL requests. Pathom can leverage this and
persist the planning part of the process across requests. This is how we set it up:
; create a var to store the cache
(defonce plan-cache* (atom {}))
(def env
; persistent plan cache
(-> {::pcp/plan-cache* plan-cache*}
(pci/register
[ip->lat-long
latlong->woeid
woeid->temperature])))
Check the Cache page for more details on how to control the cache.
; write-meta is required if you wanna see execution stats on Pathom Viz
:transform t/write-meta}}))
(def app
(-> handler
(middleware/wrap-format muuntaja-options)))
The :transform t/write-meta will make transit encode also the meta-data. This means the
running status data will flow. It allows Pathom Viz to show debug information.
Keep in mind the "run status" data is usually much larger than the response itself.
You can mitigate this in two different levels at Pathom:
Set :com.wsscode.pathom3.connect.runner/omit-run-stats-resolver-io? true to remove input/output details. This adds a great reduction in the size of the status.
Set :com.wsscode.pathom3.connect.runner/omit-run-stats? true to remove all status from meta
tip
This same handler setup works with any other ring server, like Pedestal,
http-kit, Compojure,
etc...
The boundary interface isn't required, but it gives the clients extra capabilities like allowing the user to provide root data.
Now to hook that, we need to create a Java file in our sources that will link our handler:
importnl.epij.gcf.RingHttpFunction;
publicclassPathomServerextendsRingHttpFunction{
publicStringgetHandler(){
return"com.wsscode.pathom-server/app";
}
}
After this part, we can test our server locally:
PORT=13337 clojure -X:run
Once it runs, we can test it by sending a request:
curl --location --request POST 'http://localhost:13337' \
I used EDN fore readability, but you should use application/transit+json (with transit data) for performance
and to support the custom handlers for resolvers and mutations.