Closed aholmes closed 2 months ago
I can take a look this afternoon tomorrow! (This comment always said tomorrow, ignore that edit history.)
Can you explain what "caching" means in this context? Is it simply that the feature flags are cached within the running application?
Can you explain what "caching" means in this context? Is it simply that the feature flags are cached within the running application?
It looks like it's cached within a CachingFeatureFlagRouter
object, so I suppose it depends on how you use the object
Can you explain what "caching" means in this context? Is it simply that the feature flags are cached within the running application?
"Caching" here means that the specific CachingFeatureFlagRouter
class is a feature flag router that maintains an internal cache of flags and their values. On its own, that means anything it "sets" is then retrieved (when feature_is_enabled
is called) without operations outside of itself. This then extends to subclasses of itself that can take advantage of this. In the case of DBFeatureFlagRouter
, it uses CachingFeatureFlagRouter
's behavior to avoid querying the database every time something needs to know if a flag is enabled or not.
Looks good! I'll happily debate minute style details and class architecture philosophy as long as you let me, but you're free to disengage at any point.
I appreciate the feedback - after all, these changes came from a team discussion about our coding patterns.
@nwiltsie I've finished all the changes related to our discussions.
The base
FeatureFlagRouter
was doing too much. This PR abstracts its operations into aCachingFeatureFlagRouter
that can be used by other feature flag subclasses, or does not have to be used. This allows consumers to rely on theFeatureFlagRouter
interface and base class without implementations having potentially unexpected behaviors with the caching operations that used to exist in the base class.Closes #95