When requested, server-side SDKs evaluate feature flags to determine a user's flag variation. To do this, they execute an in-process flag evaluation algorithm and return the resulting value.
Server-side SDKs can evaluate flags because these SDKs know your complete flag ruleset. These SDKs can determine users' flag variations without having to make requests to LaunchDarkly's servers for every evaluated flag.
Server-side SDKs get the complete ruleset associated with an SDK key when initializing a connection to LaunchDarkly's servers. Through this persistent connection, LaunchDarkly will continuously update the SDK's cached flag ruleset whenever flag rules change on LaunchDarkly.
You can think of each flag evaluation as a pure function, where we use the provided user context along with the complete ruleset to see if your user should be included in an evaluation or not. It is important to note that we pass along rule data not user data. If a user does not have the correct attributes locally, then it will not get evaluated by the rules that are cached by the SDK.
I found similar functionality in another project. I am discouraged that flagr does not support it.
It's really convenient. First, flags are cached. No dependency on service availability and network problems.
Local flag evaluation is guaranteed in case of flagr accessibility problems. The load on the network is reduced and the response time is increased.
https://docs.launchdarkly.com/sdk/concepts/client-side-server-side#server-side-sdks-1
See examples of how it is implemented there: https://github.com/launchdarkly/php-server-sdk https://github.com/launchdarkly/go-server-sdk https://github.com/launchdarkly/node-server-sdk
https://docs.launchdarkly.com/sdk/server-side