[GSoC 2026][Nikhil] Multi-Protocol Support (WS, MQTT, gRPC) + CLI

[animator]

Discussions on GSoC 2026 project
https://summerofcode.withgoogle.com/programs/2026/projects/8mOJR8XY

[badnikhil]

Key Points discussed in the Meeting on 30 May 2026.

1. Refactoring of the RequestModel to use PolyMorphic ProtocolModel Abstraction instead of specific models for every protocol , Its Tradeoffs ,what and how it will affect the project in future.
2. how mqtt and WebSockets support will be added to Apidash , significant UI/UX improvements(Heartbeat , MQTT auth , better topic UI , WS json templates , filtering of ws responses.).
3. How to Improve Documentation of my proposed work.
4. I also need to research more about how mqtt and WS protocols work.. for a better view of improvements in the UX.

Tasks i am onto:

• Draft a PR refactoring the RequestModel via discussed approach (Sealed Class ).
• Progress on WS along with the discussed Improvements in the UI and open a PR

[badnikhil]

we need to update our models to abstract to work with the latest environment..
there is already a open PR for the same .
#1644
if i include this in my pr for websockets a lot of irrelevant changes will be included. thats why the migration should be tracked seperately.
i am holding my PR so that i can push clean commit history.. i will open the draft PR very soon for the refactoring.

[badnikhil]

2 June 2026

