Common misconceptions about LaunchDarkly architecture

Error happens on events endpoint; contexts aren’t populating in the dashboard; live events show no/minimal activity.

Errors or blocks on the events endpoints stop the ability to make correct flag evaluations.

Errors or blocks on the events endpoints do not affect the ability to make correct flag evaluations. Reference the contributor's guide.

• After the flag evaluation, the events endpoint only sends analytic events back to LaunchDarkly. It is entirely separate from the endpoint that serves flag data. Errors on the events endpoint can still be important to address, especially if you’re using experimentation, data export, or relying on analytics.

Any connectivity error, problem, or concern in setting up LaunchDarkly for the first time.

LaunchDarkly is using WebSockets.

• LaunchDarkly SDKs use two different mechanisms to receive feature flag data: streaming and polling.
   

  • Streaming endpoints use the Server-Sent Events (SSE) protocol. This is a one-way communication channel where the SDK sends an initial GET request to establish a persistent connection, and the LaunchDarkly service pushes updates down the stream to the SDK or Relay Proxy as changes occur.

  • Polling endpoints, by contrast, use standard HTTPS GET requests. The SDK regularly sends these requests at fixed intervals to check for updated feature flag data. Polling does not use SSE and is not a persistent connection.

• In both cases, SDKs do not send POST requests to the streaming or polling endpoints. POST requests are only used when sending events (such as user evaluations or custom events) to the events endpoint

The SDK maintains a connection for a little while, and then the connection is dropped; OR
The SDK request to the LaunchDarkly service never seems to close or end.

LaunchDarkly SDKs use a RESTful or polling mechanism for flag evaluations.

LaunchDarkly uses SSE to have long-lived connections for streaming. Reference, Comparing LaunchDarkly SDKs and REST API.

• When the SDK initializes, it sends a GET request to LaunchDarkly (or the Relay Proxy, if configured). The service or Relay receives the request and sends the payload back to the environment specified by the SDK key/mobile key/client-side ID. When the SDK receives this payload, the SDK is considered “Connected.” Streaming, the default connection mode for most SDKs, keeps an open connection to the streaming endpoint or Relay Proxy so that any changes made to flags or flag configurations are sent to the SDK immediately. This is why it’s important to ensure your architecture allows long-lived connections between the SDK instance and LaunchDarkly.

Making lots of flag evaluations will cause an overabundance of network requests.

variation() and allFlags() methods have to make a network request whenever invoked in an application.

variation() and allFlags() methods do not make network requests Reference, Contributor's guide.

• When you call any of the variation() or allFlags() methods, the SDK looks up the value from the in-memory store. It does not create another GET request to the streaming or polling endpoints.

Flag evaluations received do not match the expected flag evaluation.

If the user has all the attributes in the dashboard, we can just send the user key, and LaunchDarkly will know all the corresponding attributes.

The SDKs always use the user/context object provided in the code, not the user/context object saved in the LaunchDarkly dashboard. Reference, The Contexts list.

• Every time you call variation() or allFlags() you need to pass a context object with all the attributes necessary to get a correct evaluation. None of the LaunchDarkly SDKs retrieve the user from your LaunchDarkly account to make a flag evaluation. You may see inconsistent flag values if you leave out some attributes used in flag or segment rules.

• You can use this to your advantage to change the flag value a context receives by removing and re-adding attributes programmatically as needed.

When using the server-side SDK, I’m calling identify() but don’t see the expected flag values for contexts.

The server-side SDKs are single-context like the client and mobile SDKs.

You only need to use the identify() method to change the user/context using a client-side or mobile SDK. Reference, Identifying and changing contexts.

• The client-side SDKs, including mobile, can only have one context at a time by design; this is how we ensure that your end users can’t see your flag rules, which may contain proprietary info about your business or PHI.

• The server-side SDKs are multi-context; therefore, the identify method in the server-side SDKs only sends an analytic event to LaunchDarkly. This means you always need to pass in the context object when calling variation() or allFlags() in the server-side SDKs. You don't have to call identify unless you want to populate the dashboard.

• Similarly, this is why only the client-side and mobile SDKs require a context to be passed in at initialization, whereas the server-side SDKs do not take a context object at initialization.