DOCSEARCHbyAlgolia
Submit Docs

FeatureHub Documentation

repository·main·Indexed 18 days ago

https://github.com/featurehub-io/featurehub

A Cloud Native platform for managing feature flags, A/B experiments, and centralized remote configuration. Available as a self-hosted Open Source service and a managed SaaS offering. Documentation covers Admin SDKs for Java, C#, TypeScript, and Dart, the FeatureHub CLI for feature and strategy management, and end-to-end SDK testing configurations.

Tokens
63.1K
Snippets
130
Records
297
Agent score
63%

What's inside FeatureHub

  1. Overview of FeatureHub capabilities

    main

    FeatureHub is a Cloud Native platform designed for Feature Flags, Remote Configuration, and A/B Testing. It supports mobile, web, and server applications through a variety of SDKs.

    Users can choose between two primary deployment models:

    1. SaaS (Managed Cloud): A fully managed offering with pay-as-you-go pricing. A 30-day free trial is available at app.featurehub.io.
    2. Self-hosted (Open Source): You can run FeatureHub on your own infrastructure, including deployment via Docker or Kubernetes (using Helm Charts).

  2. Overview of Admin SDKs

    main

    Admin SDKs are used to interact exclusively with the Management Repository or the Admin App. They are designed for administrative tasks rather than feature flag evaluation (which is the role of Client SDKs).

    Key characteristics:

    • Generated Code: All Admin SDKs are purely generated from OpenAPI documentation. If a specific SDK's format does not meet your requirements, you should look for an alternative generated from the same OpenAPI spec.
    • Usage: These SDKs are provided as examples and references for developers, and are used internally to test Client SDKs and examples.
    • Not in Repository: Unlike Client SDKs, the actual source code for these Admin SDKs is not stored in this repository; they are generated on demand.

  3. Overview of the Party Server

    main

    The Party Server is a consolidated server image that bundles three distinct components into one: the Management Repository (MR), the Dacha Cache, and the SSE Edge.

    It is designed for simple configurations, such as local development, testing with an H2 database (available in the docker-compose subdirectory), or using standard databases like PostgreSQL, MySQL, or SQL Server.

    Note on Scalability: For production or scalable environments, you should not use this consolidated image. Instead, deploy the individual Docker containers for each component separately. In a secure production setup, the Management Repository and Dacha servers should not be exposed externally; they should typically only be accessible by the SSE Edge servers.

  4. Manage and navigate applications

    main

    Once applications are created, you can interact with them via the Applications page:

    • Switching Applications: Use the drop-down menu on the Applications page to switch between different applications.
    • Monitoring: Application tiles provide a high-level overview, displaying the total number of environments and features contained within each application.

  5. SDK Language Support and Capabilities

    main

    FeatureHub provides SDKs for multiple languages with varying levels of feature support. Capabilities include real-time updates via Streaming API (SSE), REST API polling, rollout strategy evaluation (Server vs. Client), and observability integrations like OpenTelemetry.

    When choosing an SDK, consider whether your use case requires specific features like:

    • Rollout Strategies: Some languages support both Server-evaluated and Client-evaluated strategies.
    • Real-time Updates: Supported via SSE (Streaming API) or REST API polling.
    • Observability: Support for OpenTelemetry span augmentation and full-trace consistency is primarily available in Java and Javascript/Typescript.
    • Storage Reliability: Some SDKs allow replacing or adding alternative storage sources (e.g., Redis, Memcache, or Local Yaml) for caching or offline development.
    |===================================
