This repository centralizes the client-side SDKs for Flipt.

These client-side SDKs are responsible for evaluating context and returning the results of the evaluation. They enable developers to easily integrate Flipt into their applications without relying on server-side evaluation.

Overall documentation for the client SDKs can be found on our website.

Also, check out our introductory blog post on these client-side SDKs.

There are two versions of the client SDKs:

The Foreign Function Interface (FFI) versions of the client SDKs are currently available.

The FFI-based SDKs are currently supported on the following OSes/architectures:

• Linux x86_64
• Linux arm64
• MacOS x86_64
• MacOS arm64

The WebAssembly (WASM) version of the client SDKs is currently in beta. This version allows you to evaluate flags in the browser using WebAssembly which is OS and architecture agnostic.

The client SDKs are designed to be embedded in end-user applications.

The evaluation logic is written in Rust and can be found in the flipt-evaluation directory.

The language clients that are used in end-user applications wrap the engine can be found in the flipt-client-{language} directories.

See ARCHITECTURE.md.

We are constantly growing our list of supported languages.

Currently, we support the following languages/platforms:

1. Go (FFI)
2. Python (FFI)
3. Ruby (FFI)
4. NodeJS (FFI)
5. Java (FFI)
6. JavaScript/Typescript (Browser) (WASM)
7. Flutter/Dart (FFI)

Documentation for each client can be found in the README of that client's directory.

Languages we are planning to support:

1. Rust
2. C#

Languages we would like to support but lack expertise in:

1. Kotlin
2. Swift

Want to see a client in a language we don't support? Open an issue and let us know!

Alternatively, if you have experience in any of the above languages/platforms we welcome all contributions!! ❤️

Please take a look at each client's README for installation and usage instructions.

Why you may prefer to use a client-side SDK over our server-side SDKs:

1. You want extremely low-latency evaluation and high throughput.
2. You are ok with eventual consistency and can tolerate stale data for a short time.
3. You want to reduce the load in your network by not having each client make a request to the Flipt server for each evaluation.
4. You need evaluation to occur in-process for some reason (e.g. you are evaluating a flag in a web worker).

We have done some simple benchmarking to test the performance of the client SDKs vs the server SDKs with Flipt running locally.

Here we performed 1000 evaluations of a flag using the client SDKs and the server SDKs. The client SDKs were able to perform the evaluations in a fraction of the time it took the server SDKs. This is because the client SDKs can perform the evaluations in memory without having to make a request to the Flipt server.

While the server SDKs performed evaluations in the range of 0-14ms, the client SDKs performed evaluations in the range of 0-0.1ms (100 microseconds).

See CONTRIBUTING.md.

We are not Rust experts and are constantly learning. If you see something that can be improved, especially in the flipt-engine-ffi and flipt-evaluation directories, please open an issue or a PR, we would love to learn from you. ❤️

All code in this repository is licensed under the MIT License.

• Unleash/yggdrasil - While we independently decided upon using Rust + FFI as the engine for the client SDKs, we were inspired by the design of the yggdrasil project from Unleash.