Integration decisions
Use the least elaborate layer that matches the service you actually have. Move up when it removes repeated work you already maintain, and include its configuration and backend contract in the decision.
Direct, declarative, or generated clients
| Choice | Use when | What you own | Poor fit |
|---|---|---|---|
Direct Fetcher | A few calls or endpoint-specific behavior | Paths, request options, result selection, boundary validation | Many repeated endpoint declarations that drift independently |
| Decorator service | Stable methods benefit from a shared service declaration | Metadata/compiler setup, parameter annotations, endpoint accuracy | You do not want decorator configuration or the API is mostly ad hoc |
| Generated service | An actual OpenAPI document is the maintained contract | Generation command/configuration, review and compilation of output, regeneration on spec changes | Missing or inaccurate specification; server semantics absent from the document |
These share the runtime request boundary: core implements request/extraction (packages/fetcher/src/fetcher.ts:242), decorator has a metadata runtime dependency (packages/decorator/package.json:58), and the 5.x generator is a CLI (packages/generator/src/cli.ts:8). OpenAPI exports type definitions (packages/openapi/src/index.ts:21). Neither annotations nor generated types validate response data at runtime or invent missing server semantics.
Start with HTTP requests, then use declarative client or the verified workflow in generated client. Configuration details live in decorator reference and generator reference. The generator is part of the 5.x line; from 6.0 it lives in the Wow repository. Check the peer graph separately from the code you expect to execute.
Data views
Fetcher main ships no table or data-view component. @ahoo-wang/fetcher-viewer (View, Viewer, FetcherViewer) is deprecated on npm and frozen in the 5.x line (npm 5.1.x, branch 5.x); its guides and reference remain for existing consumers. It is superseded by @ahoo-wang/wow-view-engine in the Wow repository, on npm from Wow 9.2.0 (9.2.1 or later accepts fetcher 6; see wow.ahoo.me). For a new table today, compose React request state with the table component your application already uses, and keep filtering, sorting and pagination in your data service.
Service-specific integrations
| Integration | Required contract | Responsibility retained by the service/application |
|---|---|---|
| Wow (5.x client) | Command results/stages and supported query DSL | Authorization, tenant isolation, idempotency, projection freshness |
| CoSec | Token storage, attribution headers, refresh endpoints/session rules | Identity lifetime, replay safety, server authorization, which origins receive credentials (isTrusted) |
| SSE / OpenAI streaming | Compatible event stream and payload format | Partial-result UX, cancellation, reconnect policy if required |
Client-side conditions describe the query sent; they are not access control. Command stages describe protocol progress; they are not a universal consistency guarantee. CoSec's guarded refresh implementation is specific to its authentication exchange (packages/cosec/src/authorizationResponseInterceptor.ts:80), while SSE extraction requires a readable body (packages/eventstream/src/eventStreamResultExtractor.ts:41).
Continue with CoSec and streaming. The Wow client belongs to the 5.x line (Wow guide); from 6.0 it is documented at wow.ahoo.me. Before sharing these integrations across identities, read runtime support; before adding retries, read the failure model.