||Java^1^|Javascript^2^|Go|Dart^3|C#^4|Python|Ruby|Swift
|Streaming API feature updates (SSE) |Y|Y|Y|Y|Y|Y|Y|N
|REST API by timer polling (GET feature updates )|Y|Y|N|Y|N|Y|Y|N
|REST API by usage/timeout (GET feature updates )|Y|Y|N|N|N|Y|Y|Y
|REST API one-off GET requests support |Y|Y|N|Y|N|Y|N|Y
|Test API (PUT requests to update feature values) |Y|Y|N|Y|Y|N|N|N
|Rollout Strategies - Server Evaluated|Y|Y|N|Y|Y|Y|Y|Y
|Rollout Strategies - Client Evaluated|Y|Y|Y|N|Y|Y|Y|N
|Background Start|Y|Y|Y|Y|Y|Y|Y|Y
|Block until Start|Y|N|Y|N|N|N|N|N
|Readiness Listeners|Y|Y|Y|Y|Y|N|N|N
|Feature Update Listeners|Y|Y|Y|Y|Y|N|N|N
|Deep Usage/Analytics Adapter Support|Y|Y|N|N|N|N|N|N
|OpenTelemetry Feature Evaluation Span Augmentation|Y|Y|N|N|N|N|N|N
|Full-trace Feature Value consistency support|Y|Y|N|N|N|N|N|N
|Twilio Segment (tm) Feature Evaluation Tracking|Y|Y|N|N|N|N|N|N
|Phantom Feature Support|Y|Y|N|N|N|Y|N|N
|Feature Interceptors|Y|Y|N|Y|N|Y|Y|Y
|Local Yaml Interceptor|Y|Y|N|N|N|N|Y|N
|Alternative Storage Reliability Support^5^|Y|Y|N|N|N|N|Y|N
|Local Yaml Storage|Y|Y|N|N|N|N|Y|N
|Redis Storage|Y|Y|N|N|N|N|Y|N
|Memcache Storage|N|N|N|N|N|N|Y|N
|===================================

  6. Overview of the Strategy Editor

    main

    The Strategy Editor is a specialized UI component used for defining and modifying rollout strategies. It is implemented as an EditableRolloutStrategy interface. This component is designed for reuse across different parts of the FeatureHub administration interface, specifically for:

    • Individual feature value editing: Configuring strategies for specific values within a feature.
    • Feature groups: Managing strategies at the group level.
    • Shared strategies: (Upcoming) Managing strategies that are shared across multiple features.

  7. Use Percentage Split Rules for Rollouts and A/B Testing

    main

    Percentage split rules allow you to roll out a feature value to an approximate percentage of your user base. This is useful for "soft launches" or A/B testing.

    Key Requirements

    • Context: For percentage rules to work, you must provide a Context containing either a sessionId or a userKey (e.g., userId, email) in your SDK implementation.
    • Accuracy: The algorithm uses the provided sessionId or userKey to ensure consistent assignment. Accuracy improves with a larger number of clients.
    • Constraints: If multiple strategies contain percentage rules, the sum of all percentages cannot exceed 100%. Any remainder of the audience will receive the flag's default value.

    Use Cases

    • Soft Launch: Set the default value to off and a percentage rule to on (e.g., 20%). Gradually increase the percentage as confidence grows.
    • A/B Testing: Use percentage splits to run experiments and monitor results (e.g., via the Google Analytics connector).

  8. How Edge operates and manages caches

    main

    Edge functions as an SSE-based source of updates for features.

    Lifecycle and Discovery:

    • Startup: On start, Edge connects to the Management Repository (MR) on a NATS channel named named-caches to request the list of available caches.
    • Cache Management: Edge continuously listens to the named-caches channel and automatically updates its internal list of caches when changes occur.
    • Update Listening: Edge listens to the feature update lists for each named cache.

    Edge is designed for testing accounts to toggle features on and off during tests and allows certain Service Accounts to post changes back into the infrastructure.

  9. Use Admin Service Accounts for programmatic access

    main

    Admin Service Accounts provide programmatic access to the FeatureHub Management Repository API via the Admin SDK API. They are intended for automated tasks such as creating applications, environments, and features, or performing operations on existing features.

    To use an Admin Service Account:

    1. Create the account: A Super Admin must create the account via the Admin Service Account page in the UI.
    2. Assign permissions: Add the service account to a user group to grant it necessary permissions. Note that Admin Service Accounts and regular users share the same group-based permission model.
    3. Secure the token: When the account is created, copy the access token immediately. The token is not displayed again in the UI after creation.
    4. Manage the token: If a token is lost or compromised, you can reset it via the UI. You can also remove a token from a group to revoke access.

  11. Access FeatureHub via SDKs and APIs

    main

    FeatureHub provides multiple ways to integrate and manage feature flags programmatically:

    SDK Integration

    Use SDKs to consume feature flags in your applications (Mobile, Web, Server). Documentation includes:

    • SDK capabilities overview
    • Usage examples
    • Understanding the difference between Client & Server API Keys

    Headless Management (Admin API)

    For automating management tasks (e.g., creating flags, updating environments) without using the UI, use the headless access methods:

    • Admin SDK API: The formal API definition for managing the platform.
    • Admin Development Kit (ADK): Documentation and usage for the toolkit designed to interact with the Admin API.

  12. Compare Client Evaluated vs Server Evaluated API Keys

    main

    When a service account is granted access to an environment, FeatureHub automatically generates two types of API keys:

    1. Client Evaluated API Key: Used when feature evaluation logic happens within the client-side application.
    2. Server Evaluated API Key: Used when feature evaluation logic happens on the server-side.

    A service account requires at least READ permission for an environment to generate these keys. You can manage and copy these keys from the API Keys menu in the Admin UI.