Closed henryw374 closed 2 years ago
I think this issue belongs in lacinia-pedestal?
But while it's here... A pre-hook would be useful too. For queries we get to use interceptors to do set up and tear down but with subscriptions we only have set-up and tear down per websocket connection. For use cases like per-query metrics, cache life cycles etc it would be useful to have pre and post query hooks.
Thanks
It seems to me, that this logic can live inside the streamer.
It is invoked at the correct time to set up your cache.
It provides a shutdown callback to clean things up when either side of the conversation shuts down. That's where you clear your cache.
Hi, thanks for picking this up.
Actually what we need here is query-scoped hooks. For example, we want a query run to have it's own (level 1) cache, to provide consistency for that query result, and after that query has run, flush results to a level 2 cache.
I have sketched an implementation.. What I've done so far would be a breaking change but it just illustrates what we need. If you're happy with the idea, I could keep working on it to make a PR.
I'm sorry this has dragged on so long, the ideas are fine, but it got ignored. Please re-open if this is still something that would be helpful. I would consider a more general system where callback functions could be registred with Lacinia to cover more of the lifecycle of queries and subscriptions.
Ok Thanks. I think we still have the copied-over-code-plus-hack doing its thing in our app.
I don't have the time or inclination work on anything more general atm.
Hi,
I need to run some code after the query has been executed in source-stream and I don't see any way of doing this in lacinia currently. In my case, a query-scoped, in-memory cache needs flushing.
As a workaround, I've copy/pasted the innards of the source-stream callback to my own code (so my code puts the result into response-data-ch) and I've added the hook I need after the query result is delivered.
Any thoughts?
Thanks, Henry