I notice that juniper_hyper::graphql takes the schema/rootnode argument as type Arc<RootNode<...>> but juniper_warp::make_graphql_filter only takes the schema as RootNode<...>.
This seems to make juniper_warp difficult to use in practice in the scenario of library integrations (e.g., a juniper-based GraphQL plugin for tauri).
In the example here this issue is side-stepped completely by creating a function schema() which returns a fresh RootNode instance.
In a library integration, however, you do not have access to the components necessary to construct a new RootNode.
It seems that juniper_warp should take the argument as an Arc<RootNode<...>> like juniper_hyper in order to avoid this problem.
I notice that
juniper_hyper::graphql
takes the schema/rootnode argument as typeArc<RootNode<...>>
butjuniper_warp::make_graphql_filter
only takes the schema asRootNode<...>
.This seems to make
juniper_warp
difficult to use in practice in the scenario of library integrations (e.g., a juniper-based GraphQL plugin for tauri).In the example here this issue is side-stepped completely by creating a function
schema()
which returns a freshRootNode
instance.In a library integration, however, you do not have access to the components necessary to construct a new
RootNode
.It seems that
juniper_warp
should take the argument as anArc<RootNode<...>>
likejuniper_hyper
in order to avoid this problem.Is there a reason why it is not defined this way?