Flagsmith
Rule engine as a separate NuGet package
Requesting a standalone Flagsmith Engine NuGet package, separate from the Flagsmith Client NuGet, for flexible rule evaluation without the full SDK.
Why:
I need a lightweight rule engine for custom use cases, bypassing the client’s networking and polling features.
Benefits:
Lean Engine: Minimal package for evaluating rules with my own data, reducing overhead. Custom Polling: Freedom to implement my own polling strategy or data source. Event Notification: Tailored event handling to fit my app’s architecture. Less Dependencies: Avoids unnecessary dependencies like Polly, simplifying integration and minimizing version conflicts. Metadata Enrichments: Single location to extend features with additional metadata such as tags.
Proposal:
A dependency-free package with rule evaluation logic, no networking, and optional event hooks, which should be considerably easy to implement by extracting the existing rule evaluation logic into a standalone library.
Conclusion:
This would enhance flexibility and support advanced scenarios where the full client isn’t needed. Thoughts?
Hi @tomerplus500 , thanks for raising this. It's definitely an interesting requirement. What I would say, however, is that the client itself is pretty thin already, so I'm not sure what we'd gain by removing it. I would recommend just using the client and accessing the engine directly (perhaps we would need to expose some public methods in order to do this)?
That being said, we do have the engine split out in other languages so I'm not completely against it, I just don't think it's something that we'd be able to commit to in any short timeframe at the moment, unless there was a more pressing use case for it.
One problem we currently have for example, is that we're using Flagsmith in many of our legacy .NET Framework projects. Since these project use an older version of Polly library and Flagsmith NuGet client is using a newer one, we're having issues with mismatch Polly version at runtime. We usually do binding redirect, but in this case, there is breaking changes between the different versions of Polly.
@tomerplus500 thanks for the additional context here - I can certainly understand the issue, but I'm afraid that it's still not something that we can commit to at the current time. As far as I can tell, we're only using Polly to handle retry logic here, I don't have a good handle on .NET dependency management, but I wonder if we could loosen the dependency constraint on the Polly library if we're not using any of the functionality from the later versions of Polly?
but I wonder if we could loosen the dependency constraint on the Polly library if we're not using any of the functionality from the later versions of Polly?
If you get rid of the Polly dependency and implement a custom retry handler, which is not that complicated, then yes, it will definitely help.