Add support for Aggregate strategies

[ivarconr]

After using unleash for a while we see that we now have a lot of "aggregate strategies" implemented, such as "usersWithIdAndBetaUsers" etc.

Instead of having all different combinations of strategies implemented in all clients we could provide a way to define aggregated strategies. This way we only need the simple strategies implemented in each client.

[ivarconr]

The filter-pattern approach

A simple way to solve this is extend the current API with a strategies field. The current strategy and parameters field would be deprecated in favour of a new strategies array containing all strategies associated with a feature toggles. The idea is that any toggle can be associated with one or more strategies. If the toggle is enabled with any of the associated strategies it should be considered on.

The suggested solution allows us to keep strategies simple and at the same time add multiple strategies to any toggle without having to implement all possible combinations upfront in all clients.

Current format:

{
    "features": [
        {
            "name": "featureX",
            "description": "",
            "enabled": true,
            "strategy": "default",
            "parameters": {}
        },
        {
            "name": "featureY",
            "description": "",
            "enabled": true,
            "strategy": "ActiveForUserWithEmail",
            "parameters": {
                "emails": "[email protected]"
            }
        }
    ]
}

_New API_

{
    "version": 1,
    "features": [
        {
            "name": "featureX",
            "description": "",
            "enabled": true,
            "strategy": "default", //kept for backward compability
            "parameters": {}, //kept for backward compability
            "strategies": [
                {
                    "name": "some_strategy",
                    "parameters": {}
                }
            ]
        },
        {
            "name": "featureY",
            "description": "",
            "enabled": true,
            "strategy": "default",
            "parameters": {},
            "strategies": [
                {
                    "name": "some_strategy",
                    "parameters": {
                        "emails": "[email protected]"
                    }
                }
            ]
        }
    ]
}

[sveinelo]

+1

Could "strategy" be dropped from the new API?

[ivarconr]

yes. But that should be a two-step iteration:

• iteration 1: introduce new field, and deprecate old one.
• iteration 2: remove the old field (not backward compatible).

[ivarconr]

we have decided to move forward with multiple strategies. Based on real-world usage of Unleash we feel the need ability to add multiple activation strategies for a feature toggle. To make it simple to understand and easy to use (and based on what people actually have asked for) all strategies should be OR from the client perspective, meaning that if a feature toggle is considered active with one strategy it should be considered enabled.

TODO:

• Add support for the new format in API
  • migrations for the database to new schema (also copy strategy-config)
  • run a few test against real production-data to make sure the validations works
  • document the new db-schema
  • add mapping for legacyProperties to support old clients. We should just expose the first strategyConfig in the list of strategies for a toggle.
  • implement validations that user does not POST old props (strategy, parameters) and the new prop (strategies) at the same time.
  • clean up the api-tests.
  • document the new API-format
  • Add version property to the new API-format to ease deserialization in clients.
• Add support for multiple strategies in the Admin UI
• Add support for multiple strategies in the clients.
  • java-client (Aggregate Strategies: inital implementation unleash-client-java#28)
  • node-client (add eslint and fixes unleash-client-node#9)