> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/feature-management-experimentation/new-to-fme/get-started/install-the-sdk.md). # Install the FME SDK Learn how to install the Harness FME SDKs. Our SDKs are designed to run at the application layer of your application and provide a secure, out-of-the-box way to control your experiments and feature flags. Each SDK has two main functions: * [Serve as a decision engine for your application](#decision-engine) * [Automatically capture what variants of your features your customers are served](#capturing-what-your-customer-was-served) ### Harness FME SDKs Harness FME SDKs are for specific languages or use cases. To choose the best SDK for your scenario, see the respective SDK documentation. #### Client-side SDKs


	Android SDK	Android SDK
	Angular Utilities	Angular utilities
	Browser SDK
	Flutter Plugin	Flutter plugin
	iOS SDK	iOS SDK
	JavaScript SDK	JavaScript SDK
	React SDK	React SDK
	React Native SDK	React Native SDK
	Redux SDK	Redux SDK

#### Client-side SDK Suites


	Android Suite	Android Suite
	Browser Suite	Browser Suite
	iOS Suite	iOS Suite

#### Client-side RUM Agents


	Android Agents	Android RUM Agent
	Browser Agents	Browser RUM Agent
	iOS Agents	iOS RUM Agent

#### Server-side SDKs


	Elixir Thin Client SDK	Elixir Thin Client SDK
	Go SDK	Go SDK
	Java SDK	Java SDK
	.NET SDK	.NET SDK
	NodeJS SDK	Node.js SDK
	PHP SDK	PHP SDK
	PHP Thin Client SDK	PHP Thin Client SDK
	Python SDK	Python SDK
	Ruby SDK	Ruby SDK

#### Optional Infrastructure


	Split Daemon (splitd)	Split Daemon (splitd)
	Split Evaluator	Split Evaluator
	Split Proxy	Split Proxy
	Split Synchronizer	Split Synchronizer
	Split JavaScript Synchronizer Tools	Split JavaScript synchronizer tools
	Harness Proxy	Harness Proxy

#### OpenFeature Providers


	Android SDK	Android OpenFeature Provider
	iOS SDK	iOS OpenFeature Provider
	Web SDK	Web OpenFeature Provider
	Angular	Angular OpenFeature Provider
	React	React OpenFeature Provider
	Java SDK	Java OpenFeature Provider
	Node.js	Node.js OpenFeature Provider
	Python SDK	Python OpenFeature Provider
	.NET SDK	.NET OpenFeature Provider
	Go SDK	Go OpenFeature Provider

### Decision engine When you set up rules for your feature flags and experiments to be targeted to subsets of your customer base in Harness FME (e.g., run a 50/50 test of a new home page on customers in New York), our SDKs automatically download down these rules and maintain a local copy of them on your machines. From there, our SDKs then take care of keeping themselves up to date by periodically checking for any changes to the rules that are made in the Harness FME user interface. When your application then loads for your customers, you can simply ask the SDK via a method called `getTreatment` to decide what variant of a feature the customer should see. Since the SDK is maintaining a local copy of the rules that govern your features and experiments, it can simply reference that copy of your rules and make the decision to serve "on" or "off" to your customer without having to make a single remote call. From there, you can take the decision returned by our SDK and use that information to serve up the proper experience to your customer. The `getTreatment` function requires a customer ID, which is usually a hash representation of the current session's customer. The SDK uses the customer ID when the feature flag includes percentage-based targeting rules (for example: 50% `"On"` and 50% `"Off"`). In this case, this is not relevant since we are assigning 100% of a single treatment. However, the SDK still requires the customer ID to calculate the treatment. If the implementation will not use percentage-based treatments, then apply a dummy customer ID with any string value. In this manner, our SDK is able to abstract out any need to hardcode this type of decision making in your application. ### Capturing what your customer was served Each time our SDK makes a decision of what your customer should be served, it automatically takes that information and queues it up on your machines. The SDK then takes care of all the work in passing this information up to Harness FME in the background without ever slowing down your application. By capturing this information, you can easily understand what customers are being served and set the basis for being able to properly measure your experiments. ### Handling impressions and events load {% hint style="danger" %} **WHAT HAPPENS IF THE SDK CANNOT KEEP UP WITH THE INCOMING IMPRESSIONS AND EVENTS LOAD?** The SDK will post the queue content when it becomes full. However, if the load consistently exceeds capacity, the queue will repeatedly fill and be posted, clearing it. Meanwhile, new impressions or events generated during this period are not stored because the queue is full, resulting in data loss. Harness recommends verifying these SDK configuration parameters against your production generation rates for impressions and events, ensuring the SDK is properly configured to handle the load. {% endhint %} By default, all FME SDKs have configuration parameters that allow them to process a heavy load of generated Impressions and Events. These default parameter values are documented in the respective SDK documentation. In the [Java SDK](/feature-management-experimentation/new-to-fme/sdks-and-customer-deployed-components/server-side-sdks/java-sdk.md#configuration), for example, the Configuration section includes parameters and default values for posting impressions: * `impressionsRefreshRate = 60` (seconds) * `impressionsQueueSize = 30k` These settings mean the SDK can handle up to 30,000 impressions (each generated by a single `getTreatment` call) every 60 seconds. If your application generates more than 30,000 impressions per minute, you will need to adjust these parameters. For instance, generating 60,000 impressions per minute could be handled by setting: * `impressionsRefreshRate = 20` or `impressionsQueueSize = 70k` Harness recommends providing some buffer so the SDK can handle the actual load. If the queue size is reached, the SDK will attempt to post its contents regardless of the impression post thread’s scheduled run time. The same concept applies to events created using the SDK’s `track()` method. The relevant Java SDK parameters for posting events are: * `eventFlushIntervalInMillis = 30000` (30 seconds) * `eventsQueueSize = 500` These values allow the Java SDK to handle up to 1,000 events per minute. {% @harness-feedback/feedback %}