Comments (7)
Hey, @thompson-tomo! Thanks for the feature request 😄 This sounds like a sensible feature, but we unfortunately do not have the capacity to implement it ourselves at the moment. Would you be willing to implement it yourself and send us a PR that we could have a look at? This goes for your other two requests too (#184, #185).
If not, I'd be happy to capture your ideas in our idea board and we'll revisit them for our next quarterly planning session.
from unleash-client-dotnet.
@thomasheartm sure I have no problem working on the issues I am raising and submitting them via PR'S. Based on the scope and increased flexibility I think one of the first issues to tackle should be #192 as it would simplify this issue & others.
from unleash-client-dotnet.
Hey, @thompson-tomo. Thanks for getting back to me (and also for the new feature requests).
We've had a look through them on our end, and we're not sure we want to tackle all of them. Some of them sound relevant however, so we'll take a bit of time and respond to each on of them separately, if you don't mind. Please hold tight in the meantime.
But with all the feature requests you've opened, could you outline for me the end goal? There appears to be a red thread binding them together; what is your use case for all these things?
from unleash-client-dotnet.
The end goal which I am looking for is flexibility in use cases:
- Feature flags have the flexibility to be sourced from unleash or static files which is injected into ICONFIGURATION in either Unleash Or Microsoft Schema
- the processing of the strategies is triggered by Microsoft Feature flag SDK including having feature flag's in *.cshtml. The strategies processed could be Unleash strategies or Microsoft strategies.
- All logging is done using the suggested approach from Microsoft & removes deprecation warnings.
- usage of feature flags is consolidated alongside other application metrics ie performance and can be transported to the same analysis tools ie ELK
- An exporter is available to export the standard metrics to Unleash.
In my use case feature flags will be transported to distributed servers via Rabbitmq and cached locally Hence the ICONFIGURATION. The usage should be visible in ELK with the upload also occurring via Rabbitmq. Feature flags should easily control ui aspects.
Hope that provides further info.
I would suggest looking at the ELK libs as a sample of what I am thinking.
from unleash-client-dotnet.
Hello @thompson-tomo!
We were working on proper replies for individual issues, but I'll address your concerns here instead.
Feature flags have the flexibility to be sourced from unleash or static files which is injected into ICONFIGURATION in either Unleash Or Microsoft Schema
Unleash has support for a concept we call Bootstrapping. In short you can configure Unleash with one of two existing bootstrappers during startup, or write your own bootstrapper. The provided bootstrappers support loading from static file or URL
the processing of the strategies is triggered by Microsoft Feature flag SDK including having feature flag's in *.cshtml. The strategies processed could be Unleash strategies or Microsoft strategies.
The strategies we provide are available in the NuGet package as public classes and the SDK is open source, so you are free to configure these with anything you like but you will have to write some plumbing code yourself. And implementing a wrapper around the usage of Unleash is also a good idea.
All logging is done using the suggested approach from Microsoft & removes deprecation warnings.
Logging and serialization is on our radar to fix
- usage of feature flags is consolidated alongside other application metrics ie performance and can be transported to the same analysis tools ie ELK
- An exporter is available to export the standard metrics to Unleash.
All metrics are sent to Unleash through an implementation of IUnleashApiClient
that is exposed as a setting on UnleashSettings
class used when creating a new Unleash instance. There are admin API endpoints on the Unleash service from which metrics can be obtained, but there's also the option of implementing the IUnleashApiClient
interface your end and forwarding the metrics from that. You would have to either implement a feature flag fetching mechanism there or proxy to an instance of the UnleashApiClient as well to implement that interface, but this could also be used to address your static file question. We're recording this idea however, so thank you, it could be useful to look at transporting metrics out from the Unleash service!
In short I think you should be able to achieve most of your goals here by implementing/configuring/connecting some of our interfaces/apis. We're looking at improving the host-setup parts of Unleash to cater to both .NET Framework and .NET Core environments, and we're also looking at improving logging/serialization.
Overall this SDK exists to serve users of the Unleash platform and we have quite a few of these SDKs. They all need to conform to the same spec/feature set with a few platform specific needs having to differ between them. So larger reorganizations, splitting out parts of it, and maintaining SDK level integrations are currently not a priority
from unleash-client-dotnet.
Hi @daveleek
I am perfectly fine with the functionality being offered in a consistent across platforms but the big thing I like to see is consistency in the stack & simplicity in integrating a new library. At the same I also appreciate reducing maintenance effort across the board rather simply transferring the responsibility to others which in the end results in overall more effort. I know what I want to do could be done by building a lot of extensions but fear impact on performance & bloat caused by doing so.
I think the logical first step would be to facilitate the DI registration then move on to loading config from application Config. This would then enable devs to do the core functionality like they do with other libraries. Then work other aspects
This is part of the reason why I created small focused issues as othwise it wouldn't be managable. I lam happy to be contributing on this journey.
from unleash-client-dotnet.
Hello @thompson-tomo.
I've closed a few of the issues you posted as they don't align with what this SDK is trying to achieve.
This SDKs primary concern is to be an integration SDK for the Unleash eco system on the .NET platforms.
It is not intended as a standalone library.
The hosting/setup aspect of this library is something we're discussing improving, we are also looking at improving logging, and we're in the process of evaluating which framework versions we should support moving forwards.
from unleash-client-dotnet.
Related Issues (20)
- Reducation in target frameworks HOT 1
- Replacement of LibLog with Microsoft.Extensions.Logging.Abstractions HOT 1
- Record metrics using System.Diagnostics.Metrics HOT 2
- Split of nuget package HOT 2
- Negate operator not work in dot net sdk HOT 3
- api/client/metrics return 400 when using System.Text.Json for seriaization. HOT 5
- Feature toggles are fetched in a chron manner instead of when a feature flag is actually needed HOT 9
- Removal of Microsoft.CSharp package dependency HOT 4
- Update licence inclusion in Nuget HOT 2
- Platform specific test suite for .NET Framework to run in CI HOT 2
- Receiving Json Parsing error when receiving 304 status when ETag in response header is null. HOT 1
- We see a lot "The `appName` property is required. It was not present on the data you sent." HOT 2
- Unhandled exceptions in Unleash's background process HOT 2
- synchronousInitialization: true should throw exception if exception happens in the init flow (network, authorization, etc) HOT 3
- InvalidOperationException being thrown from Unleash.Scheduling.SystemTimerScheduledTaskManager.ConfigureTask HOT 2
- Empty userId breaks gradual rollout 100% expected behavior. HOT 3
- Built-in JSON serialization without reflection HOT 3
- Avoid subtle errors and improve DX when setting a custom serializer HOT 3
- Support for hostname strategy HOT 2
- Default config should not create files and Unit Tests should not create files HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from unleash-client-dotnet.