GSoC 2026 — WebSocket DevTools Network Panel | Working Sample + Architecture Question

[A B D U L L 六 H]

Hi Elliott and Samuel,

I am Abdullah, a Flutter developer from Pakistan, applying for
"Add WebSocket/gRPC Support to Flutter DevTools Network Panel".

I have been following the discussions in this group closely —
especially Samuel's reply to Divyansh about SDK-level
instrumentation being the preferred direction, and Samuel's
note to Mohammed that WebSocket and gRPC should be treated
as separate concerns. Based on these insights, I built a
working sample.

GitHub: https://github.com/abdullah-arain9/websocket-devtools-profiler

---

Key decisions in my implementation:

1. ProfileableWebSocket implements dart:io WebSocket interface
   as a proper drop-in replacement — not just a loose wrapper.
   Existing apps change ONE line:

   Before: final socket = await WebSocket.connect(url);
   After:  final socket = await WebSocketProfiler.connect(url);

2. Events posted via dart:developer.Timeline.instantSync() —
   same mechanism HTTP profiling uses in dart:io today.
   This means DevTools can consume WebSocket events through
   existing infrastructure — no new VM Service stream needed
   in Phase 1.

3. WebSocketProfiler registry handles multiple simultaneous
   connections — each with a unique connectionId per socket.

4. Working CLI demo output:

   ID   TIME           DIR    TYPE   BYTES   ELAPSED
   1    14:06:41.786   sent   text   20B     +22274ms   hello GSOC community
   2    14:06:42.196   recv   text   20B     +22684ms   hello GSOC community
   3    14:06:53.829   sent   text   17B     +34317ms   its Abdullah Here
   4    14:06:54.090   recv   text   17B     +34578ms   its Abdullah Here

   Summary:
   Connections: 1  |  Sent: 67B  |  Received: 67B

5. 9 unit tests passing — MockWebSocket used, no network required.

---

Architecture Question:

For dart:io SDK integration, I see two options:

Option A: Add profiling hooks directly inside _WebSocketImpl —
          similar to how _HttpClientRequest uses _httpProfileData
          today. This keeps WebSocket profiling consistent with
          existing HTTP patterns in the SDK.

Option B: Introduce a new WebSocket-specific event category in
          VM Service — separate from existing HTTP network events.

Based on the HTTP profiling pattern already in dart:io, I am
leaning toward Option A. Would this direction align with the
team's vision?

Looking forward to your feedback before I finalize my proposal.

Best regards,
Abdullah Arain
GitHub: https://github.com/abdullah-arain9