feat(): add string type support#91
Conversation
tdarci
left a comment
There was a problem hiding this comment.
cool.
What are the implications for our Consul backing store for this data?
Also, there is the part of the api that clients call to get all the dcdr values. Is the change reflected there?
No Consul (or Redis) implications - features are stored as opaque JSON bytes of the |
trevorrosenkilde
left a comment
There was a problem hiding this comment.
Not opposed to this, but do have to say we have string functionality in Growthbook IIRC. Any reason we're leaning on dcdr over Growthbook here? Perhaps just the barrier to entry (i.e. dcdr is on all our services whereas GB is not?)
Yep, that's the reason.
I think we can switch to GB later if we want to, but we gonna need to add GB and GB API key to some base kube template so we can inject that data to every service and worker (+ change our GrowthBook interface to add String support too). Another reason - for such low-level stuff we don't have any vendor locks / third-party dependencies. |
Makes total sense 👍🏻 |
Good call out, @tdarci. @a-karev-vsc - you may want to check out the dcdr package in godel (which is the dcdr-api). We may need to be careful with returning these new string values - clients may be brittle against this. I don't think we need to return these string values there - may be safest/easiest to just exclude those in the response. |
Yep, already replied above, it's fully compatible and safe :) |
trevorrosenkilde
left a comment
There was a problem hiding this comment.
Thanks for the validations!
There was a problem hiding this comment.
Let's make sure the dcdr-api deployment that's in godel still works. Handler here: https://github.com/vsco/godel/blob/4ddbfd38c257a6e2c3c62d691848dc206b9b5b62/dcdr/api/handlers/features_handler.go#L39
<-- sounds like you have already verified this? I think I missed the comment
Phase 1 testing (local Consul, new and old dcdr binary):// new binary: // old binary via main.go: |
Phase 2 testing (dev):// new binary set string value: // new binary read value: // old binary read value:
|
Description
Adds free-form
stringfeature flags alongsidebooleanandpercentile, plus an explicit--typeflag forset.Stringtype,ParseFeatureType,ParseValueForType,StringValue().GetString(feature)(returns""if absent or not a string); added toIFace.--type/-tflag (boolean|percentile|string). Boolean/percentile still inferred when omitted;stringrequires--type=string. Clearer validation errors.READMEupdated for thestringtype,GetString, and--type.ParseValueAndFeatureTypenow infersStringas the catch-all (wasInvalid); the CLI uses that to require--type=string.Invalidis still used byParseFeatureTypeand as the controller's error sentinel.Why
It can simplify string dcdr flags (like potential
min-log-levelfor the new structured logging in godel).Dcdr previously only accepted booleans and 0.0–1.0 floats, so there was no clean way to store a string value.
Usage
Compatibility
"feature_type":"string". No migration.IsAvailable/ScaleValuedefaults (false/min), never panic.--typerequirement prevents a typo'd bool/percentile from silently becoming a string.IFacegainsGetString; concrete types and the mock inherit it via embedding - only hand-rolledIFaceimplementations would need it.Tests
KVsToFeatureMap→ served JSON →UpdateFeatures→GetString.go build,go vet, andgo test