-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add domain as an openfeature concept #229
Conversation
Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
Would this allow for multiple clients across multiple (or the same) provider? |
Yes, exactly. The functionality already exists in many SDKs. |
Ya, it exists but is (IMHO) confusingly named, so I like this change. |
I agree with the motivation, the current wording around named clients is a bit awkward. I don't think the word namespace makes things clear though. A namespace usually denotes a logical grouping of identifiers or symbols. I propose we survey some examples of APIs solving similar problems to get a better idea of the alternatives. As a first data point, the Python |
@federicobond I thought namespace would be a good fit because it's a logical grouping of clients to a provider. However, I would happily change the proposal if we can find a more appropriate term. |
Thanks for the feedback everyone. I've updated the PR to use the term |
Co-authored-by: Todd Baert <todd.baert@dynatrace.com> Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
Thanks for the great reviews and feedback. I'll merge this on Wednesday the 24th unless there's an objection. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good - thank you :)
## This PR - adds domain as a concept to the server and web SDK - adds a deprecation warning anywhere client name was exposed to users. - fixes an issue in the web SDK where context set on a domain before a provider is registered was not used. ## Addresses fixes #820 4aa9657 ### Notes This change is based on [this spec](open-feature/spec#229) change. I tried to make it a non-breaking change but I may have missed an untested condition. Please carefully review to make sure I didn't miss anything. ### Follow-up Tasks - Update the doc readme parser to support "domain". - Update the NestJS and React SDKS. We should consider making those a breaking change since they're sub 1.0. --------- Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com> Signed-off-by: Todd Baert <todd.baert@dynatrace.com> Co-authored-by: Todd Baert <todd.baert@dynatrace.com>
<!-- Please use this template for your pull request. --> <!-- Please use the sections that you need and delete other sections --> ## This PR <!-- add the description of the PR here --> - adds support for domains - removes named clients ### Related Issues <!-- add here the GitHub issue that this PR resolves if applicable --> relates to open-feature/spec#229 --------- Signed-off-by: Lukas Reining <lukas.reining@codecentric.de> Co-authored-by: Michael Beemer <beeme1mr@users.noreply.github.com>
This PR
domain
as a conceptdomain
domain
as client metadataRelated Issues
Fixes #228
Follow-up Tasks