REST API - Features Create & Update endpoints

[bttf]

This PR adds two endpoints for Feature Flags

• POST /features (create)
• POST /features/:id (update)

Changes

• New schemas:
  • PostFeaturePayload.yaml
  • UpdateFeaturePayload.yaml
  • Under postFeature/ subdirectory (necessary due to required fields differing vs. read operation)
    • FeatureEnvironment.yaml
    • FeatureExperimentRule.yaml
    • FeatureForceRule.yaml
    • FeatureRolloutRule.yaml
    • FeatureRule.yaml
• Adds following methods for creating and updating environment settings for a feature
  • fromApiEnvSettingsRulesToFeatureEnvSettingsRules
  • createInterfaceEnvSettingsFromApiEnvSettings
  • updateInterfaceEnvSettingsFromApiEnvSettings

Screenshots

Create

Update

[github-actions]

Deploy preview for docs ready!

✅ Preview
https://docs-ac2viunxi-growthbook.vercel.app

Built with commit 468b4d3.
This pull request is being automatically deployed with vercel-action

[github-actions]

Your preview environment pr-1478-bttf has been deployed.

Preview environment endpoints are available at:

• https://growthbook-3000-pr-1478-bttf.growthbook.okteto.dev
• https://growthbook-3100-pr-1478-bttf.growthbook.okteto.dev

[bttf]

PR is blocked by #1139 & #1525

[igorlovich]

PR is blocked by #1139 & #1525

Both of these have been merged, should the blocked label be removed ?

[igorlovich]

@bttf what is the priority of this item in your backlog ?

[bttf]

@igorlovich Sorry for the delay. There have been extensive changes to our Features <> Experiments relationships. (And I've also been on vacation.) This is getting attention now.

[bttf]

@jdorn Following our conversation re: license key checks, the most recent commit makes the following changes so that we always enforce license key checking for both internal API requests and REST API requests.

1. In processJWT (our auth middleware responsible for loading req.organization for the internal API), I've added a licenseInit call that supplies req.organization.licenseKey, which will be set only if the org has the license key stored on its mongoDB row. Otherwise, licenseInit should fallback to the env var, and simply bypass if none is found
2. With licenseInit, the subsequent verifyLicenseMiddleware should now always verify either env-var OR mongoDB sourced license keys
3. For the REST API, I've added a similar licenseInit call to the middleware responsible for loading the organization based on the API Key
4. I've also added subsequent verifyLicenseMiddleware to the REST API middleware chain
5. With verifyLicenseMiddleware in the REST API chain, we can now check for res.locals.licenseError in our REST API endpoints. I've added both checks to postFeature and updateFeature accordingly

[bttf]

Tested creating an experiment ref rule

[jdorn]

What happens if the feature currently has environmentSettings for both dev and production, but the update call only specifies changes for production? If I'm following the logic right, I think this will delete the existing dev settings, which we don't want to do. Is that right?

[bttf]

If a feature has envSettings for both dev and production, and the update only includes production, it will not override dev. We use existing to hold existing envSettings and use that as the initial value for acc in the reduce fn, so we only overwrite what is supplied by the update. Additionally, if the update only includes the enabled field for an envSetting (and doesn't specify the rules), we do not erase the rules but include the existing set of rules with the new enabled value ... Let me know if that makes sense

growthbook/packages/back-end/src/services/features.ts

Lines 998 to 1011 in 66f92e3

	return Object.keys(incomingEnvs).reduce((acc, k) => {
	return {
	...acc,
	[k]: {
	enabled: incomingEnvs[k].enabled ?? existing[k].enabled,
	rules: incomingEnvs[k].rules
	? fromApiEnvSettingsRulesToFeatureEnvSettingsRules(
	feature,
	incomingEnvs[k].rules
	)
	: existing[k].rules,
	},
	};
	}, existing);

[bttf]

@igorlovich This is now live.