How do I run context initialization for messages in subscriptions?

[oliversalzburg]

I'm using TypeGraphQL in a project with MikroORM. Just like in the example, I fork the EM in the context initialization. This works great for queries and mutations.

For subscriptions, this context initialization is not performed (especially not since apollo-server@3 removed build-in subscription support). You can initialize a context on the connection handler of the subscription server, but these are performed once on connection.

What is a good approach to fork the EM for every new message that is handled?

[jbmikk]

I am having exactly the same problem, I haven't found a solution yet, just a work around.

What I'm doing is clearing the identity map on each event. That way any queries to the database avoid the cache and I always get fresh data for each event.

this.em.clear();

Like you said, the entity manager is forked only once per connection, so each user connected gets its own EM instance for the duration of the connection. This is not ideal, since multiple notifications containing multiple asynchronous calls could overlap and the clear call from one message could affect the other.

This is the best I could do so far and is good enough for my particular use case. When that doesn't work anymore I'm going to have to avoid db calls and include the data in the message payloads themselves. Also not ideal for other reasons (large payloads).

Anyway, I think this issue might be an Apollo server problem itself, I'm not sure it can be fixed in type-graphql, can it?

[oliversalzburg]

First of all, this is not an Apollo issue, as subscriptions are even handled by Apollo anymore. But when Apollo did handle subscriptions, it did not support this scenario.

I actually have found a way to implement a satisfying solution in our stack, but it is extremely verbose. In the hope that it helps anyone, I'll share some details.

The key is to provide your own implementation for the subscription filter function. TypeGraphQL suggests to use withFilter, which can serve as a good starting point for your own implementation: https://github.com/apollographql/graphql-subscriptions/blob/master/src/with-filter.ts

This filter is invoked for every time an event is produced that would trigger subscriptions. So this is the ideal point to start processing of individual operation executions.

We have a lot of custom code around the subscription processing to make it work nicely with our tracing. I'm not sure if any other parts were relevant. Using the filter is key, I'm sure.

[jbmikk]

Thanks, that's a good idea. I'll try that.

Anyway, I know Apollo doesn't handle them anymore directly, but I'm still stuck on version 2.