Skip to main content

Concepts

Resources​

The diagram below illustrates the Flagbase's resource hierarchy. To simplify the diagram, identity and targeting have not been included in this diagram.

To summarise the diagram below, all resources belong to a single instance. A workspaces is used to hold project(s). A project contains flags and segments. A project can have multiple environments, allowing you to have different targeting rules per environment.

If you can't see the diagram above, your browser may not support iframes. You can use this link to view original diagram.

Below is a high-level overview of each resource. If you want to go more indepth about the purpose of each resource and their relationship with other resources with examples, please visit the represent resource page in the guides section. If you wish to get a in-depth overview of data-models used by Flagbase, please read through the data-models section in the dev section.

  • Instance is a Flagbase core installation, running on a single VPS or clustered in a datacenter. Flagbase uses postgres as the main datastore used to store resources. Everything in a single postgres database represents a single Flagbase instance. You can have multiple hosts runnning Flagbase core, but if they all share the same database, we refer to that as a "single instance".
  • Access is a key/secret pair used to restrict operations on a particular resource via the policy enforcer. You can create and attach access to workspace, project and environment resources.
  • Workspace is the top-level resource which is used to group projects. A workspace can only be created by a root user, which you only have access to if you own a particular instance. You can have multiple workspaces per instance. Every workspace will have a unique key, per instance.
  • Project represents a collection of flags and segments. A project can have multiple environments that correspond to different targeting states.
  • Environment A project can have multiple environments (e.g. dev, staging, production) which correspond to different targeting states. This means if you modify a flag's targeting or a segment's rules in one environment, your changes will be scoped to that particular environment. This allows you to have different targeting rules for flags and segments in each environment.
  • Flag (aka feature flag, toggle, switch etc) represents a particular point in code which when evaluated determines the state of a feature. Flags hold different variations (i.e. on/off, true/false, A/B/C), which are only revealed upon evaluation.
  • Identity (aka user) refers to a flag observer/consumer who requests to evaluate a flag. An identity consists of a set of traits. These traits are used as the context which is used during evaluation.
  • Segment is used to group users based on their characteristics (i.e. traits). Segments are made up of one or more rules that is used to filter out a portion of your users. Segments provide a method to capture common targeting rules - allowing you to reuse these rules across different flags.
  • Targeting is a spec used to determine a flag's variaation. This spec consists of a set of rules which when evaluated using a user's context (i.e. traits), determines which variation of a flag that particular user will recieve. So essentially you could say targeting rules are conditions mapped to a variation. A flag's targeting rules are scoped to a particular project environment.