asepharyana
ec3a2867d4
- bun workspaces + Turborepo monorepo (apps/web, apps/mcp; packages/*, scripts) - @mcpedia/core single business-logic layer (Document/Content/Search services) - @mcpedia/db Drizzle schema: documents + weighted tsvector (GIN) for FTS - @mcpedia/parser frontmatter, @mcpedia/search Postgres FTS (ts_rank+ts_headline) - Next.js 16 Web UI (home/doc SSG, search dynamic) + react-markdown render - MCP server (stdio) with 4 tools + in-memory smoke test - scripts/indexer walks content/ -> upserts into Postgres - 4 seed docs; README + PHASES status
1.2 KiB
id, title, type, tags, status, author, created_at, updated_at
| id | title | type | tags | status | author | created_at | updated_at | |||
|---|---|---|---|---|---|---|---|---|---|---|
| websocket-contract | WebSocket Contract | documentation |
|
published | asep | 2026-08-19 | 2026-08-19 |
WebSocket Contract
The WebSocket contract defines how clients establish a bidirectional connection and exchange RPC-style messages with the server. It is the foundation for the type-safe API described in the tRPC integration notes.
Handshake
A client opens a single WebSocket connection and sends an init frame携带 an
auth token. The server answers with ready or closes the socket with code 4401
if the token is invalid.
Message envelope
Every frame uses a JSON envelope:
{ "id": "req-1", "method": "echo", "params": { "text": "hi" } }
The server replies with a matching id and either a result or an error
field. This request/response correlation is what makes the protocol feel like
RPC even though it rides on a single socket.
Timeouts
If the server does not answer within the negotiated timeout, the client should
re-send with the same id rather than opening a new connection. See the
debugging writeup for a common timeout pitfall when proxies buffer frames.