DOCSEARCHbyAlgolia
Submit Docs

Reforge Launch Documentation

website·Indexed 40 days ago

https://docs.reforge.com

Documentation for Reforge Launch, a platform for managing feature flags, dynamic configurations, and beta rollouts. It includes guides on SDK architecture for Node, Ruby, and React, zero-knowledge secret management, offline mode via datafiles, and tools like the Reforge CLI and Model Context Protocol (MCP) server for managing flags via Claude.

Tokens
28.7K
Snippets
164
Records
209
Agent score
52%

What's inside Reforge

  1. Overview of Reforge Zero-Knowledge Secret Management

    Reforge provides zero-knowledge support for sharing secrets between developers and applications. The system uses client-side cryptography where Reforge only stores encrypted blobs. The user is responsible for distributing the encryption/decryption keys (secret keys) to the appropriate people and services via environment variables. The Reforge SDK handles the decryption process automatically when retrieving a secret.

  2. Manage feature flags and configs with Reforge Launch MCP

    The Reforge Launch Model Context Protocol (MCP) server integrates Reforge feature flag and config management into MCP-enabled IDEs (such as Claude or Cursor). Supported capabilities include:

    • Browsing and searching flags/configs across workspaces.
    • Viewing flag details, rules, and targeting.
    • Checking audit logs for change history.
    • Viewing production evaluation data.
    • Creating and updating flags and config values.
    • Identifying and removing flags marked for deletion.
    • Setting personal overrides for testing.

  3. Manage Evaluation Context in Ruby

    Context provides the rules engine with information about users, teams, or devices to evaluate flags. There are three ways to provide context:

    1. Global Context: Set during Reforge.init. Used for all evaluations unless overridden.
    2. Thread-local (Request-scoped): Recommended for Rails apps using Reforge.with_context in an around_action in ApplicationController to avoid passing context to every call.
    3. Just-in-time Context: Passed as the second argument to .enabled? or .get for a specific evaluation.
    # 1. Global Context
Reforge.init(
  global_context: { application: { key: "my.corp.web" } }
)

# 2. Thread-local (Rails ApplicationController)
class ApplicationController < ActionController::Base
  around_action do |_, block|
    Reforge.with_context(reforge_context, &block)
  end

  def reforge_context
    { device: { mobile: mobile? } }.merge(reforge_user_context)
  end
end

# 3. Just-in-time Context
context = { user: { id: 123, email: "alice@example.com" } }
Reforge.enabled?("my-feature", context)

  4. Understand Reforge server-side SDK architecture

    Reforge server-side SDKs are designed for high performance and resilience by performing evaluations in-process. To avoid remote call latency during lookups, the SDK maintains a local, thread-safe hashmap of the configuration.

    Key architectural behaviors include:

    • Initialization: The Reforge Client singleton fetches the latest configuration from multiple sources upon startup before becoming available for use.
    • Real-time Updates: The client maintains a streaming connection to Reforge APIs to receive near-instant updates.
    • Resiliency: The SDK employs polling as a fallback measure to ensure configuration is up-to-date even if streaming connections fail.
    • Performance: Because feature flags and configurations are stored in-process, lookups are lightning fast and do not require API calls.

  5. Understand Reforge rule evaluation and segmentation

    Reforge uses rules to target specific users for feature flags. Segments are reusable sets of these rules. Rules are evaluated sequentially (in order); the first rule that matches determines which variant is served. When a rule matches, it can either return a specific variant (e.g., true, false) or a variant based on a percentage rollout. Percentage rollouts are 'sticky' to the provided lookup key and will not change unless the key or the percentage values are modified.

  6. Understand Reforge frontend SDK architecture and evaluation

    Reforge frontend SDKs perform evaluation server-side to prevent leaking sensitive rule data (such as customer ID lists) to the browser. Instead of receiving raw configuration rules, the client receives a list of evaluated feature flag values for a specific context. If a context's attributes change and the client is re-initialized, the SDK re-fetches the flags for that context.
    {
  "feature.exp12-big-button": "control",
  "feature.exp14-button-class": "very-blue",
  "feature.risky-business": true
}

  7. Implement Zero-ms feature flags in Ruby

    Zero-ms feature flags eliminate the need for a frontend HTTP request to fetch flag evaluations by sending evaluations from the backend to the frontend. This prevents the 'Flash of Original Content' (FOOC) and allows the application to run offline without changing frontend code. This feature is currently available in the Ruby client.

  8. Enable Reforge offline mode using datafiles

    Reforge supports a local-only mode that avoids contacting the server by using a datafile. A datafile is a JSON representation of all configurations for a specific environment. You can specify the datafile path using the REFORGE_DATAFILE environment variable or the datafile configuration option.

  9. Reforge Launch new feature capabilities

    Reforge Launch introduces several new capabilities for feature management:

    • MCP Support: Connect Launch to Claude, Cursor, or other MCP-enabled IDEs for assisted flag cleanup.
    • Type-Safe Code Generation: Automatic generation of type-safe clients for React, Node, and JavaScript.
    • JSON Schemas: Enforcement of structure for config and prompt JSON.
    • Mustache String Interpolation: Templating combined with type safety via codegen.
    • Prompt Management: Schemas for model, temperature, and templated systemMessage values with generated code for safe usage.
    • New Rule Operators: Support for Before/After, Greater than, Less than, and SemVer (requires Reforge SDK).

  10. Choose the correct Reforge client for your rendering strategy

    Depending on your application architecture, you should use different Reforge clients to handle feature flag and configuration evaluations:

    • Pure Server-Side Rendering (SSR): Use only the Node client. It runs on the server and provides in-memory evaluation using user-specific context provided in request handlers.
    • Pure Client-Side Rendering (CSR): Use only the JavaScript (or React) client. It runs in the browser and fetches evaluated flags from Reforge via a single HTTP request based on the user's context.
    • Hybrid Apps (SSR + CSR): Use both the Node client (for in-request server evaluations) and the JavaScript/React client (for client-side rendering decisions).
    • Statically Generated Sites: Use the Node client to evaluate flags at build time. If the site also includes client-side rendering, include the JavaScript/React client as well.

  11. Initialize the Reforge Ruby Client

    Initialize the Reforge client using Reforge.init. By default, the SDK looks for the REFORGE_BACKEND_SDK_KEY environment variable for authentication. For Rails applications, it is recommended to call Reforge.init within application.rb to allow for environment-specific configurations.
    # Basic initialization (reads REFORGE_BACKEND_SDK_KEY env var)
Reforge.init

# Rails application initialization
# application.rb
module MyApplication
  class Application < Rails::Application
    Reforge.init
  end
end

  12. Handle Reforge Loading States

    The useReforge hook provides a loading boolean. Because flags are fetched from the Reforge CDN, there is a brief period where loading is true, get() returns undefined, and isEnabled() returns false.

    Strategies for handling this:

    1. Top-level blocking: Check loading at the page level to show a global spinner, ensuring flags are ready before the UI renders.
    2. Component-level blocking: Use loading within specific components to show local spinners and prevent UI flickering.
    3. Graceful degradation: Do nothing if the flag simply toggles the visibility of an element; the element will "pop-in" once loading completes.
    const MyComponent = () => {
  const { get, loading } = useReforge();

  if (loading) return <MySpinnerComponent />;

  return <div>{get("my-feature-flag")}</div>;
}