Right now there is a lot of boilerplate code in order to support both queries and subscriptions
as well as async and sync transports. Also the context switch api leads to unnecessary confusion and
unpredictable results (when using rath from sync or async context but with sync and async links).
Solution
As async libraries are maturing I feel that there is not really a necessity to have support for both async and
sync transports beyond wrapping a sync transport like requests behind a thread pool executor. Also this is already
the scope of projects like gql.
Queries, Mutations and Subscriptions do not need to be seperated in their processing through the links and could be united
under a stream like interface, and links just operate on setting up and modifying elements of that stream.
Links would then only have to implement one function async interator, which would allow to use more functional patterns e.g. using
a function as a link.
Only the rath client should provide the interface for differentiating between a one time query or a subscription with multiple event,
only here would the koil support for sync actions be happening.
Problem
Right now there is a lot of boilerplate code in order to support both queries and subscriptions as well as async and sync transports. Also the context switch api leads to unnecessary confusion and unpredictable results (when using rath from sync or async context but with sync and async links).
Solution
As async libraries are maturing I feel that there is not really a necessity to have support for both async and sync transports beyond wrapping a sync transport like requests behind a thread pool executor. Also this is already the scope of projects like gql.
Queries, Mutations and Subscriptions do not need to be seperated in their processing through the links and could be united under a stream like interface, and links just operate on setting up and modifying elements of that stream.
Links would then only have to implement one function async interator, which would allow to use more functional patterns e.g. using a function as a link.
Only the rath client should provide the interface for differentiating between a one time query or a subscription with multiple event, only here would the koil support for sync actions be happening.
Implementation
9 is providing my take on this approach.