[FEATURE] Unified flagd-evaluator PoC (Java/Python/...) – reduced maintenance, PoC, and reference

[aepfli]

Requirements

This issue summarizes the initial efforts around the new Rust-based "flagd-evaluator" PoC and the integration of this unified implementation with Java and Python SDKs.

References:

• flagd-evaluator repository: https://github.com/open-feature-forking/flagd-evaluator
• flagd-evaluator latest release (v0.1.1): https://github.com/open-feature-forking/flagd-evaluator/releases/tag/v0.1.1
• Python SDK PoC: feat(flagd): use flagd-evaluator (rust unified implementation) for python - POC - java uses the same with wasm  python-sdk-contrib#328
• Java SDK PoC: feat(flagd): Wasmanized flagd - this is just a rough PoC java-sdk-contrib#1672
• Rust SDK PoC: refactor(in-process): flagd-evaluator PoC rust-sdk-contrib#94

Highlights:

• The flagd-evaluator is now a WASM-compiled Rust implementation, designed for reuse across SDKs and languages via WASM adapters.
• Recognized reduction in maintenance burden by having a single unified logic core, replacing divergent and duplicated implementations in each language SDK.
• The logic for the evaluator was mainly copied and adapted from the existing Rust flagd provider, acknowledging original authorship and design origins.

Disclaimer:
These efforts are strictly a Proof of Concept (PoC) and side project explorations, intended to validate the unified evaluator approach.
All implementations referenced are experimental, incomplete, and require further evaluation, polish, and design discussion.
Please do not consider any of the PoC integrations production-ready! These are provided to open up community feedback and provoke discussion on future direction.
More rigorous review and additional time should be invested into making these approaches robust.

Next Steps / Callouts:

• Seeking feedback from maintainers and users on this approach.
• Questions around performance, API flexibility, and safety/validation still need thorough investigation.
• Not intended for production without further maturation.

Summary: This unified approach should lead to easier updates, reduced maintenance, and more consistent behavior across SDKs. Community input is welcome at this early stage.

Performance

Benchmark Comparison: WASM vs Native JsonLogic in Java

Comprehensive JMH benchmarks comparing the new WASM evaluator against the existing native Java JsonLogic resolver:

Scenario	Old (JsonLogic)	New (WASM)	Notes
Simple Flag (no targeting)	0.019 µs	3.88 µs	WASM call overhead
Empty Context	0.019 µs	3.94 µs	Same as simple flag
Targeting No Match (small ctx)	3.66 µs	14.2 µs	~4x slower
Targeting Match (1000+ ctx entries)	345 µs	1592 µs	~5x slower

Key Findings:

• WASM has ~3-4µs baseline overhead per call (unavoidable)
• For complex targeting with large contexts, context serialization dominates
• Short-circuit optimization helps significantly for flags without targeting
• Pre-allocated buffers eliminate per-evaluation allocation overhead

[aepfli]

theorycrafting especially for wasm usage. The Wasm usage relies on a JSON representation of the Context. This is somewhat expensive if no Context is needed at all (static evaluation). Adding a boolean method checking if context is needed, and else provide an empty context without serialization.

Alternatively we could use a host function and provide some kind of global unified map for each evaluation, where we store the context, and provide the key to the evaluation. the host function could resolve the context based on the unique evaluation key, and maybe also provide methods to retrieve simple values based on key rather than serializing the whole object

[erenatas]

Hey Simon! Interesting idea, especially where language binding is not a feasible option! I'd be curious to know what the performance impact of web assembly would be. I see you already started looking into PyO3, I think same can be achieved for Java with jni-rs.

Somewhat related, I've been testing PyO3 binding from in-process rust flagd provider implementation (mainly for boolean evaluations) and it took less effort than I expected. I'd expect we can do the same for most (if not for all) of the languages that flagd supports as client/provider.

Would be happy to chat further and let me know if I can help. Cheers!

[aepfli]

More than happy to discuss this and taking a look. I even thought about javascript bindings already.

I think we can have one repository for just the evaluator, and generate all kind of libraries etc. from this repository. In java chicory allows compile time wasm to Javacode generation, which should then be pretty fast and utilize all the JVM features, like garbage collection, JIT and so on. Which would be my long time goal.

I already had a chat with @beeme1mr too, and we want to discuss this approach on a broader level and see how we can move forward.

By now I even think that we can actually accept some kind of minor performance impact for the benefit of unified code and easier maintenance.

[aepfli]

@open-feature/flagd-triagers - mentioning for attention :)