Shared Environments - ideas for a solution

[dabeeeenster]

Sometimes people want to be able to share flags from more than 1 enviroment amongst their own applications/services.

There are several use cases for this, but for the sake of this example, imagine there was a mobile app with iOS and Android versions, split across two completely separate code-bases. Some flags would want to be shared between both iOS and Android applications, but some would be specific to each platform. Currently there are two main ways to achieve this in Flagsmith:

1. Have 1 Flagsmith Project that has flags for both iOS and Android platforms. The downside here is that some flags are brought into each platform that have no use as they only pertain to the other platform.
2. Duplicate Flags across two Flagsmith Projects, with obvious drawbacks of keeping duplicate values in sync.

How else could we solve this situation?

My Idea: "Meta Projects"

Create 3 regular Flagsmith projects:

• iOS
• Android
• Mobile Platform

The "Mobile Platform" project would contain shared flags across both iOS and Android.

Now create 2 "Meta Projects". Meta projects are basically just references to more than 1 Project that have their own SDK keys.

• Meta iOS, containing
  • iOS Project reference
  • Mobile Project reference
• Meta Android
  • Android Project reference
  • Mobile Project reference

Each Meta Project would have its own SDK keys. Requesting Flags for that Project would return a single document that combines the flags from all the referenced Projects.

Problems

• Where do we store Identities?
• What about namespace collisions from flags with the same name across referenced projects?
• ... no doubt things I've not considered

Identities

Suggest there is 1 "lead" project defined within the Meta Project that stores Identities. This could be the same shared project. We don't care.

Flag namespaces

Each Project reference could contain a flag name prefix. So for example, the iOS project namespace could be ios.. Then a Flag in the iOS project called enableOAuth would be referenced in the Flagsmith sdk with the flag name ios.enableOAuth.

[kyle-ssg]

• I think we’d want to be able to select which features get associated. A lot of the cases I’ve come across only want a few of the flags.
• I wonder if associating identities would be optional. The associated projects would likely come from separate teams, if identities were combined they could end up with a convoluted identity with similar trait names due to teams having different conventions.
• I guess we’d apply a tag to features that come from a different project.
• What would happen to identity overrides and segment overrides?

[dabeeeenster]

• I think we’d want to be able to select which features get associated. A lot of the cases I’ve come across only want a few of the flags.

For a v1, I think just having all flags shared is OK? Most use cases want a shared set and a service/app specific set, and hence the example I described above tends to work for most use cases? We maybe need to do more customer development here.

• I wonder if associating identities would be optional. The associated projects would likely come from separate teams, if identities were combined they could end up with a convoluted identity with similar trait names due to teams having different conventions.

I think in this situation there's generally a "lead" Flagsmith project - this would be selected when creating the shared project, and Identities would just be stored there. Or they could be stored in the shared project itself. We could maybe allow this to be defined by the user.

• I guess we’d apply a tag to features that come from a different project.

Tags don't get sent to clients? So I don't see how this helps?

• What would happen to identity overrides and segment overrides?

They would work as they currently do? Not sure what you mean?

[dabeeeenster]

An alternative solution is Cross-Project dependencies

[matthewelwell]

For me, this is way over-engineered. I think the solution to the problem defined in the discussion would be to better solve by utilising tags. To achieve this, we would need to:

1. Add the ability to create multiple client side keys for an environment.
2. Add the ability to assign tags to keys, so that they only receive a subset of flags, based on the tag(s).

Unless I'm missing something, that solves the problems that you have described above. You would just create a single project and tag features accordingly. You can also use tag-based permissions as required to ensure that users cannot modify flags that they shouldn't be able to.