agree with bartek, something name <object>_is_<condition>, should probably return a boolean, or be renamed to more accurately describe what is going on.

In the future, we may want to think about doing some memoization of feature flags; as they probably won't change significantly between calls (staff may change, but I don't have the context why staff are handled special here).

In the future, we may want to think about doing some memoization of feature flags; as they probably won't change significantly between calls (staff may change, but I don't have the context why staff are handled special here).

Response caching is a great idea! A few first thoughts:

• Likely many devices would perform the same request and receive the same response over and over again
• The cache could be an in-memory key-value pair, could be separate for each replica or possibly some Redis instance
• The key consists of platform&staff&version, values are features
• The cache could be simply invalidated when we update some features
• The motivation for this is to decrease the number of DDB reads (and save some money) and possibly improve response times

Anyway we could create a Linear task to discuss this further

I've created a task where we can discuss the caching https://linear.app/comm/issue/ENG-3082/consider-using-cache-in-feature-flags-service. I think it is really not worth it in near future, as it greatly increases the complexity and doesn't introduce measurable value.