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. 🚀