Repository navigation
Add PLUGGABLE storage support to the Node.js SDK - #954
Open
justin-masse wants to merge 1 commit into
Open
justin-masse wants to merge 1 commit into
justin-masse wants to merge 1 commit into
Conversation
The pluggable storage implementation already lives in splitio-commons and is documented there as a "Pluggable storage factory for consumer server-side & client-side SplitFactory". It builds server-side keys with KeyBuilderSS and already handles consumer_partial. The browser client exposes it; the Node client does not, only because its own settings validator switches over REDIS and MEMORY and falls through to "A REDIS storage is required on consumer mode". This wires the existing implementation up: - validateStorage accepts PLUGGABLE in consumer and consumer_partial modes, and falls back to MEMORY with an error in standalone and localhost, which mirrors how REDIS is handled. - getStorage returns PluggableStorage for that type. - The consumer-mode error message now names both async storages. Verified against a wrapper backed by a plain Map: before the change a consumer_partial factory emits SDK_READY_TIMED_OUT; after it, getTreatment resolves the configured treatment with no network calls. Tests added for both consumer modes and for the standalone fallback; the Node unit suite passes (33/33) and eslint is clean.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What
Lets the Node.js SDK use
PLUGGABLEstorage in consumer and consumer_partial modes, the same way the browser client already can.Why
The implementation already exists in
splitio-commonsand is described there as a "Pluggable storage factory for consumer server-side & client-side SplitFactory". It builds its keys withKeyBuilderSS— the server-side key builder — and already branches onCONSUMER_PARTIAL_MODE.@splitsoftware/splitio-browserjsexposes it by delegating storage validation tovalidateStorageCSin commons.The Node client doesn't, for one reason:
src/settings/storage/node.jsswitches overSTORAGE_REDISandSTORAGE_MEMORYand anything else falls through tothrow new Error('A REDIS storage is required on consumer mode'). So the engine supports it, the key builder is the server-side one, and only the settings layer refuses.The motivating case is AWS Lambda. ElastiCache has no public endpoint, so a Redis consumer setup requires putting every Lambda into a VPC; a pluggable wrapper over DynamoDB avoids that while keeping evaluation local and the Synchronizer in charge of the key layout.
Changes
validateStorageacceptsPLUGGABLEin consumer modes, and in standalone/localhost logs an error and falls back toMEMORY— mirroring howREDISis handled.getStoragereturnsPluggableStoragefor that type, passingprefixandwrapper.How did you test this code?
consumerandconsumer_partial, and the standalone fallback.src/*/**/__tests__/**/!(browser).spec.js— 33/33 passing.eslint src— clean.Map: before this change aconsumer_partialfactory emitsSDK_READY_TIMED_OUT; after it,getTreatmentreturns the configured treatment with no network calls.Happy to add an integration test alongside the existing Redis e2e suites, or to adjust the API shape, if you'd prefer something different.