When you need more than one instance
EachKweri instance is bound to a single baseURL and owns an isolated cache. If your app talks to several APIs, use one instance per API — that’s the correct design, not just a convenience:
Cache keys are
method + path + params — the baseURL is not part of the key. So two APIs that both expose /users would collide in a shared cache. Separate instances give you correct isolation, plus independent eviction and per-API staleTime/cacheTime.createKweriClients (named map)
Create several named instances that share defaults. Each entry is a baseURL string (shorthand) or full per-client options:
destroyAll():
createKweriFactory (low-level primitive)
createKweriClients is built on this. It captures defaults and returns instances when invoked, so you control lifetime:
Presets
Opinionated default profiles for common project types. GC is automatic (honorscacheTime in the browser), so presets don’t set gcInterval.
defaults and override per client as needed.
Per-environment patterns
Because the factory returns instances on call, the application chooses the instantiation scope:- SPA
- SSR / RSC
- Multi-tenant / dynamic
Module-level singletons are fine — one cache for the app’s lifetime.
Path hooks per instance
Each API has its own generatedEndpointByMethod (its own types), so path hooks are bound per (instance, EndpointByMethod) pair — you can’t share one useGet across APIs. Create a hook set per API and group them:
Per-API auth
Auth differs per API, so it’s a per-clientfetcher, not a shared default:
DevTools with multiple instances
EnablingenableDevTools on several instances is safe — they share one panel with an instance switcher in the header (no stacked overlays). Each instance appears in the switcher labelled by its baseURL, or by devtools.label if set:
The first instance to enable devtools mounts the panel, so panel-level options like
position come from that instance. The panel unmounts automatically when the last instance is destroyed.