Live WebSocket Execution via Plugin Architecture

[AceTheCreator]

Playground: Live WebSocket Execution via Plugin Architecture

The Playground is a powerful interactive surface for exploring AsyncAPI specs, but currently lacks the ability to execute or simulate operations. With the new plugin architecture now available in the React component, we can expose hooks that allow tooling to wire in live WebSocket connections for testing subscribe/publish/send/receive operations directly from the rendered spec.

WebSocket is proposed as the first protocol target (rather than HTTP/Webhook) because its persistent, bidirectional, event-driven nature maps much more naturally onto AsyncAPI's async operation model than a synchronous request/response protocol does.

Proposed Behavior

• Users can open a live WebSocket connection directly from the rendered spec UI to test subscribe/publish/send/receive operations.
• The Playground ships with a built-in default WebSocket plugin that supports:
  • Connecting to a server using the operation's WS/WSS bindings.
  • Sending messages for publish/send operations, constructed from the spec-defined schema.
  • Receiving and streaming incoming messages live for subscribe/receive operations.
  • Disconnecting cleanly, with automatic cleanup on unmount/navigation.

Acceptance Criteria

• Playground registers a default WebSocket plugin for ws/wss protocol bindings
• Users can open/close a connection manually, with a visible connection-status indicator (connecting / open / closed / error)
• Outgoing messages (publish/send) can be composed and sent using the operation's schema, with basic client-side validation before send
• Incoming messages (subscribe/receive) render as a live, scrollable message log, not a single static result
• Reconnection behavior is defined (manual reconnect button at minimum; auto-reconnect with backoff as a stretch goal)
• Errors (connection refused, dropped connection, invalid message against schema) surface gracefully with user-facing messages, distinct from a closed-but-healthy state
• Connections are cleanly torn down when the user navigates away or unmounts the component, to avoid orphaned sockets
• Existing Playground behavior is unaffected when no plugin is registered

Notes

• Out of scope (for this issue): auto-reconnect with backoff, message history persistence across page reloads, and non-WS async protocols (MQTT, AMQP, Kafka), those can be tracked as follow-ups once the plugin pattern is validated here.
• This is a stateful/streaming interaction model, distinct from the request/response model of HTTP plugins, expect the plugin architecture itself to need lifecycle hooks (onOpen, onMessage, onClose, onError) rather than a single call/response hook.

[manik3160]

Hey @AceTheCreator ! opened #1300 for this :)

[aeworxet]

This GitHub issue is submitted for the Microgrant Program calendar-month round 2026-07.

I see this issue was opened on 2026-06-10 (yesterday).

@thulieblack, @derberg - could you please assess whether this issue is ready to be implemented, or does it need a prior discussion?

[KUNDAN1334]

@AceTheCreator can i work on this ?

[aeworxet]

Looping in @Mayaleeeee since this is a frontend-related GitHub issue that might need a design for implementation.

[Mayaleeeee]

Thanks for looping me in! @aeworxet

This plugin architecture and operation simulation sound like an incredibly powerful update for the Playground. Since the core of this issue involves handling HTTP/Webhook protocols, backend request execution, and network states, it is definitely a heavy engineering implementation.

From the UI side, no upfront design deliverables are needed to get this started. Once the logic is built and the team is ready to render the plugin results (response bodies, status codes, and error messages) inline, please tag me on the PR. I’ll step in to do a quick UI/UX review to ensure the new interface elements look seamless and align with our visual standards! 👍

[aeworxet]

This GitHub issue has been submitted for participation in the Microgrant Program with the Advanced Complexity Level.

To carry out the community pre-moderation, please independently assess whether this issue has been classified correctly according to the reasoning outlined in #1299 (comment).

@princerajpoot20

[princerajpoot20]

This GitHub issue has been submitted for participation in the Microgrant Program with the Advanced Complexity Level.

To carry out the community pre-moderation, please independently assess whether this issue has been classified correctly according to the reasoning outlined in #1299 (comment).

@princerajpoot20

Yes, this is an Advanced complexity level.

[aeworxet]

Microgrant Issue's service comment

Text labels: microgrant/2026-09, microgrant/advanced, microgrant/coding
Assignment to regular contributors after: 2026-08-23 00:00:00 UTC+12:00
End Of Life after: 2026-09-30 23:59:59 UTC-12:00

@asyncapi/microgrant_team

The Microgrant Program is not a Mentorship Program. The accepted level of Microgrant Program Participants is Middle/Senior.

Regular contributors should explain in clear terms how they will approach the resolution process when expressing interest in working on this Microgrant Issue.

References: Microgrant Program 101, Microgrant Program Rules

[AceTheCreator]

I'm self-assigning this issue under the microgrant program.