@launchdarkly/js-server-sdk-common - v2.26.1
    Preparing search index...

    Interface LDDataSystemOptions

    Configuration options for the Data System that the SDK uses to get and maintain flags and other data from LaunchDarkly and other sources.

    Example (Recommended):

    let dataSystemOptions = {
    dataSource: {
    dataSourceOptionsType: 'standard';
    },
    }

    Example (Polling with DynamoDB Persistent Store):
    ```typescript
    import { DynamoDBFeatureStore } from '@launchdarkly/node-server-sdk-dynamodb';

    let dataSystemOptions = {
    dataSource: {
    dataSourceOptionsType: 'pollingOnly';
    pollInterval: 300;
    },
    persistentStore: DynamoDBFeatureStore('your-table', { cacheTTL: 30 });
    }
    const client = init('my-sdk-key', { hooks: [new TracingHook()] });
    interface LDDataSystemOptions {
        dataSource?: DataSourceOptions;
        fdv1Fallback?: FDv1FallbackConfiguration | null;
        overrides?: LDOverrideSourceOptions;
        persistentStore?:
            | LDFeatureStore
            | ((clientContext: LDClientContext) => LDFeatureStore);
        useLdd?: boolean;
    }
    Index
    dataSource?: DataSourceOptions

    Configuration options for the Data Source that the SDK uses to get flags and other data from the LaunchDarkly servers. Choose one of StandardDataSourceOptions, StreamingDataSourceOptions, PollingDataSourceOptions, or CustomDataSourceOptions; setting the type and the optional fields you want to customize.

    If not specified, this defaults to using the StandardDataSourceOptions which performs a combination of streaming and polling.

    See LDDataSystemOptions documentation for examples.

    fdv1Fallback?: FDv1FallbackConfiguration | null

    Configuration for the SDK's FDv1 Fallback Synchronizer.

    The FDv1 Fallback Synchronizer is engaged only in response to a server-directed FDv1 Fallback Directive (the x-ld-fd-fallback: true response header) -- it is independent of the FDv2 initializer/synchronizer chain configured via dataSource.

    If omitted, the SDK uses sensible defaults derived from the rest of the configuration. If explicitly set to null, no FDv1 fallback synchronizer is configured and the SDK will transition to a terminal Closed state when the directive is received.

    Configures an override source.

    The source supplies flag and segment definitions that take precedence over data received from LaunchDarkly on a per-key basis. Overrides let an operator force one or more flags to a known state on a running client, whether or not the client can reach LaunchDarkly. Flags not present in the override data are unaffected.

    The override source is not a data source. It has no effect on the client's initialization status or data source status. Configuring it changes nothing until the source supplies an override. At most one override source can be configured.

    When the client is offline, the source is not built or started: no overrides are served, and a configuration error in the source is not reported. The SDK logs a warning instead.

    Some implementations provide the source object itself, while others provide a factory function that creates the source based on the SDK configuration. This property accepts either.

    Flag overrides are currently experimental and subject to change.

    persistentStore?:
        | LDFeatureStore
        | ((clientContext: LDClientContext) => LDFeatureStore)

    Before data has arrived from LaunchDarkly, the SDK is able to evaluate flags using data from the persistent store. Once fresh data has arrived from LaunchDarkly, the SDK will no longer read from the persistent store, although it will keep it up-to-date for future startups.

    Some implementations provide the store implementation object itself, while others provide a factory function that creates the store implementation based on the SDK configuration; this property accepts either.

    whose properties may be used to influence creation of the persistent store.

    useLdd?: boolean

    Whether you are using the LaunchDarkly relay proxy in daemon mode.

    In this configuration, the client will not connect to LaunchDarkly to get feature flags, but will instead get feature state from a database (Redis or another supported feature store integration) that is populated by the relay. By default, this is false.