Skip to content

Conversation

@vazarkevych
Copy link
Collaborator

This PR implements the ETag caching mechanism across both the standard GBFeaturesRepository (for OkHttp) and the NativeJavaGbFeatureRepository (for native Java HTTP clients).

This significantly reduces network bandwidth usage. When features remain unchanged, the server returns a 304 Not Modified response, avoiding the transfer of the redundant response body.

⚙️ What was done

  • ETag Storage: Integrated an LruETagCache to store the last known ETag received from the GrowthBook API.

  • Request Header: Modified the feature fetching logic to include the If-None-Match header 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 Modified response 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 LruETagCacheTest and comprehensive integration tests in GBFeaturesRepositoryEtagTest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant