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 uses server-sent events (SSE), not WebSockets.

• The streaming and polling endpoints use the server-sent events protocol to communicate to LaunchDarkly. The stream of information is one-directional – data flows from the LaunchDarkly service to the Relay Proxy or SDK instance. This means the SDKs send a GET request to LaunchDarkly streaming and polling endpoints, and the service sends the payload for the environment. The SDKs do not send POST requests on the streaming or polling endpoints. POST requests are only sent on the events endpoints.

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's 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.

• 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.