feat: add provider configuration for ofrep

[thepabloaguilar]

This PR can be considered the very first step towards the implementation of OpenFeature Remote Evaluation Protocol!

It's the implementation of an optional endpoint used by the protocol, I've decided to implement this endpoint first instead of the others (which actually are mandatory) because its simplicity and we can discuss some things here better.

The first thing you may ask is about the endpoint route, which is: /ofrep/*/ofrep/v1/configuration
Why we have ofrep twice? The answer is, because OFREP defines all the routes as follow:

• /ofrep/v1/evaluate/flags/{key}
• /ofrep/v1/evaluate/flags
• /ofrep/v1/configuration

And as you can see there's a important part missing in those, the namespace flipt supports! So the strategy we can use is always prefix with /ofrep/{namespace} and when instantiating the ofrep client just give the address as follow: http://my.flipt/ofrep/my-namespace

Refs #2980

[codecov]

Codecov Report

Attention: Patch coverage is 86.66667% with 4 lines in your changes missing coverage. Please review.

Project coverage is 63.37%. Comparing base (9d1dfaa) to head (80f124e).

Files	Patch %	Lines
internal/cmd/http.go	0.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3247      +/-   ##
==========================================
- Coverage   63.38%   63.37%   -0.02%     
==========================================
  Files         164      166       +2     
  Lines       13317    13347      +30     
==========================================
+ Hits         8441     8458      +17     
- Misses       4222     4231       +9     
- Partials      654      658       +4     

Flag	Coverage Δ
unittests	63.37% <86.66%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[GeorgeMac]

This is looking great @thepabloaguilar. Thanks for taking it on.
One thought on here regarding our SDK generator and that path.
Might be worth skipping the SDK generation for the OFREP service as we're probably never going to use it.

[markphelps]

Hey @thepabloaguilar thanks for getting this work started!! Very much appreciated!

I actually asked in the OpenFeature Slack channel a couple months ago about the best way to support namespaces in our case, and they suggested we use the custom header support that OFREP clients already provide.

Here's the link to the slack thread (you need to be in the CNFC slack first I think): https://cloud-native.slack.com/archives/C066A48LK35/p1714414882954439

So in our case we would do something like this (using Go OFREP provider as an example):

provider := ofrep.NewProvider(
    "http://localhost:8080",
    ofrep.WithHeaderProvider(func() (name string, value string) {
      return "X-Flipt-Namespace", "foo"
    })
)

Then in our server side impl we would need to pull out this header value to get the correct namespace

[thepabloaguilar]

Thanks for the comment @markphelps! I thought about using the header strategy first but I was like: Idk if it's correct to put a specific thing in something which is trying to generalize the interactions. But I'd stick with that, will add the header handling

[thepabloaguilar]

I've tested locally and it seems to be compliant with the OpenAPI Spec:

curl localhost:8080/ofrep/v1/configuration
{"name":"flipt","capabilities":{"cacheInvalidation":{"polling":{"enabled":false,"minPollingIntervalMs":"0"}},"flagEvaluation":{"supportedTypes":["string","boolean"]}}}

Prettyfied:

{
  "name": "flipt",
  "capabilities": {
    "cacheInvalidation": {
      "polling": {
        "enabled": false,
        "minPollingIntervalMs": "0"
      }
    },
    "flagEvaluation": {
      "supportedTypes": [
        "string",
        "boolean"
      ]
    }
  }
}

[erka]

I've tested locally and it seems to be compliant with the OpenAPI Spec:

curl localhost:8080/ofrep/v1/configuration
{"name":"flipt","capabilities":{"cacheInvalidation":{"polling":{"enabled":false,"minPollingIntervalMs":"0"}},"flagEvaluation":{"supportedTypes":["string","boolean"]}}}

Hi @thepabloaguilar. Great work of OFREP!

There is one small thing that isn't in complaint with OFREP OpenAPI Spec:

minPollingIntervalMs:
  type: number
     description: |
         Minimum polling interval (in millisecond) supported by the flag management system.
          The provider should ensure not to set any polling value under this minimum.
      examples:
          - 60000

In our case, minPollingIntervalMs is a string not a number. This discrepancy arises because in gRPC/protobuf, int64 is encoded as a string. To be fully compliant with the OFREP spec, we could change minPollingIntervalMs to something like uint32. WDYT?

[thepabloaguilar]

Sure @erka, I've just pushed the changes! But AFAIK even as a string it's a valid number for the JSON parsers

[erka]

Sure @erka, I've just pushed the changes! But AFAIK even as a string it's a valid number for the JSON parsers

@thepabloaguilar Unfortunately, Go doesn't

var r map[string]int
err := json.Unmarshal([]byte(`{"a":"1"}`), &r)
fmt.Println(r, err)
// Output:
// map[a:0] json: cannot unmarshal string into Go value of type int

[erka]

@thepabloaguilar One downside with mage proto is that it doesn't remove previously generated files when proto files change. We have to removesdk/go/http/ofrep.sdk.gen.go and sdk/go/ofrep.sdk.gen.go manually :(

[thepabloaguilar]

@erka done!

[erka]

@thepabloaguilar Excellent beginning on the new feature!

[markphelps]

looks great to me @thepabloaguilar !! Thank you for kicking off this work 🚀

[thepabloaguilar]

I'm already working on the evaluate endpoint!