WebSocket/gRPC DevTools Scope Clarification and Proposal Direction

[Divyansh Shah]

Hi Elliott, Samuel,

I’m Divyansh, and I’ve been actively contributing to Flutter. One of my PRs was recently merged into the Flutter repository:

https://github.com/flutter/flutter/pull/182051

I also have another PR currently under review(Expose computeLineMetrics on RenderParagraph by crackedhandle · Pull Request #181240 · flutter/flutter). Working through these contributions has helped me understand the framework–engine workflow, platform channel integration patterns, and the expectations around core code reviews.

Thanks for the clarification regarding scope — focusing primarily on WebSocket support makes sense.

I’ve been exploring the current HTTP instrumentation path in DevTools (via dart:developer events surfaced through the VM Service), and I’m trying to understand the cleanest architectural insertion point for WebSocket profiling.

From my investigation, there seem to be two possible approaches:

1. Instrument at the dart:io WebSocket implementation level and emit structured VM events (similar to HTTP profiling events), allowing DevTools to consume them generically.

2. Prototype a wrapper-based approach (e.g., a ProfileableWebSocket) to validate the frame event model before integrating at the SDK level.

I’m inclined toward SDK-level instrumentation to avoid requiring user-side code changes. I’d appreciate guidance on whether extending the existing network event stream in the VM Service would be preferred, or if introducing a dedicated WebSocket event category would be architecturally cleaner.

I’m currently prototyping a small wrapper-based traffic logger to validate the frame model (timestamp, direction, type, and size) before drafting a detailed design proposal.

Looking forward to your thoughts.

Best regards,
Divyansh Shah

[Samuel Rawlins]

Hi Divyansh, sorry for the extreme delay. Replies inline:

On Thu, Mar 5, 2026 at 1:16 PM 'Divyansh Shah' via dart-gsoc <dart...@googlegroups.com> wrote:

Hi Elliott, Samuel,

I’m Divyansh, and I’ve been actively contributing to Flutter. One of my PRs was recently merged into the Flutter repository:

https://github.com/flutter/flutter/pull/182051

I also have another PR currently under review(Expose computeLineMetrics on RenderParagraph by crackedhandle · Pull Request #181240 · flutter/flutter). Working through these contributions has helped me understand the framework–engine workflow, platform channel integration patterns, and the expectations around core code reviews.

Thanks for the clarification regarding scope — focusing primarily on WebSocket support makes sense.

I’ve been exploring the current HTTP instrumentation path in DevTools (via dart:developer events surfaced through the VM Service), and I’m trying to understand the cleanest architectural insertion point for WebSocket profiling.

From my investigation, there seem to be two possible approaches:

1. Instrument at the dart:io WebSocket implementation level and emit structured VM events (similar to HTTP profiling events), allowing DevTools to consume them generically.

2. Prototype a wrapper-based approach (e.g., a ProfileableWebSocket) to validate the frame event model before integrating at the SDK level.

I’m inclined toward SDK-level instrumentation to avoid requiring user-side code changes. I’d appreciate guidance on whether extending the existing network event stream in the VM Service would be preferred, or if introducing a dedicated WebSocket event category would be architecturally cleaner.

I agree; this is close to how the ultimate implementation would work. 

I’m currently prototyping a small wrapper-based traffic logger to validate the frame model (timestamp, direction, type, and size) before drafting a detailed design proposal.

This is a good way to quickly play with ideas, yes; it's nice to have a little CLI tool that does not require constant re-compilation of the SDK. 

Looking forward to your thoughts.

Best regards,
Divyansh Shah

--
You received this message because you are subscribed to the Google Groups "dart-gsoc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dart-gsoc+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dart-gsoc/e3ceb9c6-53c4-4097-b2e4-9b7c658959c3n%40googlegroups.com.

[Divyansh Shah]

Hey Samuel

I built a working prototype based on our discussion.
It captures WebSocket frame-level events, performs request-response pairing, tracks latency, and emits structured JSON events similar to how DevTools consumes VM Service data.
Here’s the prototype:
https://github.com/crackedhandle/devtools-websocket-profiler
I’d really appreciate your feedback on the event model and how this could map into the DevTools Network panel.
Thank you for your time.

[Samuel Rawlins]

Thanks much Divyansh! I'm going to have a look at your prototype, and will respond with my thoughts in a day or two.

To view this discussion visit https://groups.google.com/d/msgid/dart-gsoc/98cfbaad-2ae6-4c17-ae82-b266d0aeaa51n%40googlegroups.com.