-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add cacheTtlMs option #760
Conversation
When the SDK retrieves data from the EdgeKV, it does so using a single sub-request per call to `variation`, `variationDetail`, or `allFlagsState`. The problem is that Akamai imposes a limit of 4 sub-requests per handler event. If a customer evaluates more than 4 distinct flags during the handling of a single event, subsequent flag lookups would fail. To combat this, we now cache the flag values the first time an evaluation is requested, and we keep that cache in memory for the full duration of the EdgeWorker execution.
544565d
to
0a87198
Compare
@launchdarkly/js-sdk-common size report |
@launchdarkly/js-client-sdk-common size report |
@launchdarkly/js-client-sdk size report |
@@ -2,14 +2,13 @@ import { EdgeProvider } from '.'; | |||
|
|||
/** | |||
* Wraps around an edge provider to cache a copy of the sdk payload locally an explicit request is made to refetch data from the origin. | |||
* The wrapper is neccessary to ensure that we dont make redundant sub-requests from Akamai to fetch an entire environment payload. | |||
* The wrapper is necessary to ensure that we don't make redundant sub-requests from Akamai to fetch an entire environment payload. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should maybe note that, at the time of writing, there is a 4 request sub-limit.
I think we also want to update the docs to indicate using the SDK uses one of their sub-requests. In case they already need to make their own sub requests for other reasons.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think that is a fair point. I still have some loose ends I want to follow up with on this PR, so this isn't getting merged any time soon I don't think.
I'll make sure to get the docs updated and much more explicit about this one we have all this clarified.
packages/sdk/svelte/svelte.config.js
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll want to revert this file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
packages/shared/akamai-edgeworker-sdk/__tests__/featureStore/cacheableStore.test.ts
Outdated
Show resolved
Hide resolved
packages/shared/akamai-edgeworker-sdk/__tests__/featureStore/cacheableStore.test.ts
Outdated
Show resolved
Hide resolved
expect(mockGet).toHaveBeenCalledTimes(1); | ||
|
||
// eslint-disable-next-line no-promise-executor-return | ||
await new Promise((resolve) => setTimeout(resolve, 60)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of depending on time we instead should use fake timers.
Setup
jest.useFakeTimers();
If we want all pending timers to execute, then we use:
await jest.runAllTimersAsync()'
Alternatively you can advance them by a specific amount.
await jest.advanceTimersByTimeAsync(100); // advances by 100ms, things scheduled for less than that should execute.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
packages/shared/akamai-edgeworker-sdk/src/featureStore/cacheableStoreProvider.ts
Outdated
Show resolved
Hide resolved
packages/shared/akamai-edgeworker-sdk/src/featureStore/cacheableStoreProvider.ts
Outdated
Show resolved
Hide resolved
Co-authored-by: Ryan Lamb <[email protected]>
🤖 I have created a release *beep* *boop* --- <details><summary>akamai-edgeworker-sdk-common: 1.4.0</summary> ## [1.4.0](akamai-edgeworker-sdk-common-v1.3.3...akamai-edgeworker-sdk-common-v1.4.0) (2025-01-30) ### Features * Add cacheTtlMs option ([#760](#760)) ([4f961dd](4f961dd)) </details> <details><summary>akamai-server-base-sdk: 2.1.22</summary> ## [2.1.22](akamai-server-base-sdk-v2.1.21...akamai-server-base-sdk-v2.1.22) (2025-01-30) ### Dependencies * The following workspace dependencies were updated * dependencies * @launchdarkly/akamai-edgeworker-sdk-common bumped from ^1.3.3 to ^1.4.0 </details> <details><summary>akamai-server-edgekv-sdk: 1.4.0</summary> ## [1.4.0](akamai-server-edgekv-sdk-v1.3.1...akamai-server-edgekv-sdk-v1.4.0) (2025-01-30) ### Features * Add cacheTtlMs option ([#760](#760)) ([4f961dd](4f961dd)) ### Dependencies * The following workspace dependencies were updated * dependencies * @launchdarkly/akamai-edgeworker-sdk-common bumped from ^1.3.3 to ^1.4.0 </details> --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
When the SDK retrieves data from the EdgeKV, it does so using a single
sub-request per call to
variation
,variationDetail
, orallFlagsState
. The problem is that Akamai imposes a limit of 4sub-requests per handler event.
If a customer evaluates more than 4 distinct flags during the handling
of a single event, subsequent flag lookups would fail. To combat this,
we now cache the flag values for a specified amount of time.