You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For various reasons we run all our queries (and mutations) via WebSocket and found that all requests are handled sequentially in Absinthe.Phoenix.Channel. It would be great if we could execute queries asynchronously. As part of this we could also add some error handling for better stability, because when a query/mutation raises/throws an exception that is not caught in the resolver, the channel process simply dies. In the frontend we use apollo-socket-link which then rejoins the channel and restarts all pending queries/mutations (including the one that caused the exception). If the error persists, we end up in an infinite loop.
It spawns a monitored process for every single request. Requests that contain mutations are executed sequentially (i.e., we wait for the task to finish), other queries simply run in the background. Since the processes are not linked, the channel process does not die in case of an exception. But since it is monitored we can send a proper error reply (similar to what happens if a HTTP request dies due to an exception).
I would like to use this issue to discuss pros/cons of this approach and if/how this could be implemented as part of Absinthe.Phoenix.Channel.
The text was updated successfully, but these errors were encountered:
For various reasons we run all our queries (and mutations) via WebSocket and found that all requests are handled sequentially in
Absinthe.Phoenix.Channel
. It would be great if we could execute queries asynchronously. As part of this we could also add some error handling for better stability, because when a query/mutation raises/throws an exception that is not caught in the resolver, the channel process simply dies. In the frontend we use apollo-socket-link which then rejoins the channel and restarts all pending queries/mutations (including the one that caused the exception). If the error persists, we end up in an infinite loop.I have sketched out a proof of concept implementation here: https://gist.github.com/mpoeter/d18885caa3b46d47f031f6d913c93208
It spawns a monitored process for every single request. Requests that contain mutations are executed sequentially (i.e., we wait for the task to finish), other queries simply run in the background. Since the processes are not linked, the channel process does not die in case of an exception. But since it is monitored we can send a proper error reply (similar to what happens if a HTTP request dies due to an exception).
I would like to use this issue to discuss pros/cons of this approach and if/how this could be implemented as part of
Absinthe.Phoenix.Channel
.The text was updated successfully, but these errors were encountered: