Add ability to hide flags from SDKs

[dabeeeenster]

Overview

There is a common requirement to be able to send a subset of flags to an SDK client. As an example use case, if there is a single Flagsmith project that is being consumed by both a server side and client side SDK. Its probable that some of the server side SDK flags are neither relevant to the client side SDK, and in addition its probably that they would want top be private from the client side SDK.

Potential Approach

We could provide an API key per Tag. This would then filter the flags returned to the SDK to the subset of flags that are tagged with the particular tag.

In the use case above, this would mean having two tags: Server Side and Client Side. Each SDK would then be configured with the API key specific to each Tag.

[khvn26]

I came up with three approaches to this. My initial direction was to explore potential token<->tag relationships, but it quickly became more complex than I'd anticipated due to env key/server-side key disparity.
Keep in mind that all three approaches involve adding feature tags to the environment document for the filtering — this is an engine change.
As you can see I'm very much in favour of Proposal 3. What do you think?

Proposal 1: API key per Tag

One-to-many Token<->(tag, env) relationship. Ability to add tokens to a tag in the UI. When authenticated with a tag token, get a tag by token, filter the resulting flags by tag.

Cons:

• Too many auth codepaths for my taste — env key/server-side key is enough pain to manage.
• Only one tag can be leveraged for filtering features.
• One more DynamoDB table for the Edge, which affects latency.

Pros:

• Latency is only affected for tag tokens — no filtering done when not needed.

Proposal 2: Taggable API keys

Many-to-many Token<->(tag, env) relationship. Ability to add tags to existing tokens. When authenticated with any token, grab its tags along with the environment.
Same tradeoffs as above minus the latency one — here the latency will be affected for all requests.

Proposal 3: tags parameter for SDK endpoints.

Skip the auth modifications altogether. Add the ability to filter output by user-provided tag or tags. Make these configurable in SDKs.

Pros:

• Much simpler implementation — no new models or relations, just the engine part and the filtering part need to be done.
• No latency cost for Edge API.
• No UI changes, only SDK API.

Cons:

• It's a bit more explicit? (Is that a con?)

[khvn26]

I've hit an interesting roadblock where we're not really able to easily extend the feature schema in the document. Additionally, we found that:

• for the use case in question we only need to care about filtering for remote evaluation
• using arbitrary tags for filtering has little value as it's trivial to retrieve all of them

Following the internal discussion, here's what we came up with as the final solution:

1. In Core API, introduce a Feature.local_only: bool field set to False by default.
2. In the UI, add an ability to toggle the server only/protected mode for a given feature during editing/creation.
3. For the environment document schema add a project-level local_only_feature_ids: list[int] field populated in the Core API in accordance with the local_only values.
4. Filter out local_only features in Core/Edge API endpoints.

[h-no]

Hi, I just wanted to add how we use identities, features and tags for your consideration in this.
So we have different types of identities in one environment, we prefix the identities with a type. Some features only makes sense in the context of the type of the identity, so we tag features with the corresponding type.

When fetching the features for the identity it would be nice to filter the request so we only get the features that makes sense for this type of identity, my wish was to be able to do this by perhaps adding a tag as a request parameter in order to only receive features with that particular tag.

In our case with a system-type identity, something like GET /api/v1/identities/?identifier=system-<UUID>&tag=system

[dabeeeenster]

Interesting - thanks @h-no

Have you seen the discussion about context? #1839 Would be interested on your thoughts here!

[matthewelwell]

Released as functionality to mark flags as server side only as per description in this comment.