Skip to content

Add PLUGGABLE storage support to the Node.js SDK - #954

Open
justin-masse wants to merge 1 commit into
splitio:developmentfrom
justin-masse:feat/node-pluggable-storage
Open

justin-masse wants to merge 1 commit into
splitio:developmentfrom
justin-masse:feat/node-pluggable-storage

Conversation

@justin-masse

Copy link
Copy Markdown

What

Lets the Node.js SDK use PLUGGABLE storage in consumer and consumer_partial modes, the same way the browser client already can.

Why

The implementation already exists in splitio-commons and is described there as a "Pluggable storage factory for consumer server-side & client-side SplitFactory". It builds its keys with KeyBuilderSS — the server-side key builder — and already branches on CONSUMER_PARTIAL_MODE. @splitsoftware/splitio-browserjs exposes it by delegating storage validation to validateStorageCS in commons.

The Node client doesn't, for one reason: src/settings/storage/node.js switches over STORAGE_REDIS and STORAGE_MEMORY and anything else falls through to throw 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

  • validateStorage accepts PLUGGABLE in consumer modes, and in standalone/localhost logs an error and falls back to MEMORY — mirroring how REDIS is handled.
  • getStorage returns PluggableStorage for that type, passing prefix and wrapper.
  • The consumer-mode error message now names both async storages.

How did you test this code?

  • New unit tests covering consumer and consumer_partial, and the standalone fallback.
  • src/*/**/__tests__/**/!(browser).spec.js — 33/33 passing.
  • eslint src — clean.
  • End to end against a wrapper backed by a plain Map: before this change a consumer_partial factory emits SDK_READY_TIMED_OUT; after it, getTreatment returns 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.

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.
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