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
The current subscription resolver design assumes that the channel name in the subscription resolver is hard coded as the subscription resolver lambda function takes no parameters thus it is not possible to bring information such as the subscription variables and connection context into the scope of the resolver.
I need the ability to have access to the subscription parameters in the subscription resolver lambda function to be able to dynamically determine the channel based on the subscription variables. All examples of subscritions assume a hard-coded channel name which limits one to have a design which assumes a one-to-one mapping between subscription name and channel name. In our case we have one subscription and need to route the user to the correct channel based on the subscription variables.
Without such capability our team will be forced to use another non-GraphQL pupsub implementation even though all the other communication in our application happens over GraphQL. I have logged this issue on various forums including previously on issue #1385, but it seems to attract no attention.
/label critical feature
The text was updated successfully, but these errors were encountered:
@serle we are planning on doing another large revision of subscriptions in the Apollo Server 3.0 (#2360) and have added this to our project to track it there!
The current subscription resolver design assumes that the channel name in the subscription resolver is hard coded as the subscription resolver lambda function takes no parameters thus it is not possible to bring information such as the subscription variables and connection context into the scope of the resolver.
I need the ability to have access to the subscription parameters in the subscription resolver lambda function to be able to dynamically determine the channel based on the subscription variables. All examples of subscritions assume a hard-coded channel name which limits one to have a design which assumes a one-to-one mapping between subscription name and channel name. In our case we have one subscription and need to route the user to the correct channel based on the subscription variables.
Without such capability our team will be forced to use another non-GraphQL pupsub implementation even though all the other communication in our application happens over GraphQL. I have logged this issue on various forums including previously on issue #1385, but it seems to attract no attention.
/label critical feature
The text was updated successfully, but these errors were encountered: