Adjust how subscription IDs are generated

[darrenclark]

First pass at the changes described in #652

If things look good, I'll go update all documentation, fix conflicts, etc.

I also need to add the blueprint to the resolution struct (#652 (comment))

---

Subscription IDs are now derived via a context_id option returned by a subscriptions config function, combined with the GraphQL document and any provided variables.

This gives library users more control over which subscription queries get merged.

If context_id is not provided, a unique integer is generated instead (to ensure we don't merge any queries by default).

• We could also do the :erlang.term_to_binary + SHA256 hash dance on the context by default instead. It should be safe to merge subscriptions whose context is the same.. Thoughts?

Additionally, if one wants to override the default behaviour of combining the GraphQL document & provided variables to determine the document_id, they can return a document_id from the subscription's config function

[arkgil]

@darrenclark Hi 👋

We could also do the :erlang.term_to_binary + SHA256 hash dance on the context by default instead. It should be safe to merge subscriptions whose context is the same.. Thoughts?

I'm wondering if you could simply rely on the :topic returned by the config function? I would expect that retuning the same topic would tap me into the same stream of events.

[benwilson512]

@arkgil It will. There's two things happening here, there's the topic id which is used to figure out what events should fire your subscription, and then there's a "document id" concept which is used to de-duplicate documents. Document deduplification is important because it wildly improves the scale at which subscriptions can operate. If you have 1000 people all viewing the front page of your news site for exampled, you'll have 1000 copies of the same subscription document all submitted. By deduplicating, we can run just 1 of those and then publish the results to everyone.

[arkgil]

@benwilson512 right, I am aware of it, I wasn’t really clear with my comment. What I meant is, with the approach presented in this PR Subscriptions attached to the same topic are duplicated by default, and context_id needs to be explicitly set if you want them deduplicated. I was wondering whether having them deduplicated given the same topic would make sense.

Or I’m just talking nonsense 😄 Anyway, thanks for clarification 🙂

[benwilson512]

@arkadiyk Imagine you have 10 documents submitted by 10 different users, each with the user set in the context. If you dedup only on the bodies, then any data loading that happens which takes into account the current user becomes horribly broken. Only the first document is run, which loads stuff that may be exclusive to just that user, and then it gets broadcasted to everyone.

[darrenclark]

Regarding the status of this PR: Been busy with other things, but hoping to loop back to this in the next week or two

[darrenclark]

@benwilson512 I (finally) got this updated, it's ready for review now.

I did not document (outside of the tests for it) the document_id option. Figured it'd be best, so as to avoid confusion. Thoughts? I figure if anyone goes looking for this functionality, they will end up digging into Absinthe's source code and discover it there.

@arkgil If you get a chance, can you let me know if this addresses #675

[benwilson512]

@darrenclark This is really fantastic, thank you!