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