Migration v4 - context & DataSource

[RemyMachado]

With v3, I could access any dataSource inside any other dataSource through the context.

v3 DOC: Apollo Server invokes the dataSource.initialize({ cache, context }) function on each new DataSource

It allowed me to do the following:

    // for any DataSource (e.g. Posts)

    async retrieveBearerUser() {
        return this.context.dataSources.users // using users DataSource here
            .findOneById(this.context.userJwtPayload?.subject)
    }

But now that the dataSources are computed at the same time as the other fields of the context, I don't know how to replicate this behavior.

I had a context looking like a loop thanks to the previous initialization process:

dataSources = {
     posts: {
         context: {
             dataSources: {
                 posts: ... // and so on
             }
         }
    }
}

It may have been an unintended behavior, so how can I still retrieve the user from another dataSource with the new context implementation?

Any help would be greatly appreciated.

[glasser]

There's an example of how to do this in the migration guide, specifically under "If you want to access your entire context's value within your DataSource". (It takes advantage of the fact that you can access this inside a class's constructor even before the class is fully constructed.)

On the other hand, if there's only one thing like this that you want to pull off the context (eg userJwtPayload), another alternative would be to not pass the entire context into your class and instead just pass the userJwtPayload itself in, which removes the circular dependency (and also means that when writing tests for your data source class you don't have to mock out the entire context object!).

[glasser]

We found that in practice, Apollo Server's feature of letting you construct the "dataSources" subfield of your context object in a separate function from the construction of the rest of the context led to a lot of confusion:

• It was not obvious that the dataSources function was called once per request rather than once at startup
• It meant that the data type returned from the context function was not actually the type of your context object

We felt that making data sources less magical and just normal objects that take their dependencies as constructor arguments was an easier to understand approach. This does mean that if you want a circular reference between your entire context object and one particular field on it (a data source), you have to do a tad more work instead of letting Apollo Server sneakily set it up behind your back — but circular references are subtle enough that it's maybe not a bad thing that you have to do it yourself!

[simplecommerce]

Am I correct in assuming that the reason the context object in my middleware is not a reference to the same class instance in my datasources are a result of me using graphql-middleware library and not something underlying with @apollo/server's code?

I am still waiting on feedback on their end.

[trevor-scheer]

@simplecommerce we actually do a shallow clone of the context object returned by your context function. If you depend on referential identity you can nest the shared bits of context into an object within your context object. This is understandably an unobvious gotcha.

For some more context:

apollo-server/packages/server/src/ApolloServer.ts

Lines 1261 to 1276 in d7e9b97

	// We clone the context because there are some assumptions that every operation
	// execution has a brand new context object; specifically, in order to implement
	// willResolveField we put a Symbol on the context that is specific to a particular
	// request pipeline execution. We could avoid this if we had a better way of
	// instrumenting execution.
	//
	// We don't want to do a deep clone here, because one of the main advantages of
	// using batched HTTP requests is to share context across operations for a
	// single request.
	//
	// The typecast here is safe, because the only way `contextValue` can be
	// null-ish is if we used the `contextValue?: BaseContext` override, in
	// which case TContext is BaseContext and {} is ok. (This does depend on
	// the fact we've hackily forced the class to be contravariant in
	// TContext.)
	contextValue: cloneObject(options?.contextValue ?? ({} as TContext)),

[simplecommerce]

@simplecommerce we actually do a shallow clone of the context object returned by your context function. If you depend on referential identity you can nest the shared bits of context into an object within your context object. This is understandably an unobvious gotcha.

Ahh ok I kind of understand, if you can could you write me an example it doesn't have to be complex just so I know how to proceed if I want to adapt this on my project?

Thanks for the help I appreciate it!

UPDATE: ok I get what you mean now, I just tested it and confirm it does work as you mentioned. Thanks again!!

[trevor-scheer]

Glad that helped, and thanks for the update!