Ruby

Installation

Install the tggl package:

gem install tggl

Quick start

Instantiate a client with your API key and call eval_context to evaluate a context. A single API call evaluating all flags is performed, making all subsequent flag checking methods extremely fast.

This means that you do not need to cache results of isActive and get since they do not trigger an API call, they simply look up the data in the already fetched response.

require "tggl"
 
$client = Tggl::Client.new("YOUR_API_KEY")
 
# An API call to Tggl is performed here
$flags = $client.eval_context({
  userId: "abc",
  email: "foo@gmail.com",
  country: "FR",
  # ...
})
 
if $flags.is_active? "my-feature"
  # ...
end
 
if $flags.get "my-feature" == "Variation A"
  # ...
end

Differences between is_active? and get

By design, inactive flags are not in the response, which means that you have no way of telling apart those cases:

• The flag is inactive due to some conditions
• The flag does not exist
• The flag was deleted
• The API key is not valid
• Some network error

This design choice prevents unforeseen event from breaking your app, like someone deleting a flag or messing up the API key rotation. Your app will simply consider any flag to be inactive.

is_active? will return true if the flag exists and is active regardless of its value (and there is no network error).

get gives you the actual value of an active flag, and this value may be "falsy" (null, false, 0, or empty string). This may lead to unforeseen behavior if you are not careful:

if $flags.get "my-feature"
  # If 'my-feature' is active, but its value is falsy this block won't be executed
end
 
if $flags.is_active? "my-feature"
  # Even if 'my-feature' has a falsy value, this block will be executed
end

In both cases, if the flag is explicitly inactive, or if there is a network error, the block won't be executed.

Hard-coded fallback values

When using get, you can provide a fallback value that will be returned if the flag is inactive, does not exist, or in case of network error:

if $flags.get("my-feature", "Variation A") == "Variation A"
  # This code will be executed if 'my-feature' is either:
  # - active and explicitly equal to 'Variation A'
  # - inactive or network error
end

Having the possibility of providing a fallback value is useful when you want to have a default behavior when a flag is deleted or when the user encounters a network error:

if $flags.get("my-feature", true)
  # This block will be executed if 'my-feature' is explicitly active or if there is a network error
end
 
if $flags.is_active? "my-feature"
  # This block will only be executed if there is no network error and the flag is explicitly active
end

Evaluating contexts in batches

If you have multiple contexts to evaluate at once, you can batch your calls in a single HTTP request which is much more performant:

$result = $client.eval_contexts([
  { userId: 'foo' },
  { userId: 'bar' },
])
 
# Responses are returned in the same order
$fooFlags = $result[0]
$barFlags = $result[1]

Evaluate flags locally

It is possible to evaluate flags locally on the server but not recommended unless you have performance issues evaluating flags at a high frequency. Evaluating flags locally forces you to maintain the copy of flags configuration up to date and might be a source of issues.

require "tggl"
 
$client = Tggl::LocalClient.new("YOUR_SERVER_API_KEY")
 
# This method performs an API call and updates the flags configuration
$client.fetch_config
 
# Evaluation is performed locally
$client.is_active({ userId: "foo" }, "my-feature")
 
# You can also get the value of a flag, with and without default value
$client.get({ userId: "foo" }, "my-feature")
$client.get({ userId: "foo" }, "my-feature", 42)

You should cache the configuration and instantiate the client with the cached version, so you don't need to call fetchConfig for every request:

$cachedConfig = $client.fetch_config
 
# Create another client with the cached config
$client = Tggl::LocalClient.new("YOUR_SERVER_API_KEY",
  config: $cachedConfig
)

It is your responsibility to keep the cache of the configuration up to date by calling fetchConfig when needed. You can use webhooks to be notified when the configuration changes.