1. Raised a draft PR(Requestmodel refactor #1692 ) for request model refactor.
2. Regenerated all freezed models in Migrate models to freezed v3 #1644 . (also upgraded dependencies , sdk)
3. PR for websockets will be raised after the above PR(for a clean commit history and prevent merge conflicts)..

[badnikhil]

Key points discussed in the meeting on 2 June 2026.
1.How the refactoring was approached and an conclusion about its testing(All the tests pass successfully including melos test except a few which also fail on main branch).
2. Websockets will be implemented into ApiDash for the next iteration before net meeting.
3. Updated Doc for RequestModel Refactor - > here

Tasks :

• ready websockets for the next iteration
• json templates in WS UI
• Filters to query out from long list of responses

[badnikhil]

4 june 2026

1. Opened a PR for Websockets
2. added json template feature
3. Tried to implement auth.. but i need to know more about post upgrade auths in Websockets.
4. Basic auth is done for Handshake level request authentication(Initial HTTP request for upgrading).

[badnikhil]

Key Points discussed in the Meeting on 5 June 2026.

1. Implement filtering and querying capabilities for the WebSocket message stream.
2. Add support for configuring parameters for WS connections.
3. Relocate action buttons to a more intuitive and accessible position in the UI.
4. Implement configurable ping/pong heartbeat intervals to keep connections alive.
5. Add optional collapsing/expanding for large incoming WebSocket messages to prevent UI lag and improve readability.
6. Experiment with and implement quick access to recent history and templates.
7. Move json templates directly into the request pane, removing the need for popups.
8. Ensure robust logging and retrieval of past WebSocket sessions and messages.
9. Ensure Dashbot can handle WebSocket use cases effectively, and test code generation for WS requests.
10. More focus on real UX

docs are attach here and will be updated accordingly
mqtt
ws
grpc

[badnikhil]

8 June 2026

1. All the tasks from meeting on 5th June are done
2. Updated UI for mqtt from poc one
3. Updated websockets doc. and purposed a new approach for storing messages in history .Check 3.8 and 3.9

[badnikhil]

Key Points discussed in the Meeting on 10 May 2026.

1. Updated UI of MQTT and WS.

Tasks i am onto

• Implement MQTT v5 features
• Add test coverage for websockets

[badnikhil]

Key Points discussed in the Meeting on 13 May 2026.

1. fixed and merged the Migrate Models PR.
2. MQTT V5 and doc updates.

[badnikhil]

17 July 2026

1. Added Lots of Tests in WS branch.
2. Worked on MQTT v5 features and some tests.

[badnikhil]

Key Points discussed in the Meeting on 18 june 2026.

1. Doc Updates
2. Mqtt v5 features and wildcards
3. PR review

[badnikhil]

24 June 2026

1. The additional features in V5 are implemented.
2. Comprehensive Tests are also added and updated current ones.
3. Ws #1694 Needs to be Reviewed , because MQTT branch was not from main but WS as ConnectionManager and RealtimeConsoleView were common in both , Similar for gRPC. Next PRs will be Opened after this one.

Next Tasks

• Start working on gRPC
• Building CLI

[badnikhil]

26 June 2026

1. MQTT is almost done just need a final iteration over all the v5 features .
2. gRPC is also under progress.

Attention Required -
Either #1637 Needs to be Reviewed or i include those changes in my New PR for CLI . both are correct because the changes are pre-requisite for CLI . just need to know your preferred choice!

I will Open the PRs for MQTT and gRPC as soon as #1694 is merged. and for CLI will open after Mentor's Answer on the above question.

[badnikhil]

Key points from the Meeting on 28 June 2026

• HeartBeats should be configurable at Application layer Related Doc about current impl.
• The Messages(Text) in ResponsePane need some rework
• Integrate Dashbot with relevant Use-Cases like semantic search
• Features should have a Explaination/Use-case ( dashbot will be used for this so this task is moved to dashbot usecases)

5. Attention on Android UI/UX

[animator]

List of other highlighted points:

• Add more websocket APIs in foss42/apis to demonstrate all features
• DashBot use cases with WebSocket and MQTT - like search, code generation, feature help, etc.
• heartbeat UX for end user .. why it did not work for API Dash endpoint?
• wss:// ws:// missing schema issue?
• Websocket/MQTT response view .. watch only the value of particular fields user is interested in
• MQTT server like foss42/apis which lets you test MQTT features that have been developed
• Use cases / stories for WebSocket/MQTT features for better understanding by end user
• MQTT filter UX - topic, keyword
• Reproducibility of MQTT testing of all features
• QoS testing mentioned by Ragul

[badnikhil]

Dashbot usecases(ws)

• Semantic search over the log - simple search with a optional cap on no of messages(to save cost)
• Explain this WebSocket connection — plain-language walkthrough of handshake + first messages. Mirrors "Explain Response".
• What is the server sending? — summarize/pattern-group recent received messages
• Debug my connection issue — analyze lifecycle (connected→error→disconnected), suggest fixes (ws vs wss, missing auth header, add heartbeat). Mirrors "Debug Error". High.
• Generate WS client code (JS/Python/Dart) from url/headers + sample messages. Mirrors "Generate Code".
• Generate WS tests — connect/send/assert-response test code.
• Explain a message I'm sending — infer intent of a selected outgoing payload.
• Why did my message fail? — sent message → error correlation, suggest payload fix.
• Generate WS API documentation — infer message formats from history → Markdown.
• Connection health summary — uptime/disconnects/latency from timestamps.
• Auto-classify message types in history (ping/auth/data/subscription).
  Dashbot usecases(mqtt)
• Explain this MQTT connection — plain-language: "you're connected to a message post office; you're listening on these topics; here's what arrived". mirror of WS Explain;
• Debug my connection — lifecycle analysis + the failure analysis. Mirror of WS Debug. Action whitelist candidates targeting a new ChatActionTarget.mqttRequestModel: fix brokerUrl/port, toggle useTLS, set clientId etc.
• Why am I not receiving messages? — connection is fine but topic/wildcard mismatch, QoS/session-expiry loss, or disabled topic row. DashBot can string-match publishTopic against subscription wildcards and explain in everyday words.
• What's coming in on my topics? — summarize history grouped by topic (metadata): "home/temp sends a number every 5 seconds; alerts/door sent 2 messages". MQTT version of WS "what is the server sending".
• Help me pick a topic / explain wildcards — + vs # in plain words ("one folder" vs "everything below"), propose a subscription from topics seen in history
• Session persistence advisor — detect QoS>0 + sessionExpiryInterval=0 and suggest turning persistence on (one-field auto-fix).
• Generate MQTT client code (python/JS, Dart mqtt_client) from broker settings + topics.
• Explain/set up a Last Will message
• v5 features guide — user properties, request/response (responseTopic/correlationData) explained simply.
• Find in messages — same as WS usecase (LLM-over-log/semantic search, raised cap), now topic-aware

[badnikhil]

Update on the highlighted points:

• Add more websocket APIs in foss42/apis to demonstrate all features
• DashBot use cases with WebSocket and MQTT - like search, code generation, feature help, etc.
• heartbeat UX for end user .. why it did not work for API Dash endpoint?
• wss:// ws:// missing schema issue?
• Websocket/MQTT response view .. watch only the value of particular fields user is interested in
• MQTT server like foss42/apis which lets you test MQTT features that have been developed
• Use cases / stories for WebSocket/MQTT features for better understanding by end user
• MQTT filter UX - topic, keyword
• Reproducibility of MQTT testing of all features
• QoS testing mentioned by Ragul