Example

Featureflags Props

Demonstrates how to evaluate feature flags from local application properties. Shows the properties-backed FeatureClient, feature.* toggle properties, default values for missing flags, and the tradeoff that request-level targeting is not supported.
Group
REST API
Path
examples/rest-api/featureflags-props

Overview

Helix Spring Boot web service that shows how to evaluate feature flags with the Helix properties-backed feature-flag starter.

Run this example from the shared examples build:

Run

Run this example from the shared examples build


./gradlew -p examples runExample -Pexample=rest-api/featureflags-props --init-script "$(pwd)/helix.init.gradle"

What It Shows

  • adding helix-featureflags-props-spring-boot-starter to a Helix REST API
  • defining feature flags with local feature.* properties
  • evaluating properties-backed flags through the Helix FeatureClient
  • using default values when a feature property is not present
  • the tradeoff that properties-backed flags are global and do not support request-level targeting

Endpoints

  • GET /v1/featureflags-props/experience/{userId}
  • GET /liveness
  • GET /health

Example success response

{
  "userId": "pilot-user",
  "plan": "enterprise",
  "betaCheckoutEnabled": true,
  "prioritySupportEnabled": false,
  "defaultedFlagEnabled": true,
  "targetingSupported": false,
  "message": "Serve the beta checkout flow from local properties."
}

Development

Building the Application

Run the following command to build the service:

Command

Building the Application


./gradlew clean build

Testing the Application

Run the following command to run the service tests:

Command

Testing the Application


./gradlew test
./gradlew integration

Trying the API

Run the service:

Then try:

The example loads feature flags from application.properties:

  • feature.beta-checkout=true - feature.priority-support=false

It also demonstrates a defaulted flag lookup:

  • experimental-billing is not defined in properties - the service evaluates it with a default value of true

Unlike LaunchDarkly, the properties-backed implementation does not support request-scoped FeatureContext targeting. The response intentionally echoes the caller and plan while returning the same flag values for every request.

Command

Trying the API


./gradlew bootRun

Command

Trying the API


curl "http://localhost:8080/v1/featureflags-props/experience/pilot-user?plan=enterprise"

curl "http://localhost:8080/v1/featureflags-props/experience/standard-user?plan=standard"