Absinthe.Subscription.publish performance

Hi @aloukissas publish is indeed expensive by design, it is not instant like broadcast. Unlike broadcast which merely needs to send a message to various processes, Absinthe needs to execute the documents associated with a topic before it can send results to end users. So some process somewhere needs to bear the cost of performing this execution.

By default, that is the process that triggers the publish call, generally a mutation. This operates as a form of back pressure, where load incurred by an operation on the system is felt by the request that triggers that load.

@aloukissas not sure if this is applicable in your case, or you can make it applicable, but I found a tremendous performance improvement after deduplication subscription resolvers Understanding Subscriptions — absinthe v1.11.0

Subscriptions by default are expensive because they have to be resolved in context of each connected user. You can pass a context to it and make it resolve only once.

That not always can be applied, obviously if different users should see different data it often can’t work.

No trigger just runs the publish call inside of middleware on the mutation same as calling publish. You can spawn a task and call publish inside the task, or (better) you could build like an oban job queue of publish calls perhaps. The main danger to just spawning tasks is that you overload and potentially even OOM the system if you have many subscribers and many mutations on those subscribers without any backpressure.