Guides
Worked slices — how a feature is actually layered, how to cache it, and what to measure once it ships.
The API reference tells you what each endpoint takes and returns. These pages are the other half: what a whole feature looks like when it is built on top of them.
| Guide | What it works through |
|---|---|
| Domain modelling with the SDK | One feature end to end — Zod schema, use-case, oRPC procedure, TanStack Query hook, component |
| Caching with the KV store | Cache-aside, rate limits, feature flags and idempotency, with the TTL semantics that make them safe |
| Analytics | What to emit, what Connect already counts for you, and reading it back |
The pattern every guide follows
Read Domain modelling first. Every other guide, and every worked example in the API reference, is written against the layering it establishes:
schema (Zod) → use-case → procedure (oRPC) → hook (TanStack Query) → component
↓
Connect SDKOne direction, all the way down. A use-case may call Connect; a component never does. Three rules hold it together, and they are worth stating once here because every example assumes them:
Connect calls happen on the server. @cosmoops/connect-sdk/server holds
your API key and is fenced off from browser bundles by an export condition —
importing it from a client component fails the build rather than shipping the
key.
The workspace comes from the session, never from an input. A workspaceId
a caller can supply is a cross-tenant write one forgotten check away. Reading
it from the session is also what makes a workspace switch work without
touching your handlers.
Entitlement is checked in the use-case, not the component. A gate in the UI is the explanation; the check in the use-case is the enforcement. Ship both — the first without the second is a hidden button in front of an open endpoint.