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
{{ message }}
This repository was archived by the owner on Nov 25, 2022. It is now read-only.
The policy pattern is a behavioural software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, the code receives run-time instructions as to which in a family of algorithms to use.
We follow the policy pattern for selecting our rotation strategies on runtime. However, SMR does not follow this pattern and the rotation context itself could use some improvements to follow the standard approach.
This ticket is for improving our policy pattern and refactoring our SMR logic to conform to our policy pattern. This in turn will get rid of our extra endpoint tribes/id:smr as we will be able to invoke SMR using the tribes/id:rotate endpoint.
The policy pattern is a behavioural software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, the code receives run-time instructions as to which in a family of algorithms to use.
We follow the policy pattern for selecting our rotation strategies on runtime. However, SMR does not follow this pattern and the rotation context itself could use some improvements to follow the standard approach.
See: https://refactoring.guru/design-patterns/strategy
This ticket is for improving our policy pattern and refactoring our SMR logic to conform to our policy pattern. This in turn will get rid of our extra endpoint
tribes/id:smras we will be able to invoke SMR using thetribes/id:rotateendpoint.