feat: extract core flagd evaluation and API modules#1696
feat: extract core flagd evaluation and API modules#1696
Conversation
Summary of ChangesHello @toddbaert, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly refactors the flagd provider by extracting its in-process flag evaluation capabilities into dedicated, reusable modules: Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces a significant and well-executed refactoring by extracting the core flag evaluation logic into new flagd-api and flagd-core modules. This improves modularity and aligns with the architecture of other flagd SDKs. The changes also include updating to grpc-netty-shaded to prevent dependency conflicts, which is a great improvement for a library. The tests have been diligently updated to reflect these architectural changes.
I have found one critical issue in the new flagd-core module where change detection for removed flags is missing. This will prevent consumers from being notified of flag deletions. A detailed comment with a suggested fix is provided.
tools/flagd-core/src/main/java/dev/openfeature/contrib/tools/flagd/core/FlagdCore.java
Show resolved
Hide resolved
2f7202f to
c0421e1
Compare
3daa738 to
c8ec1d4
Compare
c8ec1d4 to
73fda14
Compare
| : new SyncStreamQueueSource(options); | ||
| } | ||
|
|
||
| private <T> ProviderEvaluation<T> resolve(Class<T> type, String key, EvaluationContext ctx) { |
There was a problem hiding this comment.
This is one of the few things that weren't moved 1:1
This class was eliminated because FlagdCore now handles flag storage internally and includes the metadata in evaluation results directly. The StorageQueryResult intermediary is no longer needed.
73fda14 to
06112b2
Compare
| * Interface for in-process flag evaluation in flagd. | ||
| * Combines flag storage and evaluation into a single abstraction. | ||
| */ | ||
| public interface Evaluator { |
There was a problem hiding this comment.
This new interface is equivalent to that in JS' flagd core, and the Go equivalent - though only the minimal features have been implemented (we don't need bulk evaluation here).
06112b2 to
f51baa8
Compare
| for module in "${modules[@]}" | ||
| do | ||
| mvn --batch-mode --projects $module --settings release/m2-settings.xml -DskipTests -Dcheckstyle.skip clean deploy | ||
| mvn --batch-mode --projects $module --settings release/m2-settings.xml -DskipTests -Dcheckstyle.skip -Dflagd-core.version=$FLAGD_CORE_VERSION clean deploy |
There was a problem hiding this comment.
This pins the flagd-core dep in the flagd-provider to the current version in source, ensuring we never have incompatibility.
837eb0a to
f7a5c66
Compare
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
f7a5c66 to
bcfae8a
Compare
Extraction of the core evaluator of flagd into 2 modules:
I've also included some basic automation to make sure the local version of flagd-core is always resolved in development, and at provider release the dep is pinned to exactly what is present locally.
I've intentionally made as few changes as possible, and made no functional changes; note that a large volume of the changes are
git mvoperations.Fixes: #1695