Clojurians Log v2
graphql
I just went through an exercise at work where we needed to extend our server to expose a second schema, second graphiql, at new paths. It was tedious and underlined how the supposedly helpful setup code in com.walmartlabs.lacinia.pedestal has succumbed to unnecessary complexity; I've created a new PR to add a pedestal2 namespace that decomplects it.
Essentially, the new namespace provides a simpler default-service function, but you are encouraged to just build your own, from the same building blocks, if you need to do something more complicated.
Hey, do you recall that I asked a while back whether exceptions caught in lacinia could trigger error interceptors of pedestal? I was hacking a bit on lacinia.pedestal to make that work and I think I did. It can use some hammock time on my side, but are you interested in accepting it as a contribution down the line?
Here is a PR: https://github.com/walmartlabs/lacinia-pedestal/pull/101 . Let me know what you think and I can make changes accordingly
The main problem for me is the asynchronous query executor: Pedestal, for as much as I understand it, expects a channel with a context map. I, however, got an exception that I somehow want to bubble through the interceptors. Its not immediately obvious to me what I am supposed to do with an exception caught in an asynchronous pedestal interceptor. So thats currently unsolved
Besides that it was actually rather trivial, just reraise the exceptions in the query executor interceptor and add a last ditch error interceptor that if an exception goes unhandled, just puts an error message in the response. Anyhow, let me know if you are interested in pursuing this, if you do I’ll clean up my code and create a PR in the coming week 🙂!