Server-side evaluation

It is recommended to evaluate flags via the API unless you have performance issues or if you need to split traffic on the edge without doing an API call.

Note that evaluating flags locally requires you to maintain a copy of flags configuration up to date and potentially re-implement the evaluation logic in your language, which might be a source of issues.

Using an SDK

This can be done easily in all server-side SDKs (see documentation). Here is an example in Node.js and PHP:

import { TgglLocalClient } from 'tggl-client'
 
const client = new TgglLocalClient('YOUR_SERVER_API_KEY')
 
await client.fetchConfig()
 
if (client.isActive({ userId: 'foo' }, 'my-feature')) {
  //...
}

Here the fetchConfig method is fetching the config from the API, and isActive is evaluating a context against a flag without making any API call.

Using the API directly

If your language does not have an SDK, or you prefer to use the API directly, you can make the HTTP call yourself (see documentation).

curl 'https://api.tggl.io/config' \
  -H 'x-tggl-api-key: <server api key>'

Keeping flags definition up to date

You have two solutions to maintain the cache of the configuration up to date:

• Do some polling and re-fetch the config at a regular intervals
• Use a webhook to update the cache when a flag is updated

It is recommended to use both a webhook for fast updates, and polling with a large interval as a safety net.

Important differences with the API

When evaluating flags via the API a few keys are automatically added to the context. When evaluating flags locally it is your responsibility to pass those keys to the context, otherwise any condition that is based on those keys will fail.

Here is the exhaustive list of keys that are automatically added by Tggl when evaluating flags via the API:

• timestamp: the current timestamp
• ip: the IP address that made the HTTP request
• referer: the value of the referer HTTP header