Transport is one architectural choice
The same blockchain event can be delivered through different transports and decoded into different payloads. A faster wire protocol does not move an event earlier in the ledger lifecycle. Choose the event stage and schema first, then select a transport that fits the consumer.
Compare the mechanisms
| Transport | Mechanism | Useful question |
|---|---|---|
| SSE | One-way server-to-client events over an HTTP response | Does a browser need simple pushed updates? |
| WebSocket | A bidirectional persistent connection | Does the API use subscriptions and client messages? |
| gRPC | Typed RPC with streaming and HTTP/2 flow control | Does a backend need schema-driven high-volume ingestion? |
These are protocol descriptions. They do not announce an SSE product or imply that every Supanode network exposes all three transports. Read the selected product Docs for its actual interface.
A practical selection process
- Identify whether the consumer is a browser, backend collector or historical job.
- Measure expected payload size, messages per second and processing capacity.
- Check authentication, proxy buffering, keepalive and connection limits.
- Test reconnect recovery, deduplication and the available historical gap-repair mechanism.
Recovery is an application contract
SSE can carry event IDs and Last-Event-ID, but a server must implement the corresponding replay behavior. WebSocket reconnection does not automatically restore subscriptions. gRPC flow control regulates delivery pressure; it does not create an unlimited replay archive. For a Solana backend, use the existing streaming guide for data-stage choices and then test the supported Supanode interface with your real filters.