DEV Community

Farshad Khazaei Fard
Farshad Khazaei Fard

Posted on

I wanted a Go networking engine that gets out of the way, so I built one (Breeze).

Over the past few months, I've been working on Breeze, a networking engine built on top of gnet.

The goal wasn't to create "another web framework."

The goal was to explore how far an event-loop architecture can go for modern Go services.

Some design decisions I made:

โšก Event-loop driven architecture
๐ŸŒ Native HTTP and WebSocket support
๐Ÿš€ WebSocket fast-path (avoids the HTTP router after the upgrade)
๐Ÿงต Worker pool to keep the event loop responsive
๐Ÿ“ฆ Low-allocation request handling
๐Ÿ“š Built-in Swagger support
๐Ÿ”Œ Built-in WebSocket Hub for real-time applications

One design choice I'm particularly interested in discussing is that HTTP and WebSocket aren't treated the same.

Every incoming connection is classified inside the event loop. HTTP requests follow the router, while upgraded WebSocket connections are dispatched directly to the WebSocket engine. It keeps the hot path small and avoids unnecessary work once the protocol is established.

The project is still evolving, and I'm deliberately questioning every architectural decision before calling it "production ready."

I'd genuinely appreciate feedback from developers who have experience with:

High-concurrency Go servers
gnet or event-loop architectures
Large-scale WebSocket systems
Low-latency backend services

Repository:
https://github.com/nelthaarion/breeze
Documentation:
https://nelthaarion.github.io/breeze

I'm especially interested in hearing what you would change. Architecture discussions are often more valuable than benchmark numbers.

Happy to answer any questions or dive into implementation details. ๐Ÿš€

Top comments (0)