toggler-io / toggler

toggler is a feature flag service to decouple deployment, feature enrollment and experiments

toggler is a Self hosted Feature and Release Management Service.

The service designed to be hosted on the public web. The service expects that public web request will be received from all kind of sources. Such case is the combined usage from SPA, lambda service and traditional backend services.

It is goal to provide a stable, reliable and free rollout management tooling for teams. By using release flags you can decouple the feature release from the deployment or config change process, also make it simple to keep feature states in sync for all your users.

The project aims only to be just barely enough for the minimal requirement that needed to do centralised feature release management.

Other than percentage based feature enrollment for piloting, every custom decision logic is expected to be implemented by your company trough an HTTP API.

• Why should you or your team choose Toggler?
• What's the state of the project, how safe to use it for production purposes?

Getting Started

Installation

Local Development

You need to ensure the following dependencies:

• go compiler (must have)
• bash (should have)
  • some script is written in bash
• docker-compose/podman-compose (should have) * + docker/podman
• direnv (nice to have)
  • alternatively you can just source the .envrc file at the project root directory.

To provision the project, execute the following command:

. .envrc
./bin/provision
docker-compose up --detach

To execute the tests:

go test ./...

With Container

You can build toggler from the master branch by using the Dockerfile:

docker build --tag toggler:latest .

or grab from hub.docker.com:

docker pull adamluzsi/toggler:latest

Configuration

The application can be configured trough either CLI option or with environment variables. It follows the convention that works easily with SaaS platforms or containerization based solutions.

Storage

The storage external resource will be used to persist data, and then using as source of facts.

The toggler doesn't depend on a certain storage system. It use behavior based specification, and has multiple implementation that fulfil this contract. This could potentially remove the burden on your team to introduce a new db just for the sake of the project.

You can choose from the following

• Postgres
• InMemory (for testing purposes only)

The Storage connection can be configured trough the DATABASE_URL environment variable or by providing the -database-url cli option to the executable.

To use one of the implementation, all you have to do is to provide the connection string in the CLI option or in the environment variable.

example connection string:

postgres://user:[email protected]:5432/dbname

export DATABASE_URL="postgres://user:[email protected]:5432/dbname"

Cache

Deployment

• heroku
• AWS Elastic Beanstalk
• on-premises
• Docker

Usage

Security token creation

To gain access to write and update related actions in the system, you must create a security token that will be used even on the webGUI.

To create a token, execute the following command on the server:

./toggler -cmd create-token "token-owner-uid"

the uniq id of the owner could be a email address for example. The token will be printed on the STDOUT. The token cannot be regained if it is not saved after token creation.

API Documentation

• HTTP API documentation
• you can find the swagger documentation at the /swagger.json endpoint.
• the webgui also provides swagger-ui out of the box on the /swagger-ui path

For Contributors

• High level overview
• Local Development Setup
• Backlog

Feel free to open an issue if you see anything

Thank you for reading about this project! :)

toggler's Issues

consistent feature toggles across a single request life cycle

Context

When various components call the centralized release service multiple times across a single request, it becomes possible to receive a different flag state back during a single life cycle of a request.

Such use-case is when the customer uses a microservice architecture where release toggles were not part of the design initially. passing around feature toggle states becomes change with high cost. They would like to use the service without the need to update all the microservice to pass around this new data.

Proposal

Since the 12factor app conventions, many if not all distributed systems use some form of request tracing ID.

E.g.:

• Heroku: X-Request-ID
• AWS: X-Amzn-Trace-Id: Root=...

Using this tracing ID we can make a special kind of cache that is optimized for high throughput write/read operations for /v/config endpoint.

The scaling would be done on a per tracing-id mod cluster

-

Removing Body from documentation

Having Body structs makes swagger unusable:

ex:

type ListReleaseRolloutRequest struct {
	...
	// in: body
	Body struct{}
}

event stream-based cache invalidation.

If an entity is mutated/deleted, then related caches must be invalidated.

• invalidate on Update
• invalidate on Delete

removing deployment domain. moving DeploymentEnvironment to release domain

• migration update: deployment_environments -> release_environments
• Storage Role Interface name refactor: DeploymentEnvironments -> ReleaseEnvironments
• move Environment related entity + storage contracts under the release domain

Deleting an Environment or a Flag while there is a Rollout associated with them

While deleting an Environment or a Flag, either user should get a warning about existing ReleaseRollouts associated with them, or associated ReleaseRollouts should also be deleted

# swagger integration

This will allow easy client generation for implementations

• create documentation
• generate go client from documentation
• add tests where the generated client is being used