Use KV in a real application path
Workers KV is a global key-value store for low-latency reads and lightweight shared data.
This example keeps KV simple: one binding, one fetch handler, one assertion.
The fastest way to trust a binding is to wire one small use case end to end before you hide it behind a bigger app.
- Config focus
- Stable namespace naming
- Runtime shape
- Direct and calls in a fetch handler
- Best use
- A tiny cache or session-marker flow
Start by wiring the binding clearly in config
Minimal KV config
Build the application flow around the binding
Treat this as the app-level KV path: the route, event handler, or service module receives a real request and uses the binding to do useful work.
Keep product limits, remote ownership, and fallback behavior visible in the code around the binding instead of hiding everything behind a vague utility too early.
- Prefer a tiny route like this before you wrap KV behind a helper or service layer.
A tiny fetch handler that uses KV
Keep production boundaries visible
- Config focus: Stable namespace naming.
- Runtime shape: Direct and calls in a fetch handler.
- Best use: A tiny cache or session-marker flow.
Start with the boring shape
If the first KV example already feels abstract, it is probably hiding the actual binding semantics instead of teaching them.
Previous
Testing KV
Use the default test harness first. KV is one of the bindings Devflare supports best in local tests.
Next
D1
D1 gets the same stable-name authoring story as KV, but the runtime shape is relational: , , , and prepared statements.