Integration
Integrate WuKongIM from the perspective of an existing product system.
WuKongIM owns real-time connections, channel messaging, persistence, cluster routing, and online delivery. Your product service still owns accounts, authorization, business relationships, content policy, and final business actions.
Confirm the current security boundary first
The current v3 Beta app performs CONNECT negotiation and session encryption, but its default composition does not yet validate connections against stored tokens. Product HTTP routes also have no business-authentication middleware. Put these routes behind a trusted network or authenticated reverse proxy and complete connection identity enforcement before production.
Recommended path
Integration Architecture
Divide responsibilities among clients, the product service, and the WuKongIM cluster.
Authentication
Design UID, device, token, connection, and revocation lifecycles.
Messaging
Understand client and server send paths, acknowledgements, and recovery boundaries.
Webhooks
Consume message and presence events securely and idempotently.
Plugin Extensions
Evaluate node-local hooks, lifecycle, UID bindings, and safety boundaries.
Release Checks
Check identity, connection, messaging, recovery, security, capacity, and rollback before release.
Before choosing platform APIs, learn the shared vocabulary in WuKongIMSDK Core Concepts. Then choose your platform under WuKongIMSDK and follow its task sequence.
Minimum product loop
- The user signs in to your product service instead of proving product identity directly to WuKongIM.
- The product service assigns a stable UID, device identity, and short-lived credential.
- The client discovers a route and connects to the Gateway through an SDK or protocol implementation.
- A client or trusted product service sends messages and checks the protocol-level result.
- The product service receives asynchronous webhooks and places side effects on its own durable queue.
- After a disconnect, the client SDK reconnects and recovers messages; webhooks are not a client inbox.
Pre-production checklist
| Area | What you must confirm |
|---|---|
| Identity | UIDs have one authority and untrusted clients cannot mint tokens |
| Network | Product HTTP routes are not exposed directly and Gateway ingress is controlled |
| Authorization | Relationships, membership, allowlists, denylists, and content rules follow product policy |
| Messages | Payloads are versioned and senders retain client_msg_no |
| Callbacks | The receiver persists first, returns 200 second, and tolerates duplicates |
| Operations | Queue pressure, failures, retry exhaustion, and end-to-end latency are monitored |
Begin with stable server boundaries and webhooks. Introduce Plugin Extensions only when a synchronous or post-commit hook genuinely needs to run near a node.
After implementation, use the Release Checks with your real clients, server configuration, networks, and rollback plan.