1
0
mirror of https://github.com/Unleash/unleash.git synced 2024-10-18 20:09:08 +02:00
unleash.unleash/website/docs/reference/front-end-api.md
Thomas Heartman d5fbd0b743
refactor: move docs into new structure / fix links for SEO (#2416)
## What

This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:

- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.

A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).

## Why

When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.

There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.

## Discussion points

The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 09:05:30 +00:00

3.8 KiB
Raw Blame History

title
Front-end API access

:::info Availability

The Unleash front-end API is an experimental feature and is currently in development.

:::

The Unleash front-end API offers a simplified workflow for connecting a client-side (front-end) applications to Unleash. It provides the exact same API as the Unleash proxy. The front-end API is a quick and easy way to add Unleash to single-page applications and mobile apps.

Compared to using the Unleash proxy, using the Unleash front-end API has both benefits and drawbacks. The benefits are:

  • Managing client-side API tokens is easier. With the Unleash proxy, you need to create and manage client keys manually; with the front-end API, you manage client-side API tokens in the exact same manner as other API tokens.
  • You don't need to configure and run an Unleash proxy. The front-end API is part of Unleash itself and not an external process. All proxy clients will work exactly the same as they would with the Proxy.

On the other hand, using the front-end API has the following drawbacks compared to using the proxy:

  • It can't handle a large number of requests per second. Because the front-end API is part of Unleash, you can't scale it horizontally the way you can scale the proxy.
  • It sends client details to your Unleash instance. Unleash only stores these details in its short-term runtime cache, but this can be a privacy issue for some use cases.

These points make the Unleash front-end API best suited for development purposes and applications that dont receive a lot of traffic, such as internal dashboards. However, because the API is identical to the Unleash proxy API, you can go from one to the other at any time. As such, you can start out by using the front-end API and switch to using the proxy when you need it.

Using the Unleash front-end API

When using the front-end API in an SDK, there's three things you need to configure.

Front-end API tokens

As a client-side API, you should use a front-end API token to interact with it. Refer to the how to create API tokens guide for steps on how to create API tokens.

Cross-origin resource sharing (CORS) configuration

You need to allow traffic from your application domains to use the Unleash front-end API with web and hybrid mobile applications. You can update the front-end API CORS settings from the Unleash UI under admin > CORS or by using the API.

API URL

The client needs to point to the correct API endpoint. The front-end API is available at <your-unleash-instance>/api/frontend.

API token

You can create appropriate token, with type FRONTEND on <YOUR_UNLEASH_URL>/admin/api/create-token page or with a request to /api/admin/api-tokens. See our guide on how to create API tokens for more details.

Refresh interval for tokens

Internally, Unleash creates a new Unleash client for each token it receives. Each client is configured with the project and environment specified in the token.

Each client updates its feature toggle configuration at a specified refresh interval plus a random offset between 0 and 10 seconds. By default, the refresh interval is set to 10 seconds. The random offset is used to stagger incoming requests to avoid a large number of clients all querying the database simultaneously. A new, random offset is used for every update.

The refresh interval is specified in milliseconds and can be set by using the FRONTEND_API_REFRESH_INTERVAL_MS environment variable or by using the frontendApi.refreshIntervalInMs configuration option in code.