dx(examples): use redisStorage.fromEnv() in storefront-redis.mjs (#167)

[TheBlackBit]

In plain terms

One of our example files connects to a hosted database (Redis) so a shopping cart survives a restart.
To do that, it had to read four environment variables by hand and stitch them together. The library now
has a one-line helper that does exactly that, so the example just calls it. Same behavior, four lines
of setup become one.

What you're approving

• One example file changes. No library code, no tests, nothing published to users.
• The example behaves exactly as before: with the database credentials set, it uses the database; with
  them unset, it runs in memory. The startup message still says which one it picked.
• Worst case if it's wrong: this one example fails to start on a developer's machine. It is a
  demo script, not something a customer runs.

How to test

npm run build
node examples/storefront-redis.mjs
#   → persistence : IN-MEMORY — set KV_REST_API_URL/TOKEN for Redis

KV_REST_API_URL=https://fake.upstash.io KV_REST_API_TOKEN=faketoken node examples/storefront-redis.mjs
#   → persistence : Redis (namespace "phone-demo")

I ran both, plus a third case (the Upstash variable pair with a custom REDIS_NAMESPACE), and all three
print the same thing they printed before this change. Full suites also pass: 484 tests in the gate
package, 115 in the storefront package.

---

For reviewers — the detail

Why

#167. PR
#128 added redisStorage.fromEnv(), which
reads the standard hosted-Redis connection variables — Vercel KV (KV_REST_API_URL +
KV_REST_API_TOKEN) or Upstash (UPSTASH_REDIS_REST_URL + UPSTASH_REDIS_REST_TOKEN) — and
returns a storage provider, or undefined when none are set. This example was still doing that by hand.

Per the repo's DX rubric (docs/reference/architecture-principles.md, Principle 12 — "the example IS
the DX test"), hand-wiring in an example is the signal the library should absorb it. #128 built the
helper; this uses it.

The change

-const redisUrl = process.env.KV_REST_API_URL ?? process.env.UPSTASH_REDIS_REST_URL;
-const redisToken = process.env.KV_REST_API_TOKEN ?? process.env.UPSTASH_REDIS_REST_TOKEN;
 const namespace = process.env.REDIS_NAMESPACE ?? "phone-demo";
-
-const storage =
-  redisUrl && redisToken ? redisStorage({ url: redisUrl, token: redisToken, namespace }) : undefined;
+const storage = redisStorage.fromEnv({ namespace });

Behavior is preserved, with one deliberate tightening: the old code picked the URL and the token
independently, so a stale KV_REST_API_URL left over next to a complete Upstash pair would have built a
client from one provider's URL and the other's token. fromEnv() selects a complete pair atomically,
so that mix can't happen. Everything else is identical, including undefined feeding the storage ? … : …
startup log.

Why this one didn't wait for a release

Its sibling, #166 (the same cleanup in
examples/quickstart/), is blocked until the next npm publish, because that example installs the
published packages and the published 0.4.0 has no fromEnv. This file is different: examples/ is not
an npm workspace and has no package.json, so it resolves @openmobilehub/credentagent-storefront
through the repo's workspace symlink — it runs this repo's built source, which has fromEnv on main as
of #128.

Not covered by CI

No CI job runs examples/storefront-redis.mjs (it needs a public tunnel and a phone to be useful), which
is why the manual runs above are the verification.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
credentagent-demo	Ready	Preview	Jul 30, 2026 11:33pm