off based on time of day, user role, and so on. Feature flagging allows an organization to practice continuous delivery, which means shorter release cycles that help ensure code is ready to ship at any time.
restart • Doesn't allow multiple projects to share flags (without duplicating configuration) • Not easy to sync across machines/environments • Doesn't allow us to schedule flags • Generally requires an engineer to make the modification
which is why it's the upstream proxy • Doesn't handle flag persistence (the datastore consists of a file on the local filesystem) • Doesn't provide a framework for flag creation, modification, and deletion (letting people munge flags by hand means a critical human error is simply a matter of time) • Generally requires an engineer to make the modification
and Node • Maximum number of developers can understand and contribute • Large pool of developers from which to hire • Shared code (e.g. Flaggregator is using a homegrown tool used for our CMS services for API auth in production) • Evented I/O makes sense for a feature-flagging service