Technical approach for WebSocket Frame Interception - GSoC 2026 Proposal

29 views

Skip to first unread message

Nisanur Doğan

unread,

Feb 28, 2026, 9:40:14 AM (10 days ago) Feb 28

to dart-gsoc

Hi all,

I'm Nisanur Doğan, a 2nd-year CS student at Boğaziçi University. I've been analyzing the WebSocket/gRPC Support project and following the recent discussions here.

After setting up my environment and reproducing the frame visibility gap, I've been thinking about the implementation strategy. I noticed your point about WebSockets implementing both Stream and StreamSink. This suggests that our interception logic must monitor both the add() calls (sink) and the incoming events (stream) to provide a complete picture in the Network tab.

I was considering the following technical approach for my proposal:

Would a Decorator pattern be the preferred way to wrap the WebSocket object within dart:io to log these frames, or should we look into a deeper integration with the Dart VM Service Protocol (observing SocketEvents)?
Since the goal is to make frames visible like HTTP responses, I'm researching how to serialize these frames so they can be sent over the VM Service to the DevTools frontend without significant performance overhead.

I have documented my initial environment setup and proof-of-concept here: https://github.com/Nisanurdogan38618/gsoc_network_test

I would appreciate any feedback on whether this "interception at the stream level" is the right path to explore for a robust proposal.