You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently the subscription plugin is called with EventMeta object only, but it does not know anything about the context, for example who or what triggered the event.
Describe the solution you'd like
It would be nice addition, if plugin.publish call would include the context.jwt as well. This way it would be possible to know who initiated the event, and build extra logic on top of that.
Describe alternatives you've considered
We could use this approach basically for Change Data Capture. While there's multiple ways to do it, the current interface provides nice and easy way to do this. If it had just a bit more information, that would open whole new possibilities.
Additional context
I can see publishEventsToPlugin is already called with some of the context information. Without too much analysing, it seems it would be straight forward to pass the whole context to this method, and even the whole context to the plugin, or at least parts of it.
While this is subscription plugin logic, it actually sounds to me it's actually more generic event logic, which can then be used to add subscriptions to the GraphQL API. In that sense, I might even make cleaner separation between the events and subscriptions. It might also be relevant to enable this type of event logic, without enabling subscriptions.
The text was updated successfully, but these errors were encountered:
Hi @Hellenic
We could indeed pass the whole context, but it would help to have an idea of the use case for which you need this to make sure we can solve the problem.
I would avoid exposing the whole context, as it is not considered part of the API, and relying on it may lead to brittle plugins if we change the context outside of a major release.
I must mention that, with the upcoming change data capture, the subscriptions will probably be revamped to make use of it, and the whole plugin won't really make much sense. I'm asking about your use case, because it may shed light on wether or not we may decide to scratch the plugin system altogether.
If the plugin would have the JWT data, we could pass id, email, or similar with the event. This would allow us to know who triggered the event, then we could for example create a notification to the user such as "this node was updated by X"
Is your feature request related to a problem? Please describe.
Currently the subscription plugin is called with
EventMeta
object only, but it does not know anything about the context, for example who or what triggered the event.Describe the solution you'd like
It would be nice addition, if
plugin.publish
call would include thecontext.jwt
as well. This way it would be possible to know who initiated the event, and build extra logic on top of that.Describe alternatives you've considered
We could use this approach basically for Change Data Capture. While there's multiple ways to do it, the current interface provides nice and easy way to do this. If it had just a bit more information, that would open whole new possibilities.
Additional context
I can see
publishEventsToPlugin
is already called with some of thecontext
information. Without too much analysing, it seems it would be straight forward to pass the whole context to this method, and even the whole context to the plugin, or at least parts of it.While this is subscription plugin logic, it actually sounds to me it's actually more generic event logic, which can then be used to add subscriptions to the GraphQL API. In that sense, I might even make cleaner separation between the events and subscriptions. It might also be relevant to enable this type of event logic, without enabling subscriptions.
The text was updated successfully, but these errors were encountered: