Breeze, Ultra-Fast Web Framework

Releases
1

Hey Gophers,

I’ve been building a networking engine in Go called Breeze, and I want feedback from people who have actually fought high-concurrency systems.

This is not a wrapper around net/http.

It is built on top of gnet event-loop architecture, where everything happens inside OnTraffic.

Core idea:

Each connection is classified at the event-loop level:

  • WebSocket → bypasses HTTP parsing completely

  • HTTP → manually reassembled per connection and routed

  • Blocking work → pushed into a controlled worker pool

Design choices:

:high_voltage: gnet-based single-reactor event loop
:high_voltage: WebSocket fast-path (zero HTTP overhead after detection)
:high_voltage: Per-FD HTTP buffer reassembly (sync.Map based)
:high_voltage: Dedicated WebSocket connection registry
:high_voltage: Custom frame parser with strict limits
:high_voltage: Worker pool sized to avoid event-loop starvation
:high_voltage: Easy swagger
:high_voltage: Lots of middlewares

What this really means:

Instead of treating HTTP + WS as “framework features”,

Breeze treats them as two execution paths inside a protocol multiplexer.

The event loop decides everything.

What I want feedback on:

  • Is splitting WS/HTTP at OnTraffic the right long-term design?

  • Would you trust manual HTTP reassembly in production at scale?

  • Where would you expect contention first: sync.Map, buffers, or worker queue?

  • What breaks first at 10k–100k concurrent connections in this model?

Repo:

Documentation:

I’m currently stress-testing edge cases and trying to break the architecture before it breaks in production.

Would appreciate real-world war stories from people who’ve built similar systems.

1 Like
2

Stunning scope for this project. But I would almost certainly not use it in my professional environment.

The reason is: When I have an application so hot/critical that it actually needs a performance boost compared to the standard library - it is so critical I would never use anything which is not battle-tested by a massive user-base for many years in high production work loads.

Your websocket handling looks quite good and is a gap in the standard library - you could think about packing it into a stand-alone library, because there is a higher chance for people using it, since they will need an external library anyway.

2 Likes
3

Agreed. Also - with LLMs the amount of new LLM-generated libraries is staggering. The number of “check out this new library I built!” posts have grown exponentially and it has made me more skeptical of new libraries. Especially when they have emojis on every line of the README.

Also - does this support TLS? How would you actually deploy this?

3 Likes
4

Nice Project. Starred your Repo

5

actually :smiley: , Im the worst person in 2 things , making post and comments for project, honestly I always take some help ( read it complete :smiley: ) from LLM to generate them

6

honestly, I wanted too seprate ws and framework at the beggining, but was suffering from lack of time, at the beginning, I tried to make a proxy ws client which works with any engine ( net/http , fasthttp, gnet ) but these 2 projects ( breeze and breezeORM ) didnt let me

7

thank you

rose