Download the PHP package open-feature/sdk without Composer

OpenFeature PHP SDK

[OpenFeature](https://openfeature.dev) is an open specification that provides a vendor-agnostic, community-driven API for feature flagging that works with your favorite feature flag management tool. ## 🚀 Quick start ### Requirements This library targets PHP version 8.0 and newer. As long as you have any compatible version of PHP on your system you should be able to utilize the OpenFeature SDK. This package also has a `.tool-versions` file for use with PHP version managers like `asdf`. ### Install ### Usage #### Extended Example ## 🌟 Features | Status | Features | Description | | ------ | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | ✅ | [Providers](#providers) | Integrate with a commercial, open source, or in-house feature management tool. | | ✅ | [Targeting](#targeting) | Contextually-aware flag evaluation using [evaluation context](https://openfeature.dev/docs/reference/concepts/evaluation-context). | | ✅ | [Hooks](#hooks) | Add functionality to various stages of the flag evaluation life-cycle. | | ✅ | [Logging](#logging) | Integrate with popular logging packages. | | ✅ | [MultiProvider](#multiprovider) | Combine multiple providers with configurable evaluation strategies for fallback and aggregation. | | ❌ | [Named clients](#named-clients) | Utilize multiple providers in a single application. | | ⚠️ | [Eventing](#eventing) | React to state changes in the provider or flag management system. | | ❌ | [Shutdown](#shutdown) | Gracefully clean up a provider during application shutdown. | | ✅ | [Extending](#extending) | Extend OpenFeature with custom providers and hooks. | _{Implemented: ✅ | In-progress: ⚠️ | Not implemented yet: ❌} ### Providers [Providers](https://openfeature.dev/docs/reference/concepts/provider) are an abstraction between a flag management system and the OpenFeature SDK. Look [here](https://openfeature.dev/ecosystem?instant_search%5BrefinementList%5D%5Btype%5D%5B0%5D=Provider&instant_search%5BrefinementList%5D%5Btechnology%5D%5B0%5D=PHP) for a complete list of available providers. If the provider you're looking for hasn't been created yet, see the [develop a provider](#develop-a-provider) section to learn how to build it yourself. Once you've added a provider as a dependency, it can be registered with OpenFeature like this: #### MultiProvider The Multi-Provider allows you to use multiple underlying providers as sources of flag data for the OpenFeature SDK. When a flag is being evaluated, the Multi-Provider will consult each underlying provider it is managing in order to determine the final result. Different evaluation strategies can be defined to control which providers get evaluated and which result is used. The Multi-Provider is a powerful tool for performing migrations between flag providers, or combining multiple providers into a single feature flagging interface. For example: - **Migration**: When migrating between two providers, you can run both in parallel under a unified flagging interface. As flags are added to the new provider, the Multi-Provider will automatically find and return them, falling back to the old provider if the new provider does not have the flag. - **Multiple Data Sources**: The Multi-Provider allows you to seamlessly combine many sources of flagging data, such as environment variables, local files, database values, and SaaS-hosted feature management systems. - **High Availability**: Use multiple providers as redundant sources, automatically failing over when one provider is unavailable. **Basic Usage** The Multi-Provider is initialized with an array of providers it should evaluate: By default, the Multi-Provider will evaluate all underlying providers in order and return the **first successful result**. If a provider indicates it does not have a flag (`FLAG_NOT_FOUND` error code), then it will be skipped and the next provider will be evaluated. If any provider throws or returns an error result, the operation will fail and the error will be returned. If no provider returns a successful result, the operation will fail with a `FLAG_NOT_FOUND` error code. To change this behaviour, a different "strategy" can be provided: The Multi-Provider comes with three strategies out of the box: 1. **FirstMatchStrategy** (default): Evaluates all providers in order and returns the first successful result. Providers that indicate `FLAG_NOT_FOUND` error will be skipped and the next provider will be evaluated. Any other error will cause the operation to fail and the error to be returned. 2. **FirstSuccessfulStrategy**: Evaluates all providers in order and returns the first successful result. Any error will cause that provider to be skipped. If no successful result is returned, the set of errors will be returned. 3. **ComparisonStrategy**: Evaluates all providers at one time. If every provider returns a successful result with the same value, then that result is returned. Otherwise, an error is returned immediately if any provider errors. When values do not agree, an optional callback will be executed to notify you of the mismatch, and the configured "fallback provider" value will be used. This can be useful when migrating between providers that are expected to contain identical configuration. You can easily spot mismatches in configuration without affecting flag behaviour. **Provider Naming** Providers can be named explicitly or have names auto-generated: > **Note:** Provider names are **case-insensitive** and stored in lowercase. "MyProvider", "myprovider", and "MYPROVIDER" are all treated as the same provider name. Auto-generated names from provider metadata are also normalized to lowercase. **Strategies** ##### FirstMatchStrategy (Default) Evaluates providers sequentially and returns the **first successful result**. Continues to the next provider only if the current one throws a `FLAG_NOT_FOUND` error. **Use cases:** - Primary/fallback provider setup - Gradual migration between providers - Provider priority ordering **Behavior:** - **Remote** has the flag → returns Remote's value ✅ - **Remote** throws `FLAG_NOT_FOUND` → continues to **Cache** - **Remote** throws other error (e.g., network timeout) → stops and returns error ❌ - All providers throw `FLAG_NOT_FOUND` → returns default value with aggregated errors ##### FirstSuccessfulStrategy Evaluates providers sequentially and returns the **first successful result**, skipping providers that throw **any error** (not just `FLAG_NOT_FOUND`). **Use cases:** - High availability setups - Tolerating provider failures - Failover scenarios **Behavior:** - Evaluates providers in order until one succeeds - Ignores **all types of errors** from failing providers - Returns the first successful result - If all providers fail → returns default value with aggregated errors ##### ComparisonStrategy Evaluates **all providers** at one time. If every provider returns a successful result with the same value, then that result is returned. Otherwise, an error is returned immediately if any provider errors. When values do not agree, the configured "fallback provider" value will be used. This strategy accepts several arguments during initialization: The first argument is the "fallback provider" whose value to use in the event that providers do not agree. It should be the same object reference as one of the providers in the list. The second argument is a callback function that will be executed when a mismatch is detected. The callback will be passed an array containing the details of each provider's resolution, including the flag key, the value returned, and any errors that were thrown. **Use cases:** - A/B testing during provider migrations - Validating new provider implementations against trusted baselines - Detecting configuration drift across multiple sources - Ensuring provider consistency before committing to a new provider **Behavior:** - Evaluates **ALL providers** sequentially - **Fail-fast on errors:** If ANY provider returns an error, immediately returns all errors (no partial results) - **Compares values:** Uses strict equality (`===`) to check if all providers returned the same value - **On agreement:** If all providers succeed and all values match, returns the common value - **On mismatch:** If all succeed but values don't match, calls optional `onMismatch` callback, then returns the fallback provider's value - **Throws exception** if fallback provider not found in results **Important Notes:** - The fallback provider parameter is **required** (not optional) - Fallback provider must be included in the provider list - This is **not** a "highest value wins" strategy - it checks for exact equality - Fallback provider is only used for value mismatches, NOT for error recovery - Useful for ensuring consistency during migrations, not for aggregating different values **Strategy Comparison** | Scenario | FirstMatchStrategy | FirstSuccessfulStrategy | ComparisonStrategy | |----------|-------------------|------------------------|-------------------| | Provider order matters | ✅ Yes (stops at first match) | ✅ Yes (stops at first success) | ❌ No (evaluates all) | | Handles FLAG_NOT_FOUND | Continues to next | Continues to next | Returns all errors | | Handles other errors | Stops evaluation | Continues to next | Returns all errors immediately | | Evaluates all providers | ❌ No | ❌ No | ✅ Yes | | Best for fallback | ✅ | ✅ | ❌ | | Best for high availability | ❌ | ✅ | ❌ | | Best for consistency validation | ❌ | ❌ | ✅ | | Requires fallback provider | ❌ Optional | ❌ Optional | ✅ Required | **Error Handling** Error handling varies by strategy: **FirstMatchStrategy:** - Continues evaluation when providers throw `FLAG_NOT_FOUND` - Stops and returns error if provider throws other errors - Aggregates `FLAG_NOT_FOUND` errors if all providers fail **FirstSuccessfulStrategy:** - Continues evaluation when providers throw any error - Returns first successful result, ignoring all previous errors - Aggregates all errors if all providers fail **ComparisonStrategy:** - **Fail-fast:** Returns all errors immediately if ANY provider errors - Fallback provider only used for value mismatches (not error recovery) - All providers are evaluated (no short-circuiting on mismatches) - On value mismatch: Invokes `onMismatch` callback, then returns fallback provider's value (not an error) **Error Aggregation:** When all providers fail, MultiProvider aggregates individual provider errors into a single detailed error message: This detailed error aggregation helps with debugging by showing exactly which provider failed and why, similar to JavaScript's `AggregateError`. **Complete Example** **Custom Strategies** It is also possible to implement your own strategy if the above options do not fit your use case. To do so, create a class which extends `BaseEvaluationStrategy`: The `$runMode` property determines whether the list of providers will be evaluated sequentially or at once (using `RunMode::EVALUATE_ALL`). The `shouldEvaluateThisProvider()` method is called just before a provider is evaluated by the Multi-Provider. If the function returns false, then the provider will be skipped instead of being evaluated. The `shouldEvaluateNextProvider()` method is called after a provider is evaluated in sequential mode. If it returns true, the next provider in the sequence will be called, otherwise no more providers will be evaluated. This method is not called when `$runMode` is `RunMode::EVALUATE_ALL`. The `determineFinalResult()` method is called after all providers have been evaluated, or the `shouldEvaluateNextProvider()` method returned false. It is called with an array of results from all the individual providers' evaluations. It returns the final result, or can throw an error if needed. #### Known Limitations **Sub-Provider Hooks Not Executed:** Currently, when using MultiProvider, hooks registered on individual sub-providers via `provider->getHooks()` are **not executed** during flag evaluation. Only hooks registered at the API, Client, and Invocation levels (plus MultiProvider's own hooks) are executed. In the JS-SDK reference implementation, each sub-provider's hooks are executed around each provider call via a dedicated `HookExecutor`. The PHP `Provider` interface extends `HooksGetter` (per OpenFeature Requirement 2.10), so the mechanism exists—it just isn't wired up in the current implementation. **Workaround:** Register hooks at the API or Client level instead of on individual providers: This limitation will be addressed in a future release where per-provider hook execution will be implemented to match the JS-SDK behavior. ### Targeting Sometimes, the value of a flag must consider some dynamic criteria about the application or user, such as the user's location, IP, email address, or the server's location. In OpenFeature, we refer to this as [targeting](https://openfeature.dev/specification/glossary#targeting). If the flag management system you're using supports targeting, you can provide the input data using the [evaluation context](https://openfeature.dev/docs/reference/concepts/evaluation-context). ### Hooks [Hooks](https://openfeature.dev/docs/reference/concepts/hooks) allow for custom logic to be added at well-defined points of the flag evaluation life-cycle. Look [here](https://openfeature.dev/ecosystem/?instant_search%5BrefinementList%5D%5Btype%5D%5B0%5D=Hook&instant_search%5BrefinementList%5D%5Btechnology%5D%5B0%5D=php) for a complete list of available hooks. If the hook you're looking for hasn't been created yet, see the [develop a hook](#develop-a-hook) section to learn how to build it yourself. Once you've added a hook as a dependency, it can be registered at the global, client, or flag invocation level. ### Logging The PHP SDK utilizes several of the PHP Standards Recommendation, one of those being [PSR-3](https://www.php-fig.org/psr/psr-3/) which provides a standard `LoggerInterface`. The SDK makes use of a `LoggerAwareTrait` on several components, including the client for flag evaluation, the hook executor, and the global `OpenFeatureAPI` instance. When an OpenFeature client is created by the API, it will automatically utilize the configured logger in the API for it. The logger set in the client is also automatically used for the hook execution. > ⚠️ Once the client is instantiated, updates to the API's logger will not synchronize. This is done to support the separation of named clients. If you must update an existing client's logger, do so directly! ### Named clients Named clients are not yet available in the PHP SDK. Progress on this feature can be tracked [here](https://github.com/open-feature/php-sdk/issues/93). ### Eventing Events are not yet available in the PHP SDK. Progress on this feature can be tracked [here](https://github.com/open-feature/php-sdk/issues/93). ### Shutdown A shutdown method is not yet available in the PHP SDK. Progress on this feature can be tracked [here](https://github.com/open-feature/php-sdk/issues/93). ## Extending ### Develop a provider To develop a provider, you need to create a new project and include the OpenFeature SDK as a dependency. This can be a new repository or included in [the existing contrib repository](https://github.com/open-feature/php-sdk-contrib) available under the OpenFeature organization. You’ll then need to write the provider by implementing the `Provider` interface exported by the OpenFeature SDK. As you can see, this ends up requiring some boilerplate to fulfill all of the functionality that a Provider expects. Another option for implementing a provider is to utilize the AbstractProvider base class. This provides some internally wiring and simple scaffolding so you can skip some of it and focus on what's most important: resolving feature flags! > Built a new provider? [Let us know](https://github.com/open-feature/openfeature.dev/issues/new?assignees=&labels=provider&projects=&template=document-provider.yaml&title=%5BProvider%5D%3A+) so we can add it to the docs! ### Develop a hook To develop a hook, you need to create a new project and include the OpenFeature SDK as a dependency. This can be a new repository or included in [the existing contrib repository](https://github.com/open-feature/php-sdk-contrib) available under the OpenFeature organization. Implement your own hook by conforming to the `Hook` interface. To satisfy the interface, all methods (`before`/`after`/`finally`/`error`) need to be defined. You can also extend one of the typed abstract base classes (`BooleanHook`, `StringHook`, `IntegerHook`, `FloatHook`, `ObjectHook`) which automatically implement `supportsFlagValueType()` for the corresponding flag type. You can also make use of existing base classes for various types and behaviors. Suppose you want to make this same hook, and have no limitation around extending a base class, you could do the following: > Built a new hook? [Let us know](https://github.com/open-feature/openfeature.dev/issues/new?assignees=&labels=hook&projects=&template=document-hook.yaml&title=%5BHook%5D%3A+) so we can add it to the docs! ## ⭐️ Support the project - Give this repo a ⭐️! - Follow us on social media: - Twitter: [@openfeature](https://twitter.com/openfeature) - LinkedIn: [OpenFeature](https://www.linkedin.com/company/openfeature/) - Join us on [Slack](https://cloud-native.slack.com/archives/C0344AANLA1) - For more, check out our [community page](https://openfeature.dev/community/) ## 🤝 Contributing Interested in contributing? Great, we'd love your help! To get started, take a look at the [CONTRIBUTING](CONTRIBUTING.md) guide. ### Thanks to everyone who has already contributed Made with [contrib.rocks](https://contrib.rocks).