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
GraphQL APIs have query,mutations which work with default request per time frame policies and subscriptions which work with websocket event per time frame policies. Currently we use same request based policies in API-M for both usecases. However, this is not ideal for websocket transport cases, since websocket request throttling is based on the # of active connections which backend can handle at a given time, # of events per time frame, max query complexity depth values etc. Since these parameters deviate from the REST API throttle policies, it is vital to introduce new throttle policy type for GraphQL APIs.
Describe your solution
How will you implement it
Optional Fields
Related Issues:
Suggested Labels:
Suggested Assignees:
The text was updated successfully, but these errors were encountered:
Describe your problem(s)
GraphQL APIs have query,mutations which work with default request per time frame policies and subscriptions which work with websocket event per time frame policies. Currently we use same request based policies in API-M for both usecases. However, this is not ideal for websocket transport cases, since websocket request throttling is based on the # of active connections which backend can handle at a given time, # of events per time frame, max query complexity depth values etc. Since these parameters deviate from the REST API throttle policies, it is vital to introduce new throttle policy type for GraphQL APIs.
Describe your solution
How will you implement it
Optional Fields
Related Issues:
Suggested Labels:
Suggested Assignees:
The text was updated successfully, but these errors were encountered: