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
dataSourcesto 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
SubscriptionServeras 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-corerequest 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
initializeon the DataSource instances, which might be problematic for some classes of DataSource.initialize, but with an undefinedcacheproperty, which is problematic (more following)createDataSourcesfunction, so unsure whether it callsinitializemethods with a cache.My impression is that the
cacheproperty onDataSourceConfigis the way multiple DataSource instances are intended to share state. For example, the one Apollo-supported DataSource, RESTDataSource, uses thecacheas the backing store for its HTTP request/response cache (it namespaces its entries with the prefixhttpcache:). When initialized withcache: undefined,RESTDataSourceinstances will all use instance-specificInMemoryLRUCaches. 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
cacheto the Apollo Server config (which the framework then initializes query + mutation datasources with), and also pass that same object to the manualinitializeDataSource 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