Keep it local
With multiple levels of adapters and reads that are local to your application, you'll have blazing fast feature checks that are always available and in sync, even if Flipper Cloud isn't for some reason. We've even written about how we designed Flipper to ensure that Flipper doesn't need to be online for your application to work.
Store data your way
Flipper uses adapters so you can store your flag data in a relational database, non-relational database, or anywhere really. You can use on of our existing adapters or write your own.
|
Storage
You definitely need one of these.
|
|
|---|---|
| ActiveRecord | Production Rails apps |
| Moneta | Production Ruby apps already using Moneta |
| Mongo | Production Ruby apps already using Mongo |
| Redis | Production Ruby apps already using Redis |
| Sequel | Production Ruby apps already using Sequel |
|
Cache
Reduce calls to storage to speed things up.
|
|
| ActiveSupportCacheStore | Production Rails apps with aggressive caching needs |
| Dalli | Production Ruby apps already using Dalli |
| Redis Cache | Production Rails apps with aggressive caching needs |
|
Extras
Additional functionality to complement primary adapters.
|
|
| ActorLimit | Limits the number of actors that can be enabled for a feature (default: 100) |
| Failover | Increasing reliability by failing over to a secondary adapter if primary is unavailable |
| Failsafe | Graceful failures when an exception is raised |
| Instrumented | Instrumenting all adapter operations with ActiveSupport::Notifications |
| Read Only | Preventing writes from a Production console |
| Strict | Raising an error if an unrecognized flag is used |
|
Internal
You probably dont need these but here they are.
|
|
| Dual Write | Read from one adapter but write to two (used by Cloud) |
| Memoizable | Prevent subsquent calls to an adapter for the same feature (used by memoizing middleware) |
| Memory | Testing Environments |
| Operation Logger | Stores all adapter operations in memory for verification in tests |
| Poll | Polls for changes from a remote adapter in a background thread but updates local adapter in main thread (used by Cloud) |
| Sync | Keeping two adapters in sync (bits are used in Cloud) |
|
Niche
Highly specialized adapters outside of day-to-day usage.
|
|
| HTTP | Connecting to Flipper::Api |
| PStore | When a local file is enough or you need something that works with multiple processes like some system tests |
| Rollout | Migrating from Rollout to Flipper |
Keep multiple servers in sync
Flipper always keeps a copy of flag data locally for each system using it, but with multiple servers, that data needs to stay in sync so that all of the systems are on the same page about each feature. Flipper Cloud can then serve as the source of truth for all of the systems and proactively notify them when they need to pull down the latest updates to your feature flag data.
Rest easy with backups
With Flipper Cloud as the source of truth, you can rest easy knowing that your feature flag data is automatically backed up and safe. So if you need to bring new systems online or recover from other issues, you'll always have a backup of your feature flag data in the Cloud. That way, your local copies and local backups always have the ultimate backup with Flipper Cloud.
