mirror of
https://github.com/Unleash/unleash.git
synced 2025-07-31 13:47:02 +02:00
docs: update references and names to new SDK nomenclature (#10431)
## About the changes Follow up on https://github.com/Unleash/unleash/pull/10430 this PR adapts documentation. --------- Co-authored-by: Melinda Fekete <melinda.fekete@getunleash.io>
This commit is contained in:
parent
58bd646db0
commit
629624fd1c
@ -7,7 +7,7 @@ export const edgeTokenSchema = {
|
||||
additionalProperties: false,
|
||||
required: ['token', 'projects', 'type'],
|
||||
description:
|
||||
'A representation of a client token, limiting access to [CLIENT](https://docs.getunleash.io/reference/api-tokens-and-client-keys#client-tokens) (used by serverside SDKs) or [FRONTEND](https://docs.getunleash.io/reference/api-tokens-and-client-keys#frontend-tokens) (used by proxy SDKs)',
|
||||
'A representation of a client token, limiting access to [CLIENT](https://docs.getunleash.io/reference/api-tokens-and-client-keys#backend-tokens) (used by serverside SDKs) or [FRONTEND](https://docs.getunleash.io/reference/api-tokens-and-client-keys#frontend-tokens) (used by proxy SDKs)',
|
||||
properties: {
|
||||
projects: {
|
||||
description:
|
||||
@ -19,7 +19,7 @@ export const edgeTokenSchema = {
|
||||
example: ['developerexperience', 'enterprisegrowth'],
|
||||
},
|
||||
type: {
|
||||
description: `The [API token](https://docs.getunleash.io/reference/api-tokens-and-client-keys)'s **type**. Unleash supports three different types of API tokens ([ADMIN](https://docs.getunleash.io/reference/api-tokens-and-client-keys#admin-tokens), [CLIENT](https://docs.getunleash.io/reference/api-tokens-and-client-keys#client-tokens), [FRONTEND](https://docs.getunleash.io/reference/api-tokens-and-client-keys#frontend-tokens)). They all have varying access, so when validating a token it's important to know what kind you're dealing with`,
|
||||
description: `The [API token](https://docs.getunleash.io/reference/api-tokens-and-client-keys)'s **type**. Unleash supports three different types of API tokens ([ADMIN](https://docs.getunleash.io/reference/api-tokens-and-client-keys#admin-tokens), [CLIENT](https://docs.getunleash.io/reference/api-tokens-and-client-keys#backend-tokens), [FRONTEND](https://docs.getunleash.io/reference/api-tokens-and-client-keys#frontend-tokens)). They all have varying access, so when validating a token it's important to know what kind you're dealing with`,
|
||||
type: 'string',
|
||||
enum: Object.values(ApiTokenType),
|
||||
example: 'client',
|
||||
|
@ -0,0 +1,24 @@
|
||||
exports.up = function (db, cb) {
|
||||
db.runSql(
|
||||
`
|
||||
UPDATE permissions SET display_name = 'Create Backend tokens' WHERE permission = 'CREATE_CLIENT_API_TOKEN';
|
||||
UPDATE permissions SET display_name = 'Update Backend tokens' WHERE permission = 'UPDATE_CLIENT_API_TOKEN';
|
||||
UPDATE permissions SET display_name = 'Delete Backend tokens' WHERE permission = 'DELETE_CLIENT_API_TOKEN';
|
||||
UPDATE permissions SET display_name = 'Read Backend tokens' WHERE permission = 'READ_CLIENT_API_TOKEN';
|
||||
|
||||
UPDATE permissions SET display_name = 'Create Frontend tokens' WHERE permission = 'CREATE_FRONTEND_API_TOKEN';
|
||||
UPDATE permissions SET display_name = 'Update Frontend tokens' WHERE permission = 'UPDATE_FRONTEND_API_TOKEN';
|
||||
UPDATE permissions SET display_name = 'Delete Frontend tokens' WHERE permission = 'DELETE_FRONTEND_API_TOKEN';
|
||||
UPDATE permissions SET display_name = 'Read Frontend tokens' WHERE permission = 'READ_FRONTEND_API_TOKEN';
|
||||
`,
|
||||
cb,
|
||||
);
|
||||
};
|
||||
|
||||
exports.down = function (db, cb) {
|
||||
db.runSql(
|
||||
`
|
||||
`,
|
||||
cb,
|
||||
);
|
||||
};
|
@ -14,8 +14,8 @@ Unleash provides a set of APIs to give you full programmatic control over your f
|
||||
|
||||
| API | Used by | Primary use case |
|
||||
|---------------|---------|---|
|
||||
| **Client API** | Server-side SDKs | Fetch feature flag configurations. |
|
||||
| **Frontend API** | Client-side SDKs | Fetch enabled feature flags for a specific [Unleash Context](/reference/unleash-context). |
|
||||
| **Client API** | Backend SDKs | Fetch feature flag configurations. |
|
||||
| **Frontend API** | Frontend SDKs | Fetch enabled feature flags for a specific [Unleash Context](/reference/unleash-context). |
|
||||
| **Admin API** | [Admin UI](/understanding-unleash/unleash-overview#the-unleash-admin-ui), internal tooling, and third-party [integrations](/reference/integrations) | Access and manage all resources within Unleash, such as context, environments, events, metrics, and users. |
|
||||
|
||||
## API authentication and tokens
|
||||
@ -25,24 +25,24 @@ All Unleash APIs require authentication using an [API token](/reference/api-toke
|
||||
### Token types
|
||||
|
||||
Unleash supports four types of API tokens:
|
||||
- **Client tokens**: Used to connect server-side SDKs, Unleash Edge, and the Unleash Proxy to the Client API. Can be scoped to a specific project and environment.
|
||||
- **Frontend tokens**: Used to connect client-side SDKs to the Frontend API or Unleash Edge. These tokens are designed to be publicly accessible and have limited permissions. Can be scoped to a specific project and environment.
|
||||
- **Backend tokens**: Used to connect backend SDKs, Unleash Edge, and the Unleash Proxy to the Client API. Can be scoped to a specific project and environment.
|
||||
- **Frontend tokens**: Used to connect frontend SDKs to the Frontend API or Unleash Edge. These tokens are designed to be publicly accessible and have limited permissions. Can be scoped to a specific project and environment.
|
||||
- **Personal access tokens**: Tied to a specific user account. They are useful for testing, debugging, or providing temporary access to tools and scripts that need to interact with the Admin API.
|
||||
- **Service account tokens**: The recommended method for providing API access to integrations, automation tools, and other non-human users. Service accounts provide a more secure and manageable way to grant Admin API access.
|
||||
|
||||
For an end-to-end Unleash integration, you might need to use multiple token types. For example, when connecting a client-side SDK to Unleash using Unleash Edge, you'll need the following tokens:
|
||||
- A frontend token for the client-side SDK to securely communicate with Unleash Edge.
|
||||
- A client token for Unleash Edge to communicate with the main Unleash server.
|
||||
For an end-to-end Unleash integration, you might need to use multiple token types. For example, when connecting a frontend SDK to Unleash using Unleash Edge, you'll need the following tokens:
|
||||
- A frontend token for the frontend SDK to securely communicate with Unleash Edge.
|
||||
- A backend token for Unleash Edge to communicate with the main Unleash server.
|
||||
|
||||

|
||||

|
||||
|
||||
Ensure that the client token has access to the same project and environment (or a broader scope) as the frontend token.
|
||||
Ensure that the backend token has access to the same project and environment (or a broader scope) as the frontend token.
|
||||
|
||||
### Create an API token
|
||||
|
||||
Depending on your permissions, you can create API tokens in the Unleash Admin UI in four ways:
|
||||
|
||||
- **Admin settings > Access control > API access**: for client or frontend tokens; requires the Admin root role, or a custom root role with API token permissions.
|
||||
- **Admin settings > Access control > API access**: for backend or frontend tokens; requires the Admin root role, or a custom root role with API token permissions.
|
||||
- **Admin settings > Service accounts > New service account**: for creating a service account and assigning a token.
|
||||
- **Settings > API access** [inside a project]: for project-specific client or frontend tokens; permitted for project Members or users with a corresponding root role.
|
||||
- **Profile > View profile settings > Personal API tokens**: for personal access tokens.
|
||||
|
@ -18,7 +18,7 @@ For this tutorial, you'll need the following:
|
||||
|
||||

|
||||
|
||||
The Unleash Server is a **Feature Flag Control Service**, which manages your feature flags and lets you retrieve flag data. Unleash has a UI for creating and managing projects and feature flags. For server-side applications or automated scripts, Unleash exposes an [API](/api-overview) defined by an OpenAPI specification, allowing you to perform these actions programmatically.
|
||||
The Unleash Server is a **Feature Flag Control Service**, which manages your feature flags and lets you retrieve flag data. Unleash has a UI for creating and managing projects and feature flags. For backend applications or automated scripts, Unleash exposes an [API](/api-overview) defined by an OpenAPI specification, allowing you to perform these actions programmatically.
|
||||
|
||||
## 1. Install a local feature flag provider
|
||||
|
||||
|
@ -65,7 +65,7 @@ Select the ‘New API token’ button.
|
||||
|
||||

|
||||
|
||||
Name the API token and select the “Server-side SDK (Client)” token type. You can read more about [Unleash API tokens in our documentation](/reference/api-tokens-and-client-keys#client-tokens).
|
||||
Name the API token and select the “Backend SDK” token type. You can read more about [Unleash API tokens in our documentation](/reference/api-tokens-and-client-keys#backend-tokens).
|
||||
|
||||
.
|
||||
|
||||
|
@ -260,7 +260,7 @@ func main() {
|
||||
}
|
||||
```
|
||||
|
||||
See additional use cases in our [Server-Side SDK with Go](/reference/sdks/go) documentation.
|
||||
See additional use cases in our [Backend SDK with Go](/reference/sdks/go) documentation.
|
||||
|
||||
## 6. Verify the toggle experience
|
||||
|
||||
|
@ -97,7 +97,7 @@ Select the ‘New API token’ button.
|
||||
|
||||

|
||||
|
||||
Name the API token and select the “Client-side SDK” token type, since we’ll be doing our flag evaluation on the client using the iOS SDK. You can read more about [Unleash API tokens in our documentation](/reference/api-tokens-and-client-keys#client-tokens).
|
||||
Name the API token and select the “Frontend SDK” token type, since we’ll be doing our flag evaluation on the client using the iOS SDK. You can read more about [Unleash API tokens in our documentation](/reference/api-tokens-and-client-keys#backend-tokens).
|
||||
|
||||
The token should have access to the “development” environment, as shown in the platform screenshot below.
|
||||
|
||||
@ -184,7 +184,7 @@ Next, replace the `<client_key>` string in the config object with the API token
|
||||
|
||||
As the application is launching, it will make an authenticated call to the Unleash server so we can begin using the `tempUnit` feature flag we created.
|
||||
|
||||
You can check our documentation on [API tokens and client keys](/reference/api-tokens-and-client-keys) for more specifics and see additional use-cases in our [Client-Side SDK with iOS](/reference/sdks/ios-proxy) documentation.
|
||||
You can check our documentation on [API tokens and client keys](/reference/api-tokens-and-client-keys) for more specifics and see additional use-cases in our [Frontend SDK with iOS](/reference/sdks/ios-proxy) documentation.
|
||||
|
||||
Rebuild and run your app. In your console, you will see the feature flag status defaulted to `false` and then `true` when the data has been updated from making the call to Unleash.
|
||||
|
||||
|
@ -99,11 +99,11 @@ Select the ‘New API token’ button.
|
||||
|
||||

|
||||
|
||||
Name the API token and select the “Server-side SDK” token type, since we’ll be doing our flag evaluation on the server using the Java SDK. You can read more about Unleash API tokens here: https://docs.getunleash.io/reference/api-tokens-and-client-keys#client-tokens
|
||||
Name the API token and select the “Backend SDK” token type, since we’ll be doing our flag evaluation on the server using the Java SDK. You can read more about Unleash API tokens here: /reference/api-tokens-and-client-keys#backend-tokens
|
||||
|
||||
The token should have access to the “development” environment, as shown in the platform screenshot below.
|
||||
|
||||

|
||||

|
||||
|
||||
The API token you generated can be managed in the API Access view in your project settings. It will be handy in Step 4.
|
||||
|
||||
@ -165,7 +165,7 @@ Replace the `<API_KEY>` string in the configuration’s apiKey with the API toke
|
||||
|
||||
While the app is running, it will log the enabled status of the endpoint flag we created in our Unleash instance.
|
||||
|
||||
You can check our [API token and client keys documentation](/reference/api-tokens-and-client-keys) for more specifics and see additional use cases in our [Server-Side SDK with Java](/reference/sdks/java) documentation.
|
||||
You can check our [API token and client keys documentation](/reference/api-tokens-and-client-keys) for more specifics and see additional use cases in our [Backend SDK with Java](/reference/sdks/java) documentation.
|
||||
|
||||
To run the app, use the following command:
|
||||
|
||||
|
@ -104,11 +104,11 @@ Select the ‘New API token’ button.
|
||||
|
||||

|
||||
|
||||
Name the API token and select the “Server-side SDK” token type since we’ll be doing our flag evaluation on the server using the Spring Boot SDK. You can read more about [Unleash API tokens](/reference/api-tokens-and-client-keys#client-tokens).
|
||||
Name the API token and select the “Backend SDK” token type since we’ll be doing our flag evaluation on the server using the Spring Boot SDK. You can read more about [Unleash API tokens](/reference/api-tokens-and-client-keys#backend-tokens).
|
||||
|
||||
The token should have access to the “development” environment, as shown in the platform screenshot below.
|
||||
|
||||

|
||||

|
||||
|
||||
We will use the API token in Step 4.
|
||||
|
||||
|
@ -163,7 +163,7 @@ Now, let's connect our project to Unleash so that you can toggle a feature flag
|
||||
You'll need two things:
|
||||
|
||||
- The URL of your Unleash instance's API. It's `http://localhost:4242/api/` for your local version.
|
||||
- A [client API token](/reference/api-tokens-and-client-keys#client-tokens). You can create one inside a project in **Settings > API access**.
|
||||
- A [backend token](/reference/api-tokens-and-client-keys#backend-tokens). You can create one inside a project in **Settings > API access**.
|
||||
|
||||
You can now initialize your Unleash client as follows:
|
||||
|
||||
|
@ -109,7 +109,7 @@ Select the ‘New API token’ button.
|
||||
|
||||

|
||||
|
||||
Name the API token and select the “Server-side SDK” token type, since we’ll be doing our flag evaluation on the server using the Python SDK. You can read more about [Unleash API tokens in our documentation](/reference/api-tokens-and-client-keys#client-tokens).
|
||||
Name the API token and select the “Backend SDK” token type, since we’ll be doing our flag evaluation on the server using the Python SDK. You can read more about [Unleash API tokens in our documentation](/reference/api-tokens-and-client-keys#backend-tokens).
|
||||
|
||||
The token should have access to the “development” environment, as shown in the platform screenshot below.
|
||||
|
||||
@ -167,7 +167,7 @@ The URL will point your app to your Unleash instance through your Docker contain
|
||||
|
||||
Replace the `<API token>` string in the Authorization header with the API token we created on our Unleash instance. This will allow the app to communicate with the Unleash API to use the feature flag we created.
|
||||
|
||||
You can check our [API token and client keys documentation](/reference/api-tokens-and-client-keys) for more specifics and see additional use cases in our [Server-Side SDK with Python](/reference/sdks/python) documentation.
|
||||
You can check our [API token and client keys documentation](/reference/api-tokens-and-client-keys) for more specifics and see additional use cases in our [Backend SDK with Python](/reference/sdks/python) documentation.
|
||||
|
||||
Next, go to your terminal and build the app using this command:
|
||||
|
||||
|
@ -197,7 +197,7 @@ class PostsController < ApplicationController
|
||||
|
||||
Reload your browser and check that you see three blog posts displayed. Turn off the flag in your Unleash instance and reload the page. You should see all the blog posts again.
|
||||
|
||||
See additional use cases in our [Server-Side SDK with Ruby](/reference/sdks/ruby) documentation.
|
||||
See additional use cases in our [Backend SDK with Ruby](/reference/sdks/ruby) documentation.
|
||||
|
||||
> **Note:** An update to a feature flag may take 30 seconds to propagate.
|
||||
|
||||
|
@ -109,7 +109,7 @@ Click on the ‘New API token’ button.
|
||||
|
||||

|
||||
|
||||
Name the API token and connect to the Client-side SDK.
|
||||
Name the API token and connect to the Frontend SDK.
|
||||
|
||||
The token should have access to the “development” environment, as shown in the platform screenshot below.
|
||||
|
||||
@ -174,7 +174,7 @@ Paste in a configuration object:
|
||||
```js
|
||||
const config = {
|
||||
url: "http://localhost:4242/api/frontend", // Your local instance Unleash API URL
|
||||
clientKey: "<client_key>", // Your client-side API token
|
||||
clientKey: "<client_key>", // Your frontend token
|
||||
refreshInterval: 15, // How often (in seconds) the client should poll the proxy for updates
|
||||
appName: "cypress-realworld-app", // The name of your application. It's only used for identifying your application
|
||||
};
|
||||
@ -192,7 +192,7 @@ Next, replace the `<client_key>` string in the config object with the API token
|
||||
|
||||
This configuration object is used to populate the `FlagProvider` component that comes from Unleash and wraps around the application, using the credentials to target the specific feature flag you created for the project.
|
||||
|
||||
You can check our documentation on [API tokens and client keys](/reference/api-tokens-and-client-keys) for more specifics and see additional use-cases in our [Client-Side SDK with React](/reference/sdks/react) documentation.
|
||||
You can check our documentation on [API tokens and client keys](/reference/api-tokens-and-client-keys) for more specifics and see additional use-cases in our [Frontend SDK with React](/reference/sdks/react) documentation.
|
||||
|
||||
## 5. Use the feature flag to rollout a notifications badge
|
||||
|
||||
|
@ -217,7 +217,7 @@ require 'unleash'
|
||||
|
||||
```
|
||||
|
||||
See additional use cases in our [Server-Side SDK with Ruby](/reference/sdks/ruby) documentation.
|
||||
See additional use cases in our [Backend SDK with Ruby](/reference/sdks/ruby) documentation.
|
||||
|
||||
## 6. Verify the toggle experience
|
||||
|
||||
|
@ -69,7 +69,7 @@ Select the ‘New API token’ button or copy an existing token.
|
||||
|
||||

|
||||
|
||||
Name the API token and select the “Server-side SDK (Client)” token type. You can read more about [Unleash API tokens in our documentation](/reference/api-tokens-and-client-keys#client-tokens).
|
||||
Name the API token and select the “Backend SDK” token type. You can read more about [Unleash API tokens in our documentation](/reference/api-tokens-and-client-keys#backend-tokens).
|
||||
|
||||

|
||||
|
||||
|
@ -58,7 +58,7 @@ To target users accordingly, let's create an [activation strategy](/reference/ac
|
||||
Different strategies use different parameters. Predefined strategies are bundled with Unleash. The default strategy is a gradual rollout to 100%, which means that the feature is enabled for all users. In this tutorial, we'll adjust the percentage of users who have access to the feature.
|
||||
|
||||
:::note
|
||||
Activation strategies are defined on the server. For server-side SDKs, activation strategy implementation is done on the client side. For frontend SDKs, the feature is calculated on the server side.
|
||||
Activation strategies are defined on the server. For backend SDKs, activation strategy implementation is done on the client side. For frontend SDKs, the feature is calculated on the server side.
|
||||
:::
|
||||
|
||||
Open your feature flag and click **Add strategy**.
|
||||
|
@ -54,7 +54,7 @@ An important Unleash concept that enables developers to perform a gradual rollou
|
||||
|
||||
Different strategies use different parameters. Predefined strategies are bundled with Unleash. The default strategy is the gradual rollout strategy with 100% rollout, which basically means that the feature is enabled for all users. In this case, we have only enabled the flag in the development environment for all users in the previous section.
|
||||
|
||||
Activation strategies are defined on the server. For server-side SDKs, activation strategy implementation is done on the client side. For frontend SDKs, the feature is calculated on the server side.
|
||||
Activation strategies are defined on the server. For backend SDKs, activation strategy implementation is done on the client side. For frontend SDKs, the feature is calculated on the server side.
|
||||
|
||||
You can configure your gradual rollout strategy using the following parameters in Unleash:
|
||||
|
||||
|
@ -26,9 +26,9 @@ Unleash is fundamentally designed for speed and resilience. Understanding the co
|
||||
### Fast, local feature flag evaluation
|
||||
[SDKs](/reference/sdks) embedded in your applications fetch [feature flag](/reference/feature-toggles) configurations from the Unleash server or [Unleash Edge](/reference/unleash-edge).
|
||||
|
||||
[Server-side SDKs](/reference/sdks#server-side-sdks) perform flag evaluations locally within the application's memory. This eliminates network latency for each evaluation, resulting in extremely fast checks.
|
||||
[Backend SDKs](/reference/sdks#backend-sdks) perform flag evaluations locally within the application's memory. This eliminates network latency for each evaluation, resulting in extremely fast checks.
|
||||
|
||||
[Client-side SDKs](/reference/sdks#client-side-sdks) rely on Unleash Edge as a fast, lightweight caching and evaluation layer closer to the end-user.
|
||||
[Frontend SDKs](/reference/sdks#frontend-sdks) rely on Unleash Edge as a fast, lightweight caching and evaluation layer closer to the end-user.
|
||||
|
||||
### Resilience through caching
|
||||
|
||||
@ -186,7 +186,7 @@ Configure the following:
|
||||
3. Scale up compute resources (API servers, Edge instances if applicable) in the new region as needed to handle the full production load.
|
||||
|
||||
## Scaling with Unleash Edge
|
||||
For organizations with globally distributed users and a high number of [client-side](/reference/sdks#client-side-sdks) flag evaluations (in web applications and mobile apps), relying solely on the Unleash API server can introduce latency for end-users and place significant read load on the API server and database.
|
||||
For organizations with globally distributed users and a high number of [frontend](/reference/sdks#frontend-sdks) flag evaluations (in web applications and mobile apps), relying solely on the Unleash API server can introduce latency for end-users and place significant read load on the API server and database.
|
||||
|
||||
[Unleash Edge](/reference/unleash-edge) acts as a lightweight, globally distributed, read-only caching layer for your feature flag configurations. SDKs connect to the nearest Edge instance instead of directly to the Unleash API server.
|
||||
|
||||
@ -264,7 +264,7 @@ We generally recommend Unleash Cloud for most enterprises due to reduced operati
|
||||
#### How does Unleash ensure fast feature flag checks without slowing down user experience?
|
||||
Unleash achieves speed primarily through how feature flag evaluation works in the [SDKs](/reference/sdks).
|
||||
|
||||
- **Local evaluation**: Your application integrates an Unleash SDK. This SDK periodically fetches flag configurations from the Unleash API or Unleash Edge. In server-side SDKs, the evaluation of which flags apply to a specific user happens instantly within your application's memory using the fetched rules and the context you provide (like user ID, location, etc.). Client-side SDKs can rely on Unleash Edge for fast feature flag evaluation.
|
||||
- **Local evaluation**: Your application integrates an Unleash SDK. This SDK periodically fetches flag configurations from the Unleash API or Unleash Edge. In Backend SDKs, the evaluation of which flags apply to a specific user happens instantly within your application's memory using the fetched rules and the context you provide (like user ID, location, etc.). Frontend SDKs can rely on Unleash Edge for fast feature flag evaluation.
|
||||
- **No network calls per flag check**: Because evaluation is local, there's no network latency added for each feature flag check during a user's request processing. This makes flag evaluation extremely fast.
|
||||
- **SDK caching**: SDKs securely cache the latest known flag configuration. This ensures evaluations continue even if the connection to Unleash is temporarily lost.
|
||||
|
||||
@ -324,5 +324,5 @@ Unleash is extremely scalable, designed to handle traffic volumes well beyond ty
|
||||
|
||||
The exact capacity depends on the evaluation method:
|
||||
|
||||
- **Server-side SDKs**: Flags are evaluated locally in your application, scaling as your application does. A single small Unleash instance can support 7,500 connected [SDKs](/reference/sdks), enabling a **750 trillion evaluations per day** across those connected applications. You can scale further by adding more Unleash instances.
|
||||
- **Client-side SDKs with Unleash Edge**: [Unleash Edge](/reference/unleash-edge) handles flag evaluations and scales horizontally. Performance tests showed 5 Edge instances handling over 11,000 requests per second (RPS), and a single instance configuration capable of managing at least 864 million requests daily.
|
||||
- **Backend SDKs**: Flags are evaluated locally in your application, scaling as your application does. A single small Unleash instance can support 7,500 connected [SDKs](/reference/sdks), enabling a **750 trillion evaluations per day** across those connected applications. You can scale further by adding more Unleash instances.
|
||||
- **Frontend SDKs with Unleash Edge**: [Unleash Edge](/reference/unleash-edge) handles flag evaluations and scales horizontally. Performance tests showed 5 Edge instances handling over 11,000 requests per second (RPS), and a single instance configuration capable of managing at least 864 million requests daily.
|
@ -195,7 +195,7 @@ Protecting data is critical within any software tool. It’s a security best pra
|
||||
|
||||
This is a potential attack surface area that you wouldn’t want to be the root of data breaches or unauthorized access in your system. That’s why Unleash was built in a way where integrating feature flags into your services won’t be a weak link in your organization’s ability to ship software safely.
|
||||
|
||||
With Unleash, you can architect your feature flagging solution in a way that all user data stays within your applications. When using server-side SDKs, user data remains within your application and is never shared with the Unleash server regardless of your setup. For client-side SDKs, you can retain all user data within your applications by either [self-hosting Unleash](/understanding-unleash/hosting-options#), or [self-hosting Unleash Edge](/understanding-unleash/hosting-options#unleash-edge-options). Read more on the [Unleash architecture here](/understanding-unleash/unleash-overview).
|
||||
With Unleash, you can architect your feature flagging solution in a way that all user data stays within your applications. When using backend SDKs, user data remains within your application and is never shared with the Unleash server regardless of your setup. For frontend SDKs, you can retain all user data within your applications by either [self-hosting Unleash](/understanding-unleash/hosting-options#), or [self-hosting Unleash Edge](/understanding-unleash/hosting-options#unleash-edge-options). Read more on the [Unleash architecture here](/understanding-unleash/unleash-overview).
|
||||
|
||||
### Use Unleash Edge for enterprise-grade data privacy
|
||||
|
||||
|
@ -11,8 +11,8 @@ All Unleash APIs require authentication using an [API token](/reference/api-toke
|
||||
### Token types
|
||||
|
||||
Unleash supports four types of API tokens:
|
||||
- **Client tokens**: Used to connect server-side SDKs, Unleash Edge, and the Unleash Proxy to the Client API. Can be scoped to a specific project and environment.
|
||||
- **Frontend tokens**: Used to connect client-side SDKs to the Frontend API or Unleash Edge. These tokens are designed to be publicly accessible and have limited permissions. Can be scoped to a specific project and environment.
|
||||
- **Backend tokens**: Used to connect backend SDKs, Unleash Edge, and the Unleash Proxy to the Client API. Can be scoped to a specific project and environment.
|
||||
- **Frontend tokens**: Used to connect frontend SDKs to the Frontend API or Unleash Edge. These tokens are designed to be publicly accessible and have limited permissions. Can be scoped to a specific project and environment.
|
||||
- **Personal access tokens**: Tied to a specific user account. They are useful for testing, debugging, or providing temporary access to tools and scripts that need to interact with the Admin API.
|
||||
- **Service account tokens**: The recommended method for providing API access to integrations, automation tools, and other non-human users. Service accounts provide a more secure and manageable way to grant Admin API access.
|
||||
|
||||
|
@ -16,7 +16,7 @@ Unleash Proxy is deprecated. Use [Unleash Edge](/reference/unleash-edge) instead
|
||||
|
||||
:::
|
||||
|
||||
The [Unleash Proxy](../reference/unleash-proxy) provides a way for you to consume feature flags in [front-end clients](../reference/sdks#client-side-sdks), such as the [JavaScript Proxy client](../reference/sdks/javascript-browser) and [React Proxy client](../reference/sdks/react).
|
||||
The [Unleash Proxy](../reference/unleash-proxy) provides a way for you to consume feature flags in [front-end clients](../reference/sdks#frontend-sdks), such as the [JavaScript Proxy client](../reference/sdks/javascript-browser) and [React Proxy client](../reference/sdks/react).
|
||||
|
||||
Depending on your setup, the Proxy is most easily run in one of two ways, depending on your situation:
|
||||
|
||||
@ -30,7 +30,7 @@ If you're using a hosted version of Unleash, we can also run the proxy for you.
|
||||
This is what you need before you can run the proxy:
|
||||
|
||||
- A running Unleash server to connect to. You'll need its API path (e.g. `https://app.unleash-hosted.com/demo/api`) to connect the proxy to it.
|
||||
- A [client API token](../reference/api-tokens-and-client-keys#client-tokens) for the proxy to use.
|
||||
- A [backend token](../reference/api-tokens-and-client-keys#backend-tokens) for the proxy to use.
|
||||
- If you're running the Proxy via Docker: [the `docker` command line tool](https://www.docker.com/).
|
||||
- If you're running the Proxy as a Node.js app: [Node.js and its command line tools](https://nodejs.org/).
|
||||
- A [Proxy client key](../reference/api-tokens-and-client-keys#proxy-client-keys). This can be any arbitrary string (for instance: `proxy-client-key`). Use this key when connecting a client SDK to the Proxy.
|
||||
|
@ -40,7 +40,7 @@ For more details on creating feature flags, see [How to create a feature flag](/
|
||||
|
||||
## Connect your application to Unleash
|
||||
|
||||
Next, use one of the client or server-side [SDKs](/reference/sdks) to connect Unleash with your application.
|
||||
Next, use one of the client or backend [SDKs](/reference/sdks) to connect Unleash with your application.
|
||||
|
||||
<details>
|
||||
<summary>Need an example application to test with?</summary>
|
||||
@ -50,7 +50,7 @@ Next, use one of the client or server-side [SDKs](/reference/sdks) to connect Un
|
||||
|
||||
<Tabs groupId="connect-sdk-quickstart">
|
||||
|
||||
<TabItem value="sdk-client-side" label="Connect a client-side SDK">
|
||||
<TabItem value="frontend-sdk" label="Connect a frontend SDK">
|
||||
|
||||
1. **Create an API token**
|
||||
|
||||
@ -84,11 +84,11 @@ unleash.on("synchronized", () => {
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="sdk-server-side" label="Connect a server-side SDK">
|
||||
<TabItem value="backend-sdk" label="Connect a backend SDK">
|
||||
|
||||
1. **Create an API token**
|
||||
|
||||
In the Unleash Admin UI, create a [client API token](/reference/api-tokens-and-client-keys#client-tokens) in **Admin settings > Access control > API access**.
|
||||
In the Unleash Admin UI, create a [backend token](/reference/api-tokens-and-client-keys#backend-tokens) in **Admin settings > Access control > API access**.
|
||||
2. **Get your Unleash API URL**
|
||||
|
||||
Find the base URL of your Unleash Cloud instance (for example, `https://us.app.unleash-hosted.com/some-instance-id`). Your API URL is this base URL with `/api` appended to it.
|
||||
|
@ -66,7 +66,7 @@ These parts turn the constraint into an expression that evaluates to true or fal
|
||||
|
||||
#### Constraint operators
|
||||
|
||||
Constraint operators help you define the conditional statements that get evaluated as part of the constraint. [Basic operators](#basic-operators) are available in all versions and SDKs. All other operators require Unleash version 4.9+ and [SDK compatibility](/reference/sdks#feature-compatibility-in-server-side-sdks).
|
||||
Constraint operators help you define the conditional statements that get evaluated as part of the constraint. [Basic operators](#basic-operators) are available in all versions and SDKs. All other operators require Unleash version 4.9+ and [SDK compatibility](/reference/sdks#feature-compatibility-in-backend-sdks).
|
||||
|
||||
All constraints can be negated. For example:
|
||||
|
||||
@ -132,7 +132,7 @@ The value must start with and contain at least major, minor, and patch versions.
|
||||
|
||||
#### Best practices
|
||||
|
||||
Server-side SDKs fetch the full feature flag configuration associated with your API key from Unleash. You can use API keys scoped to specific projects or environments to optimize payload size.
|
||||
Backend SDKs fetch the full feature flag configuration associated with your API key from Unleash. You can use API keys scoped to specific projects or environments to optimize payload size.
|
||||
|
||||
However, every value that you add to your feature flag constraints, increases the payload size. We recommend avoiding large constraint value lists. For example, instead of adding many user IDs or emails to the constraint value list, consider what properties those users share. This typically helps define and use a [custom context field](/reference/unleash-context#custom-context-fields) instead.
|
||||
|
||||
@ -153,7 +153,7 @@ To add an activation strategy with a constraint to a feature flag, do the follow
|
||||
|
||||
Activation strategies are defined on the server but implemented client-side. The client determines whether a feature should be enabled based on the activation strategies.
|
||||
|
||||
All [server-side client SDKs](../reference/sdks#server-side-sdks) and [Unleash Edge](../reference/unleash-edge) implement the default activation strategy. The [front-end client SDKs](../reference/sdks#client-side-sdks) do not perform evaluations themselves. Instead, they rely on [Unleash Edge](../reference/unleash-edge) to handle the implementation and evaluation.
|
||||
All [backend SDKs](../reference/sdks#backend-sdks) and [Unleash Edge](../reference/unleash-edge) implement the default activation strategy. The [frontend SDKs](../reference/sdks#frontend-sdks) do not perform evaluations themselves. Instead, they rely on [Unleash Edge](../reference/unleash-edge) to handle the implementation and evaluation.
|
||||
|
||||
When using strategies with constraints, the client must provide the current [Unleash context](unleash-context) to the flag evaluation function for the evaluation to be done correctly. All official Unleash client SDKs support the option to pass dynamic context values to the `isEnabled()` function (or the SDK's equivalent).
|
||||
|
||||
|
@ -12,36 +12,36 @@ import SearchPriority from '@site/src/components/SearchPriority';
|
||||
Unleash uses API keys to facilitate communication between consuming clients such as [SDKs](../reference/sdks), [Unleash Edge](../reference/unleash-edge), or other tools and automation.
|
||||
|
||||
Unleash supports the following types of API tokens:
|
||||
- [Client tokens](#client-tokens) for connecting [server-side client SDKs](../reference/sdks#server-side-sdks), [Unleash Edge](../reference/unleash-edge), and [Unleash Proxy](../reference/unleash-proxy) to Unleash.
|
||||
- [Frontend tokens](#frontend-tokens) for connecting [client-side SDKs](../reference/sdks#client-side-sdks) to Unleash using the [Frontend API](../reference/front-end-api) or [Unleash Edge](../reference/unleash-edge).
|
||||
- [Backend tokens](#backend-tokens) for connecting [backend SDKs](../reference/sdks#backend-sdks), [Unleash Edge](../reference/unleash-edge), and [Unleash Proxy](../reference/unleash-proxy) to Unleash.
|
||||
- [Frontend tokens](#frontend-tokens) for connecting [frontend SDKs](../reference/sdks#frontend-sdks) to Unleash using the [Frontend API](../reference/front-end-api) or [Unleash Edge](../reference/unleash-edge).
|
||||
- [Personal access tokens](#personal-access-tokens) for testing and debugging or providing temporary access to an automation tool.
|
||||
- [Service account tokens](/reference/service-accounts) for providing API access to integrations or automation tools.
|
||||
|
||||
To connect a client-side SDK to Unleash using Unleash Edge, you need both a [client](#client-tokens) and [frontend token](#frontend-tokens). See [Connect a client-side SDK to Unleash using Edge](#connect-a-client-side-sdk-to-unleash-using-edge) for an example.
|
||||
To connect a frontend SDK to Unleash using Unleash Edge, you need both a [backend](#backend-tokens) and [frontend token](#frontend-tokens). See [Connect a frontend SDK to Unleash using Edge](#connect-a-frontend-sdk-to-unleash-using-edge) for an example.
|
||||
|
||||
## API token types
|
||||
|
||||
### Client tokens
|
||||
### Backend tokens
|
||||
|
||||
Client tokens are intended for use in [server-side client SDKs](../reference/sdks#server-side-sdks), [Unleash Edge](../reference/unleash-edge), and [Unleash Proxy](../reference/unleash-proxy) to grant the permissions to:
|
||||
Backend tokens are intended for use in [backend SDKs](../reference/sdks#backend-sdks), [Unleash Edge](../reference/unleash-edge), and [Unleash Proxy](../reference/unleash-proxy) to grant the permissions to:
|
||||
- Reading feature flag information
|
||||
- Registering applications with the Unleash server
|
||||
- Sending usage metrics
|
||||
|
||||
Client tokens are scoped to one or more projects and a single environment. When creating a client token, you can give it access to a specific list of projects or to all current or future projects. Client tokens are secrets and must not be exposed to end users.
|
||||
Backend tokens are scoped to one or more projects and a single environment. When creating a backend token, you can give it access to a specific list of projects or to all current or future projects. Backend tokens are secrets and must not be exposed to end users.
|
||||
|
||||
Client tokens cannot be used in frontend SDKs; use [frontend tokens](#frontend-tokens) instead.
|
||||
Backend tokens cannot be used in frontend SDKs; use [frontend tokens](#frontend-tokens) instead.
|
||||
|
||||
### Frontend tokens
|
||||
|
||||
Use frontend tokens for connecting [frontend SDKs](../reference/sdks#client-side-sdks) to Unleash using the [Unleash Frontend API](./front-end-api) or [Unleash Edge](../reference/unleash-edge). They grant the user permission to:
|
||||
Use frontend tokens for connecting [frontend SDKs](../reference/sdks#frontend-sdks) to Unleash using the [Unleash Frontend API](./front-end-api) or [Unleash Edge](../reference/unleash-edge). They grant the user permission to:
|
||||
- Reading enabled flags for a given context
|
||||
- Registering applications with the Unleash server
|
||||
- Sending usage metrics
|
||||
|
||||
Frontend tokens are scoped to one or more projects and a single environment. When creating a frontend token, you can give it access to a specific list of projects or to all current or future projects. Frontend tokens are not considered secret and are safe to expose client-side.
|
||||
|
||||
Frontend tokens cannot be used in server-side SDKs; use [client tokens](#client-tokens) instead.
|
||||
Frontend tokens cannot be used in backend SDKs; use [backend tokens](#backend-tokens) instead.
|
||||
|
||||
### Personal access tokens
|
||||
|
||||
@ -52,7 +52,7 @@ When you use a personal access token to modify resources, the events record the
|
||||
|
||||
Personal access tokens with a lifetime expire and stop working after their expiration date. Although you can set the token to not expire, we recommend using tokens with expiration dates to follow security best practices.
|
||||
|
||||
Personal access tokens are not suitable for client SDKs, as they are not bound to an environment, they may expire, or their permissions may change. Use [client tokens](#client-tokens) instead.
|
||||
Personal access tokens are not suitable for use in SDKs, as they are not bound to an environment, they may expire, or their permissions may change.
|
||||
|
||||
### Service account tokens
|
||||
|
||||
@ -142,20 +142,20 @@ be44368985f7fb3237c584ef86f3d6bdada42ddbd63a019d26955178
|
||||
## Create an API token
|
||||
|
||||
Depending on your [permissions](#api-token-permissions), you can create API tokens in the Unleash Admin UI in four ways:
|
||||
- **Admin settings > Access control > API access**: for client or frontend tokens; requires the Admin root role, or a custom root role with [API token permissions](#api-token-permissions).
|
||||
- **Admin settings > Access control > API access**: for backend or frontend tokens; requires the Admin root role, or a custom root role with [API token permissions](#api-token-permissions).
|
||||
- **Admin settings > Service accounts > New service account**: for creating a service account and assigning a token.
|
||||
- **Settings > API access** inside a project: for project-specific client or frontend tokens; permitted for project Members or users with a [corresponding root role](#api-token-permissions).
|
||||
- **Settings > API access** inside a project: for project-specific backend or frontend tokens; permitted for project Members or users with a [corresponding root role](#api-token-permissions).
|
||||
- **Profile > View profile settings > Personal API tokens**: for [personal access tokens](#personal-access-tokens).
|
||||
|
||||
## Connect a client-side SDK to Unleash using Edge
|
||||
## Connect a frontend SDK to Unleash using Edge
|
||||
|
||||
To connect a client-side SDK to Unleash using Unleash Edge, you need both a [client](#client-tokens) and [frontend token](#frontend-tokens):
|
||||
- The client-side SDK needs a frontend token to communicate with Edge.
|
||||
- Edge needs a client token to communicate with the Unleash server.
|
||||
To connect a frontend SDK to Unleash using Unleash Edge, you need both a [backend](#backend-tokens) and [frontend token](#frontend-tokens):
|
||||
- The frontend SDK needs a frontend token to communicate with Edge.
|
||||
- Edge needs a backend token to communicate with the Unleash server.
|
||||
|
||||
Ensure that the client token has at least the same project and environment scope as the frontend token.
|
||||
Ensure that the backend token has at least the same project and environment scope as the frontend token.
|
||||
|
||||

|
||||

|
||||
|
||||
|
||||
## Proxy client keys
|
||||
@ -166,7 +166,7 @@ Unleash Proxy is in maintenance mode. Use [Unleash Edge](../reference/unleash-ed
|
||||
|
||||
:::
|
||||
|
||||
You can use proxy client keys to connect [frontend SDKs](../reference/sdks#client-side-sdks) to [Unleash Proxy](../reference/unleash-proxy). Proxy client keys are not considered a secret and are safe to expose client-side.
|
||||
You can use proxy client keys to connect [frontend SDKs](../reference/sdks#frontend-sdks) to [Unleash Proxy](../reference/unleash-proxy). Proxy client keys are not considered a secret and are safe to expose client-side.
|
||||
|
||||
Proxy client keys are arbitrary strings that you provide the Unleash proxy with on startup. They can be any string you choose, and you create them yourself.
|
||||
|
||||
|
@ -617,7 +617,7 @@ Transfer-Encoding: chunked
|
||||
|
||||
:::caution
|
||||
|
||||
From 4.21 variants are tied to an environment. Check our Open API docs for the up-to-date docs: https://docs.getunleash.io/reference/api/unleash/features
|
||||
From 4.21 variants are tied to an environment. Check our [Open API docs](/reference/api/unleash/features) for the up-to-date documentation.
|
||||
|
||||
This endpoint affects all environments at once.
|
||||
|
||||
|
@ -54,12 +54,12 @@ All values have an **empty string (`""`) as the default value**. As such, if you
|
||||
|
||||
:::note
|
||||
|
||||
If you have not implemented the strategy in your client SDK, the check will always return `false` because the client doesn't recognize the strategy.
|
||||
If you have not implemented the strategy in your backend SDK, the check will always return `false` because the client doesn't recognize the strategy.
|
||||
|
||||
:::
|
||||
|
||||
While custom strategies are _defined_ on the Unleash server, they must be _implemented_ on the client. All official Unleash client SDKs provide a way for you to implement custom strategies.
|
||||
While custom strategies are _defined_ on the Unleash server, they must be _implemented_ on the client. All official Unleash backend SDKs provide a way for you to implement custom strategies.
|
||||
|
||||
The exact method for implementing custom strategies will vary between SDKs, but the server SDKs follow the same patterns. For front-end client SDKs ([Android](/docs/generated/sdks/client-side/android-proxy.md), [JavaScript](/docs/generated/sdks/client-side/javascript-browser.md), [React](/docs/generated/sdks/client-side/react.md), [iOS](/docs/generated/sdks/client-side/ios-proxy.md), [Flutter](/docs/generated/sdks/client-side/flutter.md)), the custom activation strategy must be implemented in the [Unleash Proxy](../generated/unleash-proxy.md).
|
||||
The exact method for implementing custom strategies will vary between SDKs, but the backend SDKs follow the same patterns. For frontend SDKs ([Android](/docs/generated/sdks/frontend/android-proxy.md), [JavaScript](/docs/generated/sdks/frontend/javascript-browser.md), [React](/docs/generated/sdks/frontend/react.md), [iOS](/docs/generated/sdks/frontend/ios-proxy.md), [Flutter](/docs/generated/sdks/frontend/flutter.md)), the custom activation strategy must be implemented in the [Unleash Proxy](../generated/unleash-proxy.md).
|
||||
|
||||
When implementing a strategy in your client, you will get access to the strategy's parameters and the Unleash Context. Again, refer to your specific SDK's documentation for more details.
|
||||
|
@ -132,7 +132,7 @@ If an archived feature is revived, it starts a new lifecycle with a new [Define]
|
||||
|
||||
**Plan**: [Pro](/availability#plans) and [Enterprise](https://www.getunleash.io/pricing)
|
||||
|
||||
**Unleash version**: `5.7+` | **Unleash Edge version**: `13.1+` | **Unleash Proxy version**: `0.18+`. Requires [SDK compatibility](../reference/sdks#feature-compatibility-in-server-side-sdks) for variants.
|
||||
**Unleash version**: `5.7+` | **Unleash Edge version**: `13.1+` | **Unleash Proxy version**: `0.18+`. Requires [SDK compatibility](../reference/sdks#feature-compatibility-in-backend-sdks) for variants.
|
||||
:::
|
||||
|
||||
Feature flag dependencies define a relationship between feature flags. Each feature flag can have one parent, but multiple child flags can share the same parent.
|
||||
|
@ -9,7 +9,7 @@ import SearchPriority from '@site/src/components/SearchPriority';
|
||||
|
||||
:::note Availability
|
||||
|
||||
**Version**: `4.7+`. Requires [SDK compatibility](../reference/sdks#feature-compatibility-in-server-side-sdks).
|
||||
**Version**: `4.7+`. Requires [SDK compatibility](../reference/sdks#feature-compatibility-in-backend-sdks).
|
||||
|
||||
:::
|
||||
|
||||
|
@ -75,14 +75,14 @@ You can assign the following root permissions:
|
||||
|
||||
| Permission Name | Description |
|
||||
|----------------------------|-------------------------------------------|
|
||||
| Read frontend API tokens | View [frontend API tokens](./api-tokens-and-client-keys#frontend-tokens). |
|
||||
| Create frontend API tokens | Create frontend API tokens. |
|
||||
| Update frontend API tokens | Update frontend API tokens. |
|
||||
| Delete frontend API tokens | Delete frontend API tokens. |
|
||||
| Read client API tokens | View [client API tokens](./api-tokens-and-client-keys#client-tokens). |
|
||||
| Create client API tokens | Create client API tokens. |
|
||||
| Update client API tokens | Update client API tokens. |
|
||||
| Delete client API tokens | Delete client API tokens. |
|
||||
| Read Frontend tokens | View [Frontend tokens](./api-tokens-and-client-keys#frontend-tokens). |
|
||||
| Create Frontend tokens | Create Frontend tokens. |
|
||||
| Update Frontend tokens | Update Frontend tokens. |
|
||||
| Delete Frontend tokens | Delete Frontend tokens. |
|
||||
| Read Backend tokens | View [Backend tokens](./api-tokens-and-client-keys#backend-tokens). |
|
||||
| Create Backend tokens | Create Backend tokens. |
|
||||
| Update Backend tokens | Update Backend tokens. |
|
||||
| Delete Backend tokens | Delete Backend tokens. |
|
||||
|
||||
#### Application permissions
|
||||
|
||||
|
@ -14,49 +14,49 @@ Unleash provides official SDKs for a number of programming languages. Our commun
|
||||
|
||||
## Official SDKs
|
||||
|
||||
### Server-side SDKs
|
||||
### Backend SDKs
|
||||
|
||||
Server‑side SDKs run in backend services. They communicate with Unleash or [Unleash Edge](./unleash-edge) using the [Client API](../understanding-unleash/unleash-overview#client-api) and require a [client token](./api-tokens-and-client-keys#client-tokens).
|
||||
Server-side SDKs perform the flag evaluation locally, meaning all user data is retained within the SDK.
|
||||
Backend SDKs run in backend services. They communicate with Unleash or [Unleash Edge](./unleash-edge) using the [Client API](../understanding-unleash/unleash-overview#client-api) and require a [client token](./api-tokens-and-client-keys#backend-tokens).
|
||||
Backend SDKs perform the flag evaluation locally, meaning all user data is retained within the SDK.
|
||||
|
||||
Unleash offers the following server-side SDKs:
|
||||
Unleash offers the following backend SDKs:
|
||||
|
||||
- [Go SDK](/docs/generated/sdks/server-side/go.md)
|
||||
- [Java SDK](/docs/generated/sdks/server-side/java.md)
|
||||
- [Node.js SDK](/docs/generated/sdks/server-side/node.md)
|
||||
- [PHP SDK](/docs/generated/sdks/server-side/php.md)
|
||||
- [Python SDK](/docs/generated/sdks/server-side/python.md)
|
||||
- [Ruby SDK](/docs/generated/sdks/server-side/ruby.md)
|
||||
- [Rust SDK](/docs/generated/sdks/server-side/rust.md)
|
||||
- [.NET SDK](/docs/generated/sdks/server-side/dotnet.md)
|
||||
- [Go SDK](/docs/generated/sdks/backend/go.md)
|
||||
- [Java SDK](/docs/generated/sdks/backend/java.md)
|
||||
- [Node.js SDK](/docs/generated/sdks/backend/node.md)
|
||||
- [PHP SDK](/docs/generated/sdks/backend/php.md)
|
||||
- [Python SDK](/docs/generated/sdks/backend/python.md)
|
||||
- [Ruby SDK](/docs/generated/sdks/backend/ruby.md)
|
||||
- [Rust SDK](/docs/generated/sdks/backend/rust.md)
|
||||
- [.NET SDK](/docs/generated/sdks/backend/dotnet.md)
|
||||
|
||||
### Client-side SDKs
|
||||
### Frontend SDKs
|
||||
|
||||
Client-side SDKs are used in frontend and mobile applications. They communicate with Unleash or [Unleash Edge](./unleash-edge) through the [Frontend API](./front-end-api) and require a [frontend token](./api-tokens-and-client-keys#frontend-tokens). Unlike server-side SDKs, client-side SDKs do not perform the flag evaluation locally. Instead, they fetch all enabled feature flags for a given [Unleash Context](./unleash-context). The flag evaluation happens either in [Unleash Edge](./unleash-edge), or in the Unleash server, when using the [Frontend API](./front-end-api) directly.
|
||||
Frontend SDKs are used in frontend and mobile applications. They communicate with Unleash or [Unleash Edge](./unleash-edge) through the [Frontend API](./front-end-api) and require a [frontend token](./api-tokens-and-client-keys#frontend-tokens). Unlike backend SDKs, frontend SDKs do not perform the flag evaluation locally. Instead, they fetch all enabled feature flags for a given [Unleash Context](./unleash-context). The flag evaluation happens either in [Unleash Edge](./unleash-edge), or in the Unleash server, when using the [Frontend API](./front-end-api) directly.
|
||||
|
||||
When the SDK initializes, it sets up an in-memory repository and retrieves a list of all enabled flags and their variants in a single request. Once fetched, the SDK serves flag values from memory, without making additional requests. It periodically refreshes the list of enabled flags to keep the data up to date.
|
||||
|
||||
Unleash offers the following client-side SDKs:
|
||||
Unleash offers the following frontend SDKs:
|
||||
|
||||
- [Android SDK](/docs/generated/sdks/client-side/android-proxy.md)
|
||||
- [Flutter SDK](/docs/generated/sdks/client-side/flutter.md)
|
||||
- [iOS SDK](/docs/generated/sdks/client-side/ios-proxy.md)
|
||||
- [JavaScript SDK](/docs/generated/sdks/client-side/javascript-browser.md)
|
||||
- [Next.js](/docs/generated/sdks/client-side/next-js.md)
|
||||
- [React SDK](/docs/generated/sdks/client-side/react.md)
|
||||
- [Svelte SDK](/docs/generated/sdks/client-side/svelte.md)
|
||||
- [Vue SDK](/docs/generated/sdks/client-side/vue.md)
|
||||
- [Android SDK](/docs/generated/sdks/frontend/android-proxy.md)
|
||||
- [Flutter SDK](/docs/generated/sdks/frontend/flutter.md)
|
||||
- [iOS SDK](/docs/generated/sdks/frontend/ios-proxy.md)
|
||||
- [JavaScript SDK](/docs/generated/sdks/frontend/javascript-browser.md)
|
||||
- [Next.js](/docs/generated/sdks/frontend/next-js.md)
|
||||
- [React SDK](/docs/generated/sdks/frontend/react.md)
|
||||
- [Svelte SDK](/docs/generated/sdks/frontend/svelte.md)
|
||||
- [Vue SDK](/docs/generated/sdks/frontend/vue.md)
|
||||
|
||||
### Feature compatibility in server-side SDKs
|
||||
### Feature compatibility in backend SDKs
|
||||
|
||||
The following tables show which features are supported by each server-side SDK. Some features are only applicable to specific SDKs, depending on the programming language or how the client is implemented.
|
||||
The following tables show which features are supported by each backend SDK. Some features are only applicable to specific SDKs, depending on the programming language or how the client is implemented.
|
||||
|
||||
**Symbol reference**
|
||||
|
||||
✅ Implemented | ❌ Not supported | ⭕ Not implemented, but under consideration | **N/A** Not applicable to this SDK
|
||||
|
||||
#### Initialization
|
||||
| Capability | [Java](/docs/generated/sdks/server-side/java.md) | [Node.js](/docs/generated/sdks/server-side/node.md) | [Go](/docs/generated/sdks/server-side/go.md) | [Python](/docs/generated/sdks/server-side/python.md) | [Ruby](/docs/generated/sdks/server-side/ruby.md) | [.NET](/docs/generated/sdks/server-side/dotnet.md) | [PHP](/docs/generated/sdks/server-side/php.md) | [Rust](/docs/generated/sdks/server-side/rust.md) |
|
||||
| Capability | [Java](/docs/generated/sdks/backend/java.md) | [Node.js](/docs/generated/sdks/backend/node.md) | [Go](/docs/generated/sdks/backend/go.md) | [Python](/docs/generated/sdks/backend/python.md) | [Ruby](/docs/generated/sdks/backend/ruby.md) | [.NET](/docs/generated/sdks/backend/dotnet.md) | [PHP](/docs/generated/sdks/backend/php.md) | [Rust](/docs/generated/sdks/backend/rust.md) |
|
||||
| --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: |
|
||||
| Async initialization | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ |
|
||||
| Block until synchronized | ✅ | ✅ | ✅ | ⭕ | ⭕ | ✅ | ✅ | ⭕ |
|
||||
@ -66,13 +66,13 @@ The following tables show which features are supported by each server-side SDK.
|
||||
| Flag Query: `project_name` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | N/A | ⭕ |
|
||||
|
||||
#### Custom headers
|
||||
| Capability | [Java](/docs/generated/sdks/server-side/java.md) | [Node.js](/docs/generated/sdks/server-side/node.md) | [Go](/docs/generated/sdks/server-side/go.md) | [Python](/docs/generated/sdks/server-side/python.md) | [Ruby](/docs/generated/sdks/server-side/ruby.md) | [.NET](/docs/generated/sdks/server-side/dotnet.md) | [PHP](/docs/generated/sdks/server-side/php.md) | [Rust](/docs/generated/sdks/server-side/rust.md) |
|
||||
| Capability | [Java](/docs/generated/sdks/backend/java.md) | [Node.js](/docs/generated/sdks/backend/node.md) | [Go](/docs/generated/sdks/backend/go.md) | [Python](/docs/generated/sdks/backend/python.md) | [Ruby](/docs/generated/sdks/backend/ruby.md) | [.NET](/docs/generated/sdks/backend/dotnet.md) | [PHP](/docs/generated/sdks/backend/php.md) | [Rust](/docs/generated/sdks/backend/rust.md) |
|
||||
| --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: |
|
||||
| static | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ |
|
||||
| function | ✅ | ✅ | ⭕ | ✅ | ✅ (4.3) | ✅ | ✅ | ⭕ |
|
||||
|
||||
#### Built-in strategies
|
||||
| Capability | [Java](/docs/generated/sdks/server-side/java.md) | [Node.js](/docs/generated/sdks/server-side/node.md) | [Go](/docs/generated/sdks/server-side/go.md) | [Python](/docs/generated/sdks/server-side/python.md) | [Ruby](/docs/generated/sdks/server-side/ruby.md) | [.NET](/docs/generated/sdks/server-side/dotnet.md) | [PHP](/docs/generated/sdks/server-side/php.md) | [Rust](/docs/generated/sdks/server-side/rust.md) |
|
||||
| Capability | [Java](/docs/generated/sdks/backend/java.md) | [Node.js](/docs/generated/sdks/backend/node.md) | [Go](/docs/generated/sdks/backend/go.md) | [Python](/docs/generated/sdks/backend/python.md) | [Ruby](/docs/generated/sdks/backend/ruby.md) | [.NET](/docs/generated/sdks/backend/dotnet.md) | [PHP](/docs/generated/sdks/backend/php.md) | [Rust](/docs/generated/sdks/backend/rust.md) |
|
||||
| --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: |
|
||||
| [Gradual rollout](./activation-strategies) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
|
||||
| [Gradual rollout with custom stickiness](./stickiness#custom-stickiness) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ |
|
||||
@ -80,60 +80,60 @@ The following tables show which features are supported by each server-side SDK.
|
||||
| [IP](./predefined-strategy-types#ips) with CIDR syntax | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | ✅ | ✅ |
|
||||
|
||||
#### Custom strategies
|
||||
All server-side SDKs have basic support.
|
||||
All backend SDKs have basic support.
|
||||
|
||||
#### Strategy constraints
|
||||
All server-side SDKs have support for the basic operators (`IN`, `NOT_IN`).
|
||||
All backend SDKs have support for the basic operators (`IN`, `NOT_IN`).
|
||||
|
||||
| Capability | [Java](/docs/generated/sdks/server-side/java.md) | [Node.js](/docs/generated/sdks/server-side/node.md) | [Go](/docs/generated/sdks/server-side/go.md) | [Python](/docs/generated/sdks/server-side/python.md) | [Ruby](/docs/generated/sdks/server-side/ruby.md) | [.NET](/docs/generated/sdks/server-side/dotnet.md) | [PHP](/docs/generated/sdks/server-side/php.md) | [Rust](/docs/generated/sdks/server-side/rust.md) |
|
||||
| Capability | [Java](/docs/generated/sdks/backend/java.md) | [Node.js](/docs/generated/sdks/backend/node.md) | [Go](/docs/generated/sdks/backend/go.md) | [Python](/docs/generated/sdks/backend/python.md) | [Ruby](/docs/generated/sdks/backend/ruby.md) | [.NET](/docs/generated/sdks/backend/dotnet.md) | [PHP](/docs/generated/sdks/backend/php.md) | [Rust](/docs/generated/sdks/backend/rust.md) |
|
||||
| --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: |
|
||||
| [Advanced operators](./activation-strategies#advanced-operators) | ✅ (5.1) | ✅ (3.12) | ✅ (3.3) | ✅ (5.1) | ✅ (4.2) | ✅ (2.1) | ✅ (1.3.1) | ⭕ |
|
||||
|
||||
|
||||
#### Unleash Context
|
||||
|
||||
Static fields (`environment`, `appName`), defined fields, and custom properties are supported in all server-side SDKs.
|
||||
Static fields (`environment`, `appName`), defined fields, and custom properties are supported in all backend SDKs.
|
||||
|
||||
#### `isEnabled` implementation
|
||||
| Capability | [Java](/docs/generated/sdks/server-side/java.md) | [Node.js](/docs/generated/sdks/server-side/node.md) | [Go](/docs/generated/sdks/server-side/go.md) | [Python](/docs/generated/sdks/server-side/python.md) | [Ruby](/docs/generated/sdks/server-side/ruby.md) | [.NET](/docs/generated/sdks/server-side/dotnet.md) | [PHP](/docs/generated/sdks/server-side/php.md) | [Rust](/docs/generated/sdks/server-side/rust.md) |
|
||||
| Capability | [Java](/docs/generated/sdks/backend/java.md) | [Node.js](/docs/generated/sdks/backend/node.md) | [Go](/docs/generated/sdks/backend/go.md) | [Python](/docs/generated/sdks/backend/python.md) | [Ruby](/docs/generated/sdks/backend/ruby.md) | [.NET](/docs/generated/sdks/backend/dotnet.md) | [PHP](/docs/generated/sdks/backend/php.md) | [Rust](/docs/generated/sdks/backend/rust.md) |
|
||||
| --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: |
|
||||
| Can take context and override fallback value | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
|
||||
| Fallback function | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | ⭕ | ⭕ |
|
||||
|
||||
#### Strategy variants
|
||||
|
||||
| Capability | [Java](/docs/generated/sdks/server-side/java.md) | [Node.js](/docs/generated/sdks/server-side/node.md) | [Go](/docs/generated/sdks/server-side/go.md) | [Python](/docs/generated/sdks/server-side/python.md) | [Ruby](/docs/generated/sdks/server-side/ruby.md) | [.NET](/docs/generated/sdks/server-side/dotnet.md) | [PHP](/docs/generated/sdks/server-side/php.md) | [Rust](/docs/generated/sdks/server-side/rust.md) |
|
||||
| Capability | [Java](/docs/generated/sdks/backend/java.md) | [Node.js](/docs/generated/sdks/backend/node.md) | [Go](/docs/generated/sdks/backend/go.md) | [Python](/docs/generated/sdks/backend/python.md) | [Ruby](/docs/generated/sdks/backend/ruby.md) | [.NET](/docs/generated/sdks/backend/dotnet.md) | [PHP](/docs/generated/sdks/backend/php.md) | [Rust](/docs/generated/sdks/backend/rust.md) |
|
||||
| --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: |
|
||||
| [Strategy variants](./strategy-variants) and [custom stickiness](./stickiness#custom-stickiness) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ |
|
||||
|
||||
|
||||
#### Local backup
|
||||
| Capability | [Java](/docs/generated/sdks/server-side/java.md) | [Node.js](/docs/generated/sdks/server-side/node.md) | [Go](/docs/generated/sdks/server-side/go.md) | [Python](/docs/generated/sdks/server-side/python.md) | [Ruby](/docs/generated/sdks/server-side/ruby.md) | [.NET](/docs/generated/sdks/server-side/dotnet.md) | [PHP](/docs/generated/sdks/server-side/php.md) | [Rust](/docs/generated/sdks/server-side/rust.md) |
|
||||
| Capability | [Java](/docs/generated/sdks/backend/java.md) | [Node.js](/docs/generated/sdks/backend/node.md) | [Go](/docs/generated/sdks/backend/go.md) | [Python](/docs/generated/sdks/backend/python.md) | [Ruby](/docs/generated/sdks/backend/ruby.md) | [.NET](/docs/generated/sdks/backend/dotnet.md) | [PHP](/docs/generated/sdks/backend/php.md) | [Rust](/docs/generated/sdks/backend/rust.md) |
|
||||
| --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: |
|
||||
| File-based local backup | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ |
|
||||
|
||||
#### Metrics and impression data
|
||||
| Capability | [Java](/docs/generated/sdks/server-side/java.md) | [Node.js](/docs/generated/sdks/server-side/node.md) | [Go](/docs/generated/sdks/server-side/go.md) | [Python](/docs/generated/sdks/server-side/python.md) | [Ruby](/docs/generated/sdks/server-side/ruby.md) | [.NET](/docs/generated/sdks/server-side/dotnet.md) | [PHP](/docs/generated/sdks/server-side/php.md) | [Rust](/docs/generated/sdks/server-side/rust.md) |
|
||||
| Capability | [Java](/docs/generated/sdks/backend/java.md) | [Node.js](/docs/generated/sdks/backend/node.md) | [Go](/docs/generated/sdks/backend/go.md) | [Python](/docs/generated/sdks/backend/python.md) | [Ruby](/docs/generated/sdks/backend/ruby.md) | [.NET](/docs/generated/sdks/backend/dotnet.md) | [PHP](/docs/generated/sdks/backend/php.md) | [Rust](/docs/generated/sdks/backend/rust.md) |
|
||||
| --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: |
|
||||
| Usage metrics | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
|
||||
| [Impression data](./impression-data) | ✅ | ✅ | ✅ | ✅ | ⭕ | ✅ | ✅ | ⭕ |
|
||||
|
||||
#### Bootstrap
|
||||
| Capability | [Java](/docs/generated/sdks/server-side/java.md) | [Node.js](/docs/generated/sdks/server-side/node.md) | [Go](/docs/generated/sdks/server-side/go.md) | [Python](/docs/generated/sdks/server-side/python.md) | [Ruby](/docs/generated/sdks/server-side/ruby.md) | [.NET](/docs/generated/sdks/server-side/dotnet.md) | [PHP](/docs/generated/sdks/server-side/php.md) | [Rust](/docs/generated/sdks/server-side/rust.md) |
|
||||
| Capability | [Java](/docs/generated/sdks/backend/java.md) | [Node.js](/docs/generated/sdks/backend/node.md) | [Go](/docs/generated/sdks/backend/go.md) | [Python](/docs/generated/sdks/backend/python.md) | [Ruby](/docs/generated/sdks/backend/ruby.md) | [.NET](/docs/generated/sdks/backend/dotnet.md) | [PHP](/docs/generated/sdks/backend/php.md) | [Rust](/docs/generated/sdks/backend/rust.md) |
|
||||
| --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: |
|
||||
| Bootstrap from file or custom implementation | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ |
|
||||
|
||||
### Default refresh and metrics intervals
|
||||
|
||||
#### Server-side SDKs
|
||||
#### Backend SDKs
|
||||
|
||||
| Interval | [Java](/docs/generated/sdks/server-side/java.md) | [Node.js](/docs/generated/sdks/server-side/node.md) | [Go](/docs/generated/sdks/server-side/go.md) | [Python](/docs/generated/sdks/server-side/python.md) | [Ruby](/docs/generated/sdks/server-side/ruby.md) | [.NET](/docs/generated/sdks/server-side/dotnet.md) | [PHP](/docs/generated/sdks/server-side/php.md) | [Rust](/docs/generated/sdks/server-side/rust.md) |
|
||||
| Interval | [Java](/docs/generated/sdks/backend/java.md) | [Node.js](/docs/generated/sdks/backend/node.md) | [Go](/docs/generated/sdks/backend/go.md) | [Python](/docs/generated/sdks/backend/python.md) | [Ruby](/docs/generated/sdks/backend/ruby.md) | [.NET](/docs/generated/sdks/backend/dotnet.md) | [PHP](/docs/generated/sdks/backend/php.md) | [Rust](/docs/generated/sdks/backend/rust.md) |
|
||||
| --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: |
|
||||
| Default refresh interval | 15s | 15s | 15s | 15s | 15s | 15s | 15s | 15s |
|
||||
| Default metrics interval | 60s | 60s | 60s | 60s | 60s | 60s | 60s | 15s |
|
||||
|
||||
#### Client-side SDKs
|
||||
| Interval | [Android](/docs/generated/sdks/client-side/android-proxy.md) | [Flutter](/docs/generated/sdks/client-side/flutter.md) | [iOS](/docs/generated/sdks/client-side/ios-proxy.md) | [JavaScript](/docs/generated/sdks/client-side/javascript-browser.md) | [Next.js](/docs/generated/sdks/client-side/next-js.md) | [React](/docs/generated/sdks/client-side/react.md) | [Svelte](/docs/generated/sdks/client-side/svelte.md) | [Vue](/docs/generated/sdks/client-side/vue.md) |
|
||||
#### Frontend SDKs
|
||||
| Interval | [Android](/docs/generated/sdks/frontend/android-proxy.md) | [Flutter](/docs/generated/sdks/frontend/flutter.md) | [iOS](/docs/generated/sdks/frontend/ios-proxy.md) | [JavaScript](/docs/generated/sdks/frontend/javascript-browser.md) | [Next.js](/docs/generated/sdks/frontend/next-js.md) | [React](/docs/generated/sdks/frontend/react.md) | [Svelte](/docs/generated/sdks/frontend/svelte.md) | [Vue](/docs/generated/sdks/frontend/vue.md) |
|
||||
| --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: |
|
||||
| Default refresh interval | 60s | 30s | 15s | 30s | 30s | 30s | 30s | 30s |
|
||||
| Default metrics interval | 60s | 30s | 30s | 60s | 60s | 60s | 60s | 60s |
|
||||
@ -162,7 +162,7 @@ If you need a language or framework not covered officially, explore our communit
|
||||
If you can't find an SDK that fits your requirements, you can also develop your own SDK. To make implementation easier, check out these resources:
|
||||
|
||||
- [Unleash Client Specifications](https://github.com/Unleash/client-specification) - Used by all official SDKs to make sure they behave correctly across different language implementations. This lets us verify that a gradual rollout to 10% of the users would affect the same users regardless of which SDK you're using.
|
||||
- [Client SDK overview](/client-specification) - A brief guide of the _Unleash Architecture_ and important aspects of the SDK role in it all.
|
||||
- [Backend SDK overview](/client-specification) - A brief guide of the _Unleash Architecture_ and important aspects of the SDK role in it all.
|
||||
|
||||
## Offline behavior
|
||||
|
||||
@ -174,15 +174,15 @@ Unless the SDK supports [bootstrapping](#bootstrapping), it needs to connect to
|
||||
|
||||
### Bootstrapping
|
||||
|
||||
By default, all SDKs reach out to the Unleash server at startup to fetch their flag configuration. Additionally, most of the [server-side SDKs](#server-side-sdks) and Unleash Edge support bootstrapping, which allows them to get their flag configuration from a file, the environment, or other local resources. These SDKs can function without any network connection.
|
||||
By default, all SDKs reach out to the Unleash server at startup to fetch their flag configuration. Additionally, most of the [backend SDKs](#backend-sdks) and Unleash Edge support bootstrapping, which allows them to get their flag configuration from a file, the environment, or other local resources. These SDKs can function without any network connection.
|
||||
|
||||
Bootstrapping is also supported by the following frontend SDKs:
|
||||
|
||||
- [Android SDK](/docs/generated/sdks/client-side/android-proxy.md)
|
||||
- [JavaScript SDK](/docs/generated/sdks/client-side/javascript-browser.md)
|
||||
- [React SDK](/docs/generated/sdks/client-side/react.md)
|
||||
- [Svelte SDK](/docs/generated/sdks/client-side/svelte.md)
|
||||
- [Vue SDK](/docs/generated/sdks/client-side/vue.md)
|
||||
- [Android SDK](/docs/generated/sdks/frontend/android-proxy.md)
|
||||
- [JavaScript SDK](/docs/generated/sdks/frontend/javascript-browser.md)
|
||||
- [React SDK](/docs/generated/sdks/frontend/react.md)
|
||||
- [Svelte SDK](/docs/generated/sdks/frontend/svelte.md)
|
||||
- [Vue SDK](/docs/generated/sdks/frontend/vue.md)
|
||||
|
||||
|
||||
### SDK identification headers
|
||||
|
@ -24,7 +24,7 @@ For instance: When using the [gradual rollout activation strategy](../reference/
|
||||
|
||||
:::note Availability
|
||||
|
||||
**Plan**: [Enterprise](https://www.getunleash.io/pricing) | **Version**: `4.0+` and [SDK compatibility](../reference/sdks#feature-compatibility-in-server-side-sdks).
|
||||
**Plan**: [Enterprise](https://www.getunleash.io/pricing) | **Version**: `4.0+` and [SDK compatibility](../reference/sdks#feature-compatibility-in-backend-sdks).
|
||||
|
||||
:::
|
||||
|
||||
|
@ -9,7 +9,7 @@ import SearchPriority from '@site/src/components/SearchPriority';
|
||||
|
||||
:::note Availability
|
||||
|
||||
**Version**: `5.4+` and [SDK compatibility](/reference/sdks#feature-compatibility-in-server-side-sdks).
|
||||
**Version**: `5.4+` and [SDK compatibility](/reference/sdks#feature-compatibility-in-backend-sdks).
|
||||
|
||||
:::
|
||||
## Overview
|
||||
|
@ -28,7 +28,7 @@ The following table gives an overview of the fields' intended usage, their lifet
|
||||
| `sessionId` | `string` | dynamic | The identifier of the current session. |
|
||||
| `remoteAddress` | `string` | dynamic | The application's IP address. |
|
||||
| `properties` | `Map<string, string>` | dynamic | A key-value store for additional data. |
|
||||
| `currentTime` | `DateTime`/`string` | dynamic | A `DateTime` (or similar) data class instance or a string in an RFC-3339 format. **Defaults to the current time** if not set by the user; requires [SDK compatibility](../reference/sdks#feature-compatibility-in-server-side-sdks). |
|
||||
| `currentTime` | `DateTime`/`string` | dynamic | A `DateTime` (or similar) data class instance or a string in an RFC-3339 format. **Defaults to the current time** if not set by the user; requires [SDK compatibility](../reference/sdks#feature-compatibility-in-backend-sdks). |
|
||||
|
||||
|
||||
### The `properties` field
|
||||
@ -78,7 +78,7 @@ Using a custom context field called _region_ as an example: if you define the fi
|
||||
|
||||
:::note SDK compatibility
|
||||
|
||||
Custom stickiness is supported by all SDKs except for the Rust SDK. Refer to the [SDK compatibility table](../reference/sdks#feature-compatibility-in-server-side-sdks) for more information.
|
||||
Custom stickiness is supported by all SDKs except for the Rust SDK. Refer to the [SDK compatibility table](../reference/sdks#feature-compatibility-in-backend-sdks) for more information.
|
||||
|
||||
:::
|
||||
|
||||
|
@ -166,13 +166,13 @@ Instead of performing client-side evaluation, a more secure and maintainable app
|
||||
|
||||
### Server-side components
|
||||
|
||||
In [Principle 1](#1-enable-runtime-control), we proposed a set of architectural components for building a feature flag system. The same principles apply here, with additional suggestions for achieving local evaluation. For client-side setups, use a dedicated evaluation server that can evaluate feature flags and pass evaluated results to the client SDK.
|
||||
In [Principle 1](#1-enable-runtime-control), we proposed a set of architectural components for building a feature flag system. The same principles apply here, with additional suggestions for achieving local evaluation. For client-side setups, use a dedicated evaluation server that can evaluate feature flags and pass evaluated results to the frontend SDK.
|
||||
|
||||
### SDKs
|
||||
|
||||
[SDKs](/reference/sdks) make it more convenient to work with feature flags. Depending on the context of your infrastructure, you need different types of SDKs to talk to your feature flagging service. Server-side SDKs should fetch configurations from the _Feature Flag Control Service_ and evaluate flags locally using the application's context, reducing the need for frequent network calls.
|
||||
[SDKs](/reference/sdks) make it more convenient to work with feature flags. Depending on the context of your infrastructure, you need different types of SDKs to talk to your feature flagging service. Backend SDKs should fetch configurations from the _Feature Flag Control Service_ and evaluate flags locally using the application's context, reducing the need for frequent network calls.
|
||||
|
||||
For client-side feature flags, SDKs should send the context to an evaluation server and receive the evaluated results. The evaluated results are then cached in memory in the client-side application, allowing quick lookups without additional network overhead. This provides the performance benefits of local evaluation while minimizing the exposure of sensitive data.
|
||||
For frontend applications, SDKs should send the context to an evaluation server and receive the evaluated results. The evaluated results are then cached in memory in the client-side application, allowing quick lookups without additional network overhead. This provides the performance benefits of local evaluation while minimizing the exposure of sensitive data.
|
||||
|
||||
<VideoContent videoUrls={["https://www.youtube.com/embed/mCXSAWzdn3I"]}/>
|
||||
|
||||
|
@ -66,25 +66,25 @@ In this setup, you need to configure Edge and the SDKs.
|
||||
### Configure Edge
|
||||
|
||||
Set the `UPSTREAM_URL` environment variable to your Unleash instance URL (e.g., `https://<your-instance>.app.unleash-hosted.com/api`):
|
||||
- Provide the Client API tokens using the `TOKENS` environment variable. This allows Edge to fetch the correct flag configurations on startup.
|
||||
- Provide the Backend API tokens using the `TOKENS` environment variable. This allows Edge to fetch the correct flag configurations on startup.
|
||||
- Run the Edge container. Example using Docker:
|
||||
```bash
|
||||
docker run -p 3063:3063 \
|
||||
-e UPSTREAM_URL='<UPSTREAM_URL>' \
|
||||
-e TOKENS='<CLIENT_API_TOKEN>' \
|
||||
-e TOKENS='<BACKEND_API_TOKEN>' \
|
||||
unleashorg/unleash-edge:latest edge
|
||||
```
|
||||
- To add configurations for other projects/environments dynamically after startup, you can send an authorized request to Edge using a different Client API token:
|
||||
- To add configurations for other projects/environments dynamically after startup, you can send an authorized request to Edge using a different Backend API token:
|
||||
```bash
|
||||
curl --location --request GET 'http://<your-edge-host>:3063/api/client/features' \
|
||||
--header 'Authorization: <NEW_CLIENT_API_TOKEN>'
|
||||
--header 'Authorization: <NEW_BACKEND_API_TOKEN>'
|
||||
```
|
||||
|
||||
### Configure the SDKs
|
||||
|
||||
Point your SDKs to your self-hosted Edge instance's URL.
|
||||
- **Server-side SDKs:** Use the `/api/client` endpoint and a Client token. Edge returns the full flag configuration for the token's scope.
|
||||
- **Client-side SDKs:** Use the `/api/frontend` endpoint and a Frontend token. Edge evaluates flags based on the context provided by the SDK and returns only the evaluated feature flags.
|
||||
- **Backend SDKs:** Use the `/api/client` endpoint and a Backend token. Edge returns the full flag configuration for the token's scope.
|
||||
- **Frontend SDKs:** Use the `/api/frontend` endpoint and a Frontend token. Edge evaluates flags based on the context provided by the SDK and returns only the evaluated feature flags.
|
||||
|
||||
|
||||
## Self-hosted
|
||||
|
@ -30,21 +30,21 @@ A web interface for managing feature flags, defining activation strategies, view
|
||||
|
||||
### Unleash SDKs
|
||||
|
||||
Unleash provides both [server-side](/reference/sdks#server-side-sdks) and [client-side SDKs](/reference/sdks#client-side-sdks) for integrating feature flagging into your applications. SDKs fetch data from the Unleash API to check which feature flags are enabled. Server-side SDKs fetch all feature flag configuration data and perform the evaluation locally, while client-side SDKs fetch evaluated feature flags only.
|
||||
Unleash provides both [backend](/reference/sdks#backend-sdks) and [frontend SDKs](/reference/sdks#frontend-sdks) for integrating feature flagging into your applications. SDKs fetch data from the Unleash API to check which feature flags are enabled. Backend SDKs fetch all feature flag configuration data and perform the evaluation locally, while frontend SDKs fetch evaluated feature flags only.
|
||||
|
||||
#### Server-side SDKs
|
||||
#### Backend SDKs
|
||||
|
||||
Server-side SDKs run in backend applications and retrieve feature flag configurations using the [Client API](#client-api) either from Unleash server or [Unleash Edge](#unleash-edge).
|
||||
Backend SDKs run in backend applications and retrieve feature flag configurations using the [Client API](#client-api) either from Unleash server or [Unleash Edge](#unleash-edge).
|
||||
|
||||
Server-side SDKs cache all feature flag data in memory, applying activation strategies locally. This makes flag evaluation incredibly fast, as it is a simple function operating on local state, without the need to poll data from the database. This architecture results in a small delay (typically a few seconds, but configurable) when propagating configuration changes to your applications.
|
||||
Backend SDKs cache all feature flag data in memory, applying activation strategies locally. This makes flag evaluation incredibly fast, as it is a simple function operating on local state, without the need to poll data from the database. This architecture results in a small delay (typically a few seconds, but configurable) when propagating configuration changes to your applications.
|
||||
|
||||
Supported languages include: [Node.js](/reference/sdks/node), [Go](/reference/sdks/go), [Java](/reference/sdks/java), [Python](/reference/sdks/python), [.NET](/reference/sdks/dotnet), [PHP](/reference/sdks/php), and more.
|
||||
|
||||
#### Client-side SDKs
|
||||
#### Frontend SDKs
|
||||
|
||||
Client-side SDKs are used in frontend and mobile applications. They communicate with Unleash or [Unleash Edge](#unleash-edge) through the [Frontend API](#frontend-api).
|
||||
Frontend SDKs are used in frontend and mobile applications. They communicate with Unleash or [Unleash Edge](#unleash-edge) through the [Frontend API](#frontend-api).
|
||||
|
||||
Unlike server-side SDKs, client-side SDKs do not perform the flag evaluation locally. Instead, they fetch all enabled feature flags for a given [Unleash Context](/reference/unleash-context). The flag evaluation happens inside [Unleash Edge](#unleash-edge), or within the Unleash server. Client-side SDKs cache evaluated feature flags in memory using a single evaluation call to the server, making flag evaluation secure, fast, and efficient.
|
||||
Unlike backend SDKs, frontend SDKs do not perform the flag evaluation locally. Instead, they fetch all enabled feature flags for a given [Unleash Context](/reference/unleash-context). The flag evaluation happens inside [Unleash Edge](#unleash-edge), or within the Unleash server. Frontend SDKs cache evaluated feature flags in memory using a single evaluation call to the server, making flag evaluation secure, fast, and efficient.
|
||||
|
||||
Supported platforms include: [JavaScript](/reference/sdks/javascript-browser), [React](/reference/sdks/react), [iOS](/reference/sdks/ios-proxy), [Android](/reference/sdks/android-proxy), and more.
|
||||
|
||||
@ -54,37 +54,37 @@ The following table outlines where flag evaluation happens with different SDK se
|
||||
|
||||
| SDK setup | Feature flag evaluation |
|
||||
|------------------------------------|--------------------------------------------------|
|
||||
| Server-side SDK + Unleash | Performed **locally** within the SDK. |
|
||||
| Server-side SDK + Unleash Edge | Performed **locally** within the SDK. |
|
||||
| Client-side SDK + Unleash | Performed by the **Unleash server**. |
|
||||
| Client-side SDK + Unleash Edge | Performed by **Unleash Edge**. |
|
||||
| Backend SDK + Unleash | Performed **locally** within the SDK. |
|
||||
| Backend SDK + Unleash Edge | Performed **locally** within the SDK. |
|
||||
| Frontend SDK + Unleash | Performed by the **Unleash server**. |
|
||||
| Frontend SDK + Unleash Edge | Performed by **Unleash Edge**. |
|
||||
|
||||
Flag evaluation relies on the [Unleash Context](/reference/unleash-context) and may involve user data. Since server-side SDKs always perform local evaluation, your user data remains within your application and is never shared with the Unleash server.
|
||||
Flag evaluation relies on the [Unleash Context](/reference/unleash-context) and may involve user data. Since backend SDKs always perform local evaluation, your user data remains within your application and is never shared with the Unleash server.
|
||||
|
||||
For client-side SDKs, you can use Unleash Edge for flag evaluation to ensure that user data is not shared with the Unleash server. You have different [hosting options](/understanding-unleash/hosting-options) for both Unleash and Unleash Edge allowing you to meet any privacy requirements.
|
||||
For frontend SDKs, you can use Unleash Edge for flag evaluation to ensure that user data is not shared with the Unleash server. You have different [hosting options](/understanding-unleash/hosting-options) for both Unleash and Unleash Edge allowing you to meet any privacy requirements.
|
||||
|
||||
### Unleash Edge
|
||||
|
||||
Unleash Edge is a lightweight caching layer designed to improve scalability, performance, and resilience. It sits between your SDKs and the Unleash API and handles thousands of connected SDKs without increasing the number of requests you make to your Unleash instance.
|
||||
|
||||
Beyond scalability, Unleash Edge also offers privacy and security benefits for client-side SDKs by performing flag evaluations without exposing sensitive data to end-users or to Unleash.
|
||||
Beyond scalability, Unleash Edge also offers privacy and security benefits for frontend SDKs by performing flag evaluations without exposing sensitive data to end-users or to Unleash.
|
||||
|
||||
### Unleash APIs
|
||||
|
||||
#### Client API
|
||||
|
||||
The [Client API](/api-overview) is the API used by server-side SDKs to fetch feature flag configurations and send SDK usage metrics to Unleash.
|
||||
The [Client API](/api-overview) is the API used by backend SDKs to fetch feature flag configurations and send SDK usage metrics to Unleash.
|
||||
|
||||
#### Frontend API
|
||||
The [Frontend API](/api-overview) is the API used by client-side SDKs to retrieve all enabled feature flags for a given [Unleash Context](/reference/unleash-context) and send SDK usage metrics to Unleash.
|
||||
The [Frontend API](/api-overview) is the API used by frontend SDKs to retrieve all enabled feature flags for a given [Unleash Context](/reference/unleash-context) and send SDK usage metrics to Unleash.
|
||||
|
||||
#### Admin API
|
||||
The [Admin API](/api-overview) is an API layer for managing all aspects of your Unleash instance, including creating, updating, and deleting resources, such as feature flags, activation strategies, and environments. This API is used by the [Unleash Admin UI](#the-unleash-admin-ui) and other tools and [integrations](/reference/integrations).
|
||||
|
||||
| API | Used by | Available endpoints |
|
||||
|---------------|---------|---|
|
||||
| Client API | Server-side SDKs | Get all enabled feature flags for a given context, register an SDK, send SDK usage metrics. |
|
||||
| Frontend API | Client-side SDKs | Get a feature flag by name, get all feature flags, register an SDK, send SDK usage metrics. |
|
||||
| Client API | Backend SDKs | Get all enabled feature flags for a given context, register an SDK, send SDK usage metrics. |
|
||||
| Frontend API | Frontend SDKs | Get a feature flag by name, get all feature flags, register an SDK, send SDK usage metrics. |
|
||||
| Admin API | Admin UI, internal tooling, third-party integrations | Access and manage all resources within Unleash, such as context, environments, events, metrics, and users. |
|
||||
|
||||
## Get started with Unleash
|
||||
|
@ -185,7 +185,7 @@ If emails fail to send or contain errors:
|
||||
| :--------------------------------- | :-------------- | :--------------------------------------------------------------------------------------------------------- |
|
||||
| `UNLEASH_DEFAULT_ADMIN_USERNAME` | `admin` | Sets the username for the initial admin user created on first startup. |
|
||||
| `UNLEASH_DEFAULT_ADMIN_PASSWORD` | `unleash4all` | Sets the password for the initial admin user. **Change this for any non-local setup.** |
|
||||
| `INIT_CLIENT_API_TOKENS` | N/A | Comma-separated list of [Client tokens](/reference/api-tokens-and-client-keys#client-tokens) to create on first startup (if no tokens exist in the database). |
|
||||
| `INIT_CLIENT_API_TOKENS` | N/A | Comma-separated list of [Client tokens](/reference/api-tokens-and-client-keys#backend-tokens) to create on first startup (if no tokens exist in the database). |
|
||||
| `INIT_FRONTEND_API_TOKENS` | N/A | Comma-separated list of [Frontend tokens](/reference/api-tokens-and-client-keys#frontend-tokens) to create on first startup (if no tokens exist in the database). |
|
||||
|
||||
### Server behavior
|
||||
|
@ -21,8 +21,8 @@ import {
|
||||
//
|
||||
// type ReadmeData = Readme & { repoUrl: string };
|
||||
|
||||
const CLIENT_SIDE_SDK = 'client-side';
|
||||
const SERVER_SIDE_SDK = 'server-side';
|
||||
const CLIENT_SIDE_SDK = 'frontend';
|
||||
const SERVER_SIDE_SDK = 'backend';
|
||||
|
||||
const serverSideSdks = {
|
||||
'unleash-client-go': {
|
||||
@ -101,8 +101,8 @@ const SDKS = (() => {
|
||||
|
||||
const getAdmonitions = (sdk) => {
|
||||
const admonitions = {
|
||||
[CLIENT_SIDE_SDK]: `To connect to Unleash from a client-side context, you'll need to use the [Unleash front-end API](/reference/front-end-api) ([how do I create an API token?](/how-to/how-to-create-api-tokens.mdx)) or the [Unleash proxy](/reference/unleash-proxy) ([how do I create client keys?](/reference/api-tokens-and-client-keys#proxy-client-keys)).`,
|
||||
[SERVER_SIDE_SDK]: `To connect to Unleash, you'll need your Unleash API url (e.g. \`https://<your-unleash>/api\`) and a [server-side API token](/reference/api-tokens-and-client-keys.mdx#client-tokens) ([how do I create an API token?](/how-to/how-to-create-api-tokens.mdx)).`,
|
||||
[CLIENT_SIDE_SDK]: `To connect to Unleash from a frontend application, you'll need to use the [Unleash front-end API](/reference/front-end-api) ([how do I create an API token?](/how-to/how-to-create-api-tokens.mdx)) or the [Unleash proxy](/reference/unleash-proxy) ([how do I create client keys?](/reference/api-tokens-and-client-keys#proxy-client-keys)).`,
|
||||
[SERVER_SIDE_SDK]: `To connect to Unleash, you'll need your Unleash API url (e.g. \`https://<your-unleash>/api\`) and a [backend API token](/reference/api-tokens-and-client-keys.mdx#backend-tokens) ([how do I create an API token?](/how-to/how-to-create-api-tokens.mdx)).`,
|
||||
};
|
||||
|
||||
const wrap = (text) => `:::tip\n${text}\n:::`;
|
||||
|
@ -498,21 +498,21 @@ const sidebars: SidebarsConfig = {
|
||||
items: [
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Server-side SDKs',
|
||||
label: 'Backend SDKs',
|
||||
items: [
|
||||
{
|
||||
type: 'autogenerated',
|
||||
dirName: 'generated/sdks/server-side',
|
||||
dirName: 'generated/sdks/backend',
|
||||
},
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Client-side SDKs',
|
||||
label: 'Frontend SDKs',
|
||||
items: [
|
||||
{
|
||||
type: 'autogenerated',
|
||||
dirName: 'generated/sdks/client-side',
|
||||
dirName: 'generated/sdks/frontend',
|
||||
},
|
||||
],
|
||||
},
|
||||
|
Loading…
Reference in New Issue
Block a user