subscriptions handled by graphql-core #2701
Replies: 1 comment 1 reply
-
Personally I didn't follow that issue too much but it has been discussed some times. Here is some context I remember from the top of my head: There was some confusion in the past about how some of our extension hooks would work with subscriptions. That's because Strawberry had little subscription support when extensions were added. Not sure whether this confusion has been fully resolved yet. However, there is a PR which adds extension support to subscriptions #2430. Originally it stalled for a bit since it changes 50+ files and was based on another PR. That other PR has been merged since then, so I'll take another look as soon as I find time. |
Beta Was this translation helpful? Give feedback.
-
I noticed that in
strawberry.schema.schema
,execute()
is imported fromstrawberry.schema.execute
whereassubscribe()
comes directly from graphql core.strawberry
execute()
does various things, including running extensions, and returns astrawberry.types.ExecutionResult
whereas the other does no strawberry things and returnsgraphql.ExecutionResult
.What are we missing out by this? What does
strawberry.schema.execute.execute
add on top ofgraphql.execute()
?The reason I ask is among other things that it causes a certain disparity between multi- and single-results operations over websockets.
Indeed, there is a "TODO" in the schema, indicating that "extensions" will at some point be supported. Is that all that strawberry adds on top, these extensions? Should we add a similar strawberry wrapping for "subscribe()?"
Beta Was this translation helpful? Give feedback.
All reactions