apollo-server: Datasources missing in the context when using subscriptions
Intended outcome: Context in the resolver functions will contain dataSources
field when using subscriptions just like when calling with queries.
Actual outcome: Field dataSources
is missing while using subscriptions in the context (in subscribe
and resolve
functions). The context contains everything except this one field.
How to reproduce the issue:
- set
dataSources
to the server
const server = new ApolloServer({
schema: Schema,
dataSources: () => createDataSources(),
// ...
})
- dump content of the context:
subscribe: (parent, args, context) => {
console.warn(context); // dataSources missing, every other field is there correctly
})
I think this is quite serious because otherwise, I cannot query my data sources at all while using subscriptions.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 23 (4 by maintainers)
Unfortunately, this is a known issue. Although we run
SubscriptionServer
as part ofApolloServer
, the request pipeline is completely separate. That means features like persisted queries, data sources, and tracing don’t currently work with subscriptions (or queries and mutations over the WebSocket transport).There is work underway on a refactoring of the
apollo-server-core
request pipeline that will make it transport independent, and that will allow us to build the WebSocket transport on top of it. Until then, I’m afraid there isn’t much we can do.I solved this by using @PatrickStrz method with some little tweak to have each Datasource instance to have the full context, Same way apollo server initializes its Datasources
Hope this helps 😃
@jbaxleyiii so why is this ticket closed? Is 3.0 out?
Just worth noting that the subscriptions integration in Apollo Server has always been incredibly superficial, and we are planning to remove it in Apollo Server 3 (replacing it with instructions on how to use a more maintained subscriptions package alongside Apollo Server). We do hope to have a more deeply integrated subscriptions implementation at some point but the current version promises more than it delivers, as this and many other issues indicate.
I solved this by using @BrockReece’s method but initializing DataSource classes manually:
Hope this helps 😃
Any update on this?
any update on this?
It’s 2020 now… Any update on this?
Hi, did anyone come up with a solution to this?
I am currently adding my dataSources to both the dataSource and context methods, but this feels kind of icky…
any update on this?
Any update? Can’t use data sources as newing one up leaves it uninitialised…
For future visitors, here’s an example implementation using Apollo Server 3 (apollo-server-express 3.9), WebSocketServer from ‘ws’, and useServer from ‘graphql-ws’, including authorization.
Just want to note/summarize that
initialize
on the DataSource instances, which might be problematic for some classes of DataSource.initialize
, but with an undefinedcache
property, which is problematic (more following)createDataSources
function, so unsure whether it callsinitialize
methods with a cache.My impression is that the
cache
property onDataSourceConfig
is the way multiple DataSource instances are intended to share state. For example, the one Apollo-supported DataSource, RESTDataSource, uses thecache
as the backing store for its HTTP request/response cache (it namespaces its entries with the prefixhttpcache:
). When initialized withcache: undefined
,RESTDataSource
instances will all use instance-specificInMemoryLRUCache
s. Since you typically instantiate new instances for every GraphQL operation, that means multiple operations don’t share a cache. That might not be what you want.I suspect most people will instead want to explicitly pass a
cache
to the Apollo Server config (which the framework then initializes query + mutation datasources with), and also pass that same object to the manualinitialize
DataSource calls done for subscriptions. Then every operation the server handles, including subscriptions, uses the same cache.For reference, the default is (src) a
new InMemoryLRUCache()
from apollo-server-caching.@josedache Awesome, works like a charm! Thank you!
We can follow the 3.0 Roadmap, which includes “Unify diverging request pipelines”:
https://github.com/apollographql/apollo-server/issues/2360