feat: Implement ETag caching #187
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR implements the ETag caching mechanism across both the standard
GBFeaturesRepository(for OkHttp) and theNativeJavaGbFeatureRepository(for native Java HTTP clients).This significantly reduces network bandwidth usage. When features remain unchanged, the server returns a
304 Not Modifiedresponse, avoiding the transfer of the redundant response body.⚙️ What was done
ETag Storage: Integrated an
LruETagCacheto store the last known ETag received from the GrowthBook API.Request Header: Modified the feature fetching logic to include the
If-None-Matchheader in network requests if a corresponding ETag is available in the cache.304 Handling: Updated the repository's request handler to correctly process the
HTTP 304 Not Modifiedresponse code. On receiving 304, the method ensures the existing features JSON data is retained, and the cache TTL (Time-To-Live) is updated to prevent immediate revalidation.Testing: Added unit test in
LruETagCacheTestand comprehensive integration tests inGBFeaturesRepositoryEtagTest.