> 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 Our SDKs are designed to live at the application layer of your application and provide a secure and out-of-the-box method for controlling 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 Split 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	/pages/8AF59NZ2aqPq17XR8ugB
	Angular Utilities	/pages/LJUbiHqsA3WW7eSs02EX
	Browser SDK
	Flutter Plugin	/pages/snGwWXajHlfJW7GDuFNF
	iOS SDK	/pages/7GUS0j7lBbffwUUTAgvq
	JavaScript SDK	/pages/2W8f1cXqxHpZb3xLL5je
	React SDK	/pages/avzO8zntoEWOK5ZVqkA3
	React Native SDK	/pages/foy1cK0LEZ2lp8QguIuf
	Redux SDK	/pages/zbpMQAvyCnZBKNbFmCc3

#### Client-side SDK Suites


	Android Suite	/pages/3ks69wKAhG4XvmVbZ6Xj
	Browser Suite	/pages/DcRGs2KekvF0tPE9vuNf
	iOS Suite	/pages/gmtzCtH7qKd30fjMDfMg

#### Client-side RUM Agents


	Android Agents	/pages/0H5kmb6WM71VzZ9yyTm0
	Browser Agents	/pages/K1e9ai9ihe27QesIrvhC
	iOS Agents	/pages/1tDiwj1CsAH84dpM6m1T

#### Server-side SDKs


	Elixir Thin Client SDK	/pages/aCR1qteofOk23blhGAC4
	Go SDK	/pages/9S5EdLJQSGskpM0SkLxH
	Java SDK	/pages/uwrbv211wAgmTIdyenQD
	.NET SDK	/pages/AogFQGSeilYEy4E1M6nj
	NodeJS SDK	/pages/Ffpw4KXywnonGdBt79yQ
	PHP SDK	/pages/VECjaZVbNH17j4LpfoZZ
	PHP Thin Client SDK	/pages/Iv28tuwRX9swh3cpgarB
	Python SDK	/pages/sLjI7D2F7J7Fvg1ZKE9g
	Ruby SDK	/pages/ZRyRRi2ra4rGRlie7iRQ

#### Optional Infrastructure


	Split Daemon (splitd)	/pages/KN0KengJjX4SrBWxHj1F
	Split Evaluator	/pages/1MrRpfxzlUFAYdKytfbE
	Split Proxy	/pages/EZJVipUInU5cBablPXFa
	Split Synchronizer	/pages/OkOmXqVarqMVzjp9Mc2K
	Split JavaScript Synchronizer Tools	/pages/tzgtoFntiMLb2i0YXoa4
	Harness Proxy	/pages/h2pZlZukvBQ5yFZCItjJ

#### OpenFeature Providers


	Android SDK	/pages/L21NxV2qsSkETdB3b2fH
	iOS SDK	/pages/wKCMCSy0eAvjEQvvJe8S
	Web SDK	/pages/GtRMAnJJOu6nLmargGJk
	Angular	/pages/lPP4BZLYhof32eH7UV70
	React	/pages/dwzC7qGMzj8DZoYmEdi5
	Java SDK	/pages/M49Dup7gNFA7GgWO7TU2
	Node.js	/pages/wUGhgu41rrhmshqWOgDU
	Python SDK	/pages/0HBp8Zx2WSsj2tud8GDt
	.NET SDK	/pages/GX3SPITzEp8F3Gz1C6Yu
	Go SDK	/pages/F8pnEyyfCWslBkS6oUlU

### Decision engine When you set up rules for your feature flags and experiments to be targeted to subsets of your customer base in Split (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 Split 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 Split 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.