-
Notifications
You must be signed in to change notification settings - Fork 64
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Total web-docs overhaul: - puts a helpful intro at the start, with a demo on the next page - adds an "architecture" page which discusses in-process vs rpc - adds a deployment page with mentions how to install/run - adds a "reference" section which includes: - specs - protos (in the form of autogenerated markdown for easy navigation) - autogenerated CLI docs - adds FAQ --------- Signed-off-by: Todd Baert <[email protected]> Co-authored-by: Michael Beemer <[email protected]>
- Loading branch information
Showing
74 changed files
with
1,648 additions
and
1,700 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -14,4 +14,5 @@ go.work.sum | |
bin/ | ||
|
||
# built documentation | ||
site | ||
site | ||
.cache/ |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,45 @@ | ||
# Architecture | ||
|
||
flagd architectures fall into two broad categories: those where the evaluation engine is deployed in a standalone process to which the client application connects ([RPC](#rpc-evaluation)), and those where the evaluation engine is embedded into the client application ([in-process](#in-process-evaluation)). | ||
|
||
## RPC vs In-Process Evaluation | ||
|
||
### RPC evaluation | ||
|
||
In RPC-based deployments one or more flagd instances deployed and exposed to client applications in your infrastructure. | ||
flagd RPC providers use HTTP or gRPC to request flag evaluations from flagd. | ||
The request payload contains the [flag key](https://openfeature.dev/specification/glossary#flag-key) identifying the flag to be evaluated, as well as the relevant [evaluation context](https://openfeature.dev/specification/glossary#evaluation-context). | ||
The flagd instance is configured to watch one or more [syncs](./concepts/syncs.md), and merges them to build its set of flags (see [here](./concepts/syncs.md#merging) for more details on flag definition merging). | ||
When sync sources are updated, flagd will send notifications to clients that flags have changed, enabling applications to react to changes by re-evaluating flags. | ||
|
||
This architecture is can be leveraged by very simple clients, since no in-process engine is needed; in fact, you can evaluate flags directly from a terminal console using the `cURL` utility. | ||
One disadvantage of this pattern is the latency involved in the remote request (though flagd typically takes <10ms for an evaluation, and can evaluate thousands of flags per second). | ||
|
||
```mermaid | ||
--- | ||
title: RPC Evaluation | ||
--- | ||
erDiagram | ||
flagd ||--o{ "sync (file)" : watches | ||
flagd ||--o{ "sync (http)" : polls | ||
flagd ||--o{ "sync (grpc)" : "sync.proto (gRPC/stream)" | ||
flagd ||--o{ "sync (kubernetes)" : watches | ||
"client app (+ flagd RPC provider)" ||--|| flagd : "evaluation.proto (gRPC/stream) / HTTP" | ||
``` | ||
|
||
### In-Process evaluation | ||
|
||
In-process deployments embed the flagd evaluation engine directly into the client application through the use of an [in-process provider](./deployment.md#in-process). | ||
The in-process provider is connected via the sync protocol to an implementing [gRPC service](./concepts/syncs.md#grpc-sync) that provides the flag definitions. | ||
This pattern requires an in-process implementation of the flagd evaluation engine, but has the benefit of no I/O overhead, since no inter-process communication is required. | ||
|
||
```mermaid | ||
--- | ||
title: In-Process Evaluation | ||
--- | ||
erDiagram | ||
"client app (+ flagd in-process provider)" ||--|| "sync (grpc)" : "sync.proto (gRPC/stream)" | ||
``` | ||
|
||
<!-- TODO: add link to sync protocol reference entry --> | ||
<!-- TODO: we might want a dedicated Kubernets section here eventually to talk about the specifics of the K8s implementation --> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,22 @@ | ||
{ | ||
"flags": { | ||
"show-welcome-banner": { | ||
"state": "ENABLED", | ||
"variants": { | ||
"on": true, | ||
"off": false | ||
}, | ||
"defaultVariant": "off" | ||
}, | ||
"background-color": { | ||
"state": "ENABLED", | ||
"variants": { | ||
"red": "#FF0000", | ||
"blue": "#0000FF", | ||
"green": "#00FF00", | ||
"yellow": "#FFFF00" | ||
}, | ||
"defaultVariant": "red" | ||
} | ||
} | ||
} |
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,24 @@ | ||
# Feature Flagging | ||
|
||
Feature flags are a software development technique that allows teams to enable, disable or change the behavior of certain features or code paths in a product or service, without modifying the source code. | ||
|
||
## OpenFeature Compliance | ||
|
||
[OpenFeature](https://openfeature.dev/) is an open standard that provides a vendor-agnostic, community-driven API for feature flagging. | ||
The flagd project is fully OpenFeature-compliant. | ||
In fact, flagd was initially conceived as a reference implementation for an OpenFeature backend, but has become a powerful tool in its own right. | ||
For this reason, you'll find flagd's concepts and terminology align with that of the OpenFeature project. | ||
Within the context of an OpenFeature-compliant feature flag solution, flagd artifacts and libraries comprise the [flag management system](https://openfeature.dev/specification/glossary#flag-management-system) and [providers](https://openfeature.dev/specification/glossary#provider). | ||
These artifacts and libraries alone won't allow you to evaluate flags in your application - you'll also need the [OpenFeature SDK](https://openfeature.dev/specification/glossary#feature-flag-sdk) for your language as well, which provides the evaluation API for application developers to use. | ||
|
||
## Supported Feature Flagging Use-Cases | ||
|
||
Below is a non-exhaustive table of common feature flag use-cases, and how flagd supports them: | ||
|
||
| Use case | flagd Feature | | ||
| ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| flag evaluation | Returns the value of a particular feature flag, if the flag is enabled. Supports flags of various types including boolean, numeric, string, and JSON. | | ||
| dynamic configuration | Flag definitions from any sync source are monitored for changes, with some syncs supporting near real time updates. | | ||
| dynamic (context-sensitive) evaluation | flagd evaluations are context sensitive. Rules can use arbitrary context attributes as inputs for flag evaluation logic. | | ||
| fractional evaluation / random assignment | flagd's [fractional](../reference/custom-operations/fractional-operation.md) custom operation supports pseudorandom assignment of flag values. | | ||
| progressive roll-outs | Progressive roll-outs of new features can be accomplished by leveraging the [fractional](../reference/custom-operations/fractional-operation.md) custom operation as well as automation in your build pipeline, SCM, or infrastructure which updates the distribution over time. | |
Oops, something went wrong.