|
| 1 | +--- |
| 2 | +layout: default |
| 3 | +title: Peers |
| 4 | +nav_order: 2 |
| 5 | +--- |
| 6 | + |
| 7 | +<!-- prettier-ignore-start --> |
| 8 | +# Peers |
| 9 | +{: .no_toc } |
| 10 | +<!-- prettier-ignore-end --> |
| 11 | + |
| 12 | +<!-- prettier-ignore --> |
| 13 | +- TOC |
| 14 | +{: toc} |
| 15 | + |
| 16 | +## CAP Extensibility Feature Toggles |
| 17 | + |
| 18 | +Reference documentation: |
| 19 | +[https://cap.cloud.sap/docs/guides/extensibility/feature-toggles](https://cap.cloud.sap/docs/guides/extensibility/feature-toggles) |
| 20 | + |
| 21 | +In CAP, the features to be toggled are _pre-built extensions_ of CDS models. These extensions are either active or |
| 22 | +inactive, i.e., boolean in nature. They are dynamic in the sense that they can be active for one request and inactive |
| 23 | +for another based on the requesting user or tenant. However, their state never changes within the handling of a |
| 24 | +request. |
| 25 | + |
| 26 | +Our library supports these types of toggles, by acting as a _Feature Vector Provider_ for CDS, when the library is used |
| 27 | +as a CDS-plugin. For details see: [Feature Vector Provider]({{ site.baseurl }}/plugin/#feature-vector-provider). |
| 28 | + |
| 29 | +## SAP Feature Flags Service |
| 30 | + |
| 31 | +Reference documentation: |
| 32 | +[https://help.sap.com/docs/feature-flags-service](https://help.sap.com/docs/feature-flags-service) |
| 33 | + |
| 34 | +This SAP BTP service is designed to assist applications with microservice or multi-component architecture in harmonizing |
| 35 | +and managing their feature delivery and runtime state. To accomplish this, it provides a service instance with |
| 36 | +centralized state that can be queried with a web API or accessed via a dashboard to alter feature states. |
| 37 | + |
| 38 | +We believe this approach works well in practice for many applications. However, our library follows a somewhat different |
| 39 | +philosophy for feature toggle management: |
| 40 | + |
| 41 | +- We don't have a dashboard to get an overview of the active feature states in applications with multiple parts. |
| 42 | +- We don't have any rollout concepts, like gradual rollout or similar. Our library is client-side, hence decentralized, |
| 43 | + and it has no holistic view of how many servers or end-users use it. |
| 44 | +- We encourage that the feature configuration is part of the application source code, in human-readable yaml form, in |
| 45 | + order to keep the code in sync with the respective features. |
| 46 | +- We use redis for state persistence and this allows us to use a sub/pub pattern to keep the local state of many |
| 47 | + application instances in sync without polling. |
| 48 | +- We focus on input validation and allow flexible, expressive toggle states of different types. |
| 49 | + |
| 50 | +We could imagine supporting the service as an alternative to redis and our source-versioned configuration files at |
| 51 | +some point. The service does not come with an associated client library, so there are natural synergies where our |
| 52 | +library can help in terms of caching and local state management. |
0 commit comments