Endpoint to tell which version/edition the API is available (plus or not)

[ssangervasi]

trafficstars

As of https://github.com/ethyca/fidesctl-plus/issues/78 the non-Plus UI uses a request to /plus/health to determine whether the backend has Plus endpoints. An error response disables Plus features, a success enables them (the body is disregarded). This works implicitly because the main server does not have any /plus routes.

This should be replaced with an explicit API for detecting whether Plus is enabled. This should be a single endpoint that is served by both Fidesctl and Fidesctl-plus without relying on an error response. This could be a new endpoint (e.g. edition, features, etc) or additional information on the health endpoint (which already has a version field).

Whatever endpoint+format is chosen, fidesctl-plus must be configured to override the endpoint or inform the fidesctl handler that plus is enabled.

[mfbrown]

It might be worth considering if we should also/instead use the feature flag framework from Fidesops which should now be part of control.

[allisonking]

Popping in here with some thoughts because of https://github.com/ethyca/fidesctl-plus/pull/219

From what I've seen, there are two types of "features" we want to be able to flag:

• Features that are being built that we don't want to show yet (I believe this is covered by the framework from fidesops, which uses https://github.com/romaindso/react-feature-flags). The source of truth for these are a flags.json file in the admin-ui folder
• Features that are plus only which should only render when we are hosting with the plus server. The source of truth for this still needs to be figured out (what this ticket is about) but would probably be one of the ones Sebastian outlined above

It would be cool if we could combine both of those needs into one system. Some possibilities:

• The plus dockerfile adds an entry to flags.json with just plus: true. The drawback of this is that it would only work with the built dockerfile, not for local devs just running a make server in plus
• Add some entires to fides.toml and then an endpoint in fides core which reads that file and makes an endpoint out of it which has a payload similar to what flags.json has now. I think this would mean plus would not have to have its own endpoint—it would just need to extend its own fides.toml with the additional flags it wants

It might also be cool to...

• Be able to override with a dev value (similar to .env.development) such that developers do not have to remember to turn the flag values on/off before shipping a thing (or accidentally committing a flag on/off)
• Be able to override values at one easy place (so that people who need to do demos can switch their stuff on/off... perhaps even after build time!). I think the fides.toml solution might cover this, if certain entries can be overwritten by environment variables? (I think they can, but I'm not 100% sure)