68bad77a84
* docs: Update Unleash architecture digram * fix: typo an -> a * docs(fix): fix img link in readme * docs: update architecture graph
2.5 KiB
| title |
|---|
| Unleash introductory overview |
One of the most important aspects of the architecture to understand is that feature toggles are evaluated in a client SDKs which runs as part of your application. This makes toggle evaluations super-fast (we're talk nano-seconds), scalable and resilient against network disturbances. In order to achieve this Unleash compromises a small update-delay when you change your toggle configurations until it is fully propagated to your application (in terms of seconds and is configurable).
If you want more details you can read about our unique architecture.
Unleash Server
Before you can connect your application to Unleash you need a Unleash server. You have a few options available:
- Unleash Open-source
- Unleash Enterprise
System Overview
- Unleash API - The service holding all feature toggles and their configurations. Configurations declare which activation strategies to use and which parameters they should get. API documentation
- Unleash Admin UI - The dashboard used to manage feature toggles, define new strategies, look at metrics, etc. Create your first feature toggle
- Unleash SDK - Used by clients to check if a feature is enabled or disabled. The SDK also collects metrics and sends them to the Unleash API. See all our SDKs
- Unleash Proxy - Sits between frontend/native applications and the Unleash API. Ensures high performance and that you don't expose the full feature toggle configuration to end-users. Read more about Unleash Proxy
To be super fast (we're talking nano-seconds), the client SDK caches all feature toggles and their current configuration in memory. The activation strategies are also implemented in the SDK. This makes it really fast to check if a toggle is on or off because it is just a simple function operating on local state, without the need to poll data from the database.