featureFlags.md

Feature Flags Proposal

The targets that we want to achieve:

• Detach feature flags from build process (which forces to have multiple deployment environments or instances)
• Have the flexibility to have feature flags attached or detached to Grover site version
• Be future ready in case the decision is made to develop an on-site configurator (in order to turn certain feature flags on/off according to the desire of the viewer) . The site can be launched with some /URL param/ that will turn dev mode on (which in turn will enable a gear-settings-overlay to control feature flags)
• Be able to control from API level which features have a particular version of the site

Bonus items:

• We can declare site version to be more strict than feature flags (eg. to have site version be decisive) & attach it to route param or URL
• Once they are attached in redux, we can operate and toggle them (to allow for live toggle of any feature)
• We will be able to do switch statements for deciding which view to show per route depending on the version (which is dynamic from the API or URL param or both at the same)

Crud for feature flags Basic view of /requests & responses/

// Request to create a feature flag
{
	name: [String],
	version: [Unsiged Integer - foreign key] // can be selected from dropdown in UI
	strict_version_bounding: [Boolean],
}

// Response for the feature flag object
{
	id: [Unsigned Integer],
	name: [String],
	version: {
		id: [Unsigned Integer],
		name: [String],
		version: [Float],
	},
	strict_version_bounding: [Boolean]
}

Crud for version flags Basic view of /requests & responses/

// Request to create version flag
{
	name: [String],
	version: [Float]
}

// Response for the version 
{
	id: [Unsigned Integer],
	name: [String],
	version: [Float],
	features: [
		{Feature Flag Response Object Signature},
		{Feature Flag Response Object Signature},
		{Feature Flag Response Object Signature}
	]
}