feat: ofrep provider

[Rahul-Baradol]

This PR

• adds OFREP provider

Related Issues

Fixes #51

Follow-up Tasks

• Dev testing
• Unit tests
• Docs

[Rahul-Baradol]

@erenatas
PR is ready for review... please let me know your thoughts!

[erenatas]

You are quick :) I will have a look today

[erenatas]

@beeme1mr Hey, do we have any behavioral tests for OFREP?

@Rahul-Baradol it looks like a nice start, however I don't see any have documentation, code coverage. You can have a look at what we have done over flagd

[Rahul-Baradol]

Yeah right...took this as a start, and wanted your input before proceeding.
No problem, will write the tests and docs, and we can take from there!

[erenatas]

Yeah right...took this as a start, and wanted your input before proceeding. No problem, will write the tests and docs, and we can take from there!

Its a good start :). The implementation reuses the same reqwest client as well 👍

[Rahul-Baradol]

@erenatas
have added UTCs and docs...

[erka]

I’ve made some modifications to your implementation in this PR

[erenatas]

Having a look at: https://github.com/open-feature/protocol/blob/main/guideline/dynamic-context-provider.md You did most of the work so big kudos!

I see 2 things are missing:

1. provider can receive 429 response (rate limiting):

   429: The provider has reached the rate limit of the flag management system. In that situation the provider should read the Retry-After header from the response and ensure that no call to the endpoint happened before this date. Every evaluation happening before the retry after date should error and return the default value.
   In this case you should handle this in your responses such as:

   match response.status() {
       // ... existing cases ...
       StatusCode::TOO_MANY_REQUESTS => {
           ....
   }

   user should be caching this on the client side so perhaps you can return an Err

2. guideline says:

   baseURL: The base URL of the flag management system.
   This must be the base of the URL pointing before the /ofrep namespace of the API.
   In the constructor, the provider should check if the baseURL is a valid URL and return an error if the URL is invalid.

   You can utilize url crate for handling this.

[erka]

Great start @Rahul-Baradol ! There might be a few things missing, but it’s definitely headed in the right direction.

[erenatas]

@Rahul-Baradol, hi, I was away for the past 2 weeks but I will be back from next week. Let me know when its ready for review, and I will have a look.

[beeme1mr]

Hey, do we have any behavioral tests for OFREP?

@Rahul-Baradol @erenatas here's what we currently have for requirements https://github.com/open-feature/protocol/blob/main/guideline/dynamic-context-provider.md. Please note that this is for dynamic context providers (e.g. server).

[erenatas]

Hey, do we have any behavioral tests for OFREP?

@Rahul-Baradol @erenatas here's what we currently have for requirements https://github.com/open-feature/protocol/blob/main/guideline/dynamic-context-provider.md. Please note that this is for dynamic context providers (e.g. server).

Hey, overall this implementation looks good to me as well. Perhaps we can do a 0.0.1 release, wdyt?

[Rahul-Baradol]

Sure @erenatas we can go ahead !