DEV Community: Farshad Khazaei Fard

We Don't Need Another Go ORM. We Need a Better One.

Farshad Khazaei Fard — Mon, 13 Jul 2026 09:49:39 +0000

The Go ecosystem already has excellent ORMs.

So why build another one?

Because most of them force developers to choose between two things:

🚀 Performance
😊 Developer Experience

You rarely get both.

That question led to BreezeORM.

The Problem

As applications grow, database access becomes one of the biggest bottlenecks.

Developers often end up writing:

Raw SQL for speed
ORMs for productivity
A mix of both... and lots of maintenance headaches

Neither approach feels ideal.

Raw SQL gives complete control—but quickly becomes difficult to maintain.

Traditional ORMs make development easier—but sometimes hide expensive queries, allocate unnecessary objects, or generate SQL you didn't intend.

There should be a middle ground.

What BreezeORM Tries to Solve

Instead of treating SQL as something to hide, BreezeORM embraces it.

Its design focuses on:

⚡ Low-overhead query execution
🧠 Predictable SQL generation
🔍 Type-safe query building
🧩 Clean repository integration
🚀 Prepared statement support
📦 Lightweight architecture with minimal abstractions

The goal isn't to be the most feature-rich ORM.

The goal is to stay out of your way.

Built for Real Applications

Whether you're building:

REST APIs
SaaS platforms
Trading systems
Analytics pipelines
Multiplayer game backends
AI services

Your database layer shouldn't become the slowest part of your application.

BreezeORM is designed with production workloads in mind.

Performance Isn't Everything...

...but it matters.

Performance without maintainability becomes technical debt.

Maintainability without performance becomes a scaling problem.

BreezeORM aims for both.

Fast enough for demanding systems.

Simple enough to enjoy using every day.

Go Should Feel Like Go

One of Go's greatest strengths is clarity.

Small interfaces.

Explicit behavior.

Readable code.

BreezeORM follows the same philosophy.

No hidden magic.

No surprising behavior.

Just predictable, efficient data access.

Why Open Source?

Because infrastructure improves when developers challenge assumptions.

Every benchmark.

Every issue.

Every pull request.

Every discussion.

Makes the project stronger.

If you've ever wished your ORM felt a little more "Go"...

golang #go #database #orm #opensource #backend #performance #postgres #mysql

Breeze Framework: Rethinking What a Modern Go Framework Can Be ⚡

Farshad Khazaei Fard — Mon, 13 Jul 2026 09:46:09 +0000

The web has changed.

Applications are no longer simple HTTP servers.
Today we build real-time dashboards, AI-powered services, multiplayer systems, APIs, microservices, and applications that need to handle thousands of connections with minimal overhead.

But our frameworks are still mostly designed for yesterday's problems.

So we asked a simple question:

What if a *Go * framework was built from the ground up for modern workloads?

Meet Breeze.

A high-performance Go framework designed around one idea:

Performance should not come at the cost of developer experience.

Why Breeze?

Go already gives us incredible performance.

But the framework layer often becomes the bottleneck.

Too much abstraction.
Too many allocations.
Too much hidden complexity.

Breeze takes a different approach:

⚡ High-performance networking powered by gnet
🔥 Real-time WebSocket architecture built in
🧩 Modular middleware system
📚 Automatic Swagger/OpenAPI generation
🎨 Built-in SPA template engine
🚀 Optimized worker pool architecture
🗄️ BreezeORM for efficient database operations

Everything you need to build production-grade applications — without assembling dozens of unrelated tools.

The Future Is Real-Time

Modern applications are moving toward instant experiences:

Live collaboration
Trading platforms
AI assistants
Gaming backends
Monitoring systems
Real-time analytics

Breeze is designed for this world.

Instead of adding real-time capabilities later, Breeze treats them as a first-class citizen.

Less Glue Code. More Building.

A common problem in backend development:

You start with a simple API...

Then suddenly you need:

Authentication
Documentation
WebSockets
Background workers
Database optimization
Frontend integration

Your stack becomes a collection of disconnected pieces.

Breeze tries to bring these pieces together into one coherent ecosystem.

Built With Go Philosophy

Go was created around simplicity, performance, and reliability.

Breeze follows the same principles:

Simple APIs.
Predictable behavior.
Low overhead.
Production-focused design.

No magic.
No unnecessary complexity.

Just a fast foundation for building the next generation of applications.

A New Breeze Is Coming 🌪️

Frameworks should not only help us write code faster.

They should help us think bigger.

Breeze is an experiment in what a modern Go framework can become.

The goal is simple:

Make building fast, scalable, real-time applications feel effortless.

Try Breeze. Build something fast.

⭐ GitHub:
https://github.com/nelthaarion/breeze

golang #go #opensource #webdevelopment #backend #performance #framework

I Put an Entire DevOps Stack Inside My Go Framework (And It's Glorious)

Farshad Khazaei Fard — Thu, 09 Jul 2026 07:24:45 +0000

Debugging Go APIs shouldn't require 5 terminal tabs, a Grafana instance, and a prayer.

Let me describe a familiar scenario. You're building an API. A request fails. To figure out why, you:

Check your server logs in Terminal 1.
Open your database GUI to see if the data was written.
Check your Redis client to see if the cache was invalidated.
Open Swagger to verify the payload shape.
Run pprof to see if memory spiked.

That’s five different tools, five different context switches, and about ten minutes lost for a bug that takes thirty seconds to fix.

When I was building Breeze (the gnet-powered Go framework I wrote about recently), I decided to solve this. I didn't want to build a separate monitoring tool—I wanted the framework to know what it was doing.

Enter the Breeze Dashboard: a real-time, single-pane-of-glass observability tool built directly into your Go server.

🖥️ What Is the Breeze Dashboard?

It’s a live web UI that attaches to your Breeze application. It gives you full visibility into your traffic, your database, your routes, and your Go runtime—without writing a single line of monitoring code.

Oh, and it comes with built-in authentication so you don't accidentally expose your server internals to the internet.

Here is what you get the second you turn it on:

1. 🕵️‍♂️ The Developer Timeline (My Favorite Feature)

This is the killer app of the dashboard. Instead of correlating timestamps across logs and databases, the Developer Timeline gives you a linear, chronological view of a request's lifecycle.

You can watch a single HTTP request trigger a specific ORM query, hit the cache, and spawn a background queue job—all in one unified timeline. It turns "guessing" into "seeing."

2. 📡 Live Requests Stream

A real-time, updating feed of every request hitting your server. You see the Method, Path, Status Code, and Latency the millisecond it happens. No grepping logs. No waiting for aggregators. Just instant, raw visibility.

3. 🗄️ Database Browser & ORM Query Monitor

You don't need pgAdmin or DBeaver for local dev anymore.

Database Browser: Inspect your tables, indexes, and data directly in the dashboard UI.
ORM Query Monitor: See the exact SQL queries your application is generating in real-time, how long they take, and which route triggered them. It makes N+1 query problems painfully obvious.

4. 🗺️ Routes Explorer & API Explorer

Routes Explorer: A visual map of every route registered in your router—methods, paths, and attached middleware chains.
API Explorer: Since Breeze has native OpenAPI 3.1 support, the dashboard integrates a full API testing UI. You can ping your endpoints directly from the browser.

5. 🧠 Real-Time Health & Runtime

Deep dive into the Go runtime without pprof web UI:

Active Goroutines
Memory Allocation / GC Pauses
CPU usage
Event loop stats (since it runs on gnet)

6. 📦 Cache & Queue Monitoring

If your app uses caching or background workers, the dashboard gives you a live look into their state. See what keys are hot, what queues are backing up, and clear caches with a click.

7. 📜 Live Logs

A clean, filterable log stream right in your browser. Collapses stack traces by default, expands on click.

🚀 How It Works

Because Breeze controls the entire request lifecycle—from the gnet event loop to the router, to the template engine—it can capture telemetry that external APMs (like DataDog or New Relic) have to work incredibly hard to instrument.

You don't need to add tracing IDs manually. You don't need to wrap your database driver. The framework is the instrument.

Setting it up is conceptually as simple as pointing it at your app and adding an auth check:

// Conceptual setup (requires Breeze latest)
// Enable the dashboard with a secure password
app.EnableDashboard(breeze.DashboardConfig{
    Path:     "/admin/dashboard",
    Password: "your-secure-password", // Never hardcode in prod!
})

app.Run(3000, true)

Navigate to localhost:3000/admin/dashboard, log in, and you're instantly looking at the heartbeat of your application.

🤔 Why Does This Matter?

The "Full-Stack Go" movement is growing. People are tired of spinning up a React frontend, a Postgres instance, a Redis cache, and three separate monitoring tools just to build a simple CRUD app.

Frameworks like Laravel (PHP) and Django (Python) have had robust local tooling for years. Go developers have historically had to build their own DevOps pies from scratch.

The Breeze Dashboard bridges that gap. It gives you the raw, C-level performance of gnet, combined with the developer experience of a modern, batteries-included framework.

🛡️ A Quick Word on Security

Because the dashboard has access to your database, logs, and runtime, it is locked down by default.

It is disabled unless explicitly enabled.
It requires authentication.
In production, you should ideally bind it to an internal port or put it behind an auth proxy.

Try It Out

If you're already using Breeze, update to the latest version and check the docs to enable the Dashboard. If you haven't tried Breeze yet, this is a great reason to take it for a spin.

🔗 Docs & Setup Guide: nelthaarion.github.io/breeze
⭐ GitHub: github.com/nelthaarion/breeze

What's your current local development debugging setup? Are you team docker-compose with 5 containers, or team print statements? Let me know in the comments! 👇

Tags: #go #golang #devops #observability #dashboard #breeze #webdev

🚀 Announcing Breeze: The Go HTTP Framework That Redefines Raw Speed

Farshad Khazaei Fard — Thu, 09 Jul 2026 07:10:02 +0000

630k req/s. Zero allocations. Built-in SPA engine. This is Breeze.

Let me skip the humble intro. I built a Go HTTP framework that benchmarks 3× faster than Fiber on the same hardware, same payload. It's called Breeze, it's built on top of gnet's event loop, and it ships with features that most frameworks make you bolt on yourself.

Here's why I think it's worth your attention.

📊 The Numbers Don't Lie

Simple JSON endpoint. Same machine. Same payload.

Framework	Requests/sec	vs Breeze
Breeze	~630k	1.0×
goFiber	~210k	0.33×
Echo	~140k	0.22×
Gin	~120k	0.19×
net/http	~85k	0.13×

These are approximate numbers from my environment — run the benchmarks yourself for authoritative results.

🔍 How Is This Even Possible?

Breeze isn't another net/http wrapper. It's built on gnet, a non-blocking event-driven networking engine that makes direct epoll/kqueue syscalls. On top of that, I obsessed over every allocation in the hot path:

Stack-allocated router. Path segment matching uses a fixed [16]string array on the stack — no heap allocations. Parameter indexes are pre-computed at route registration, not at match time.

Zero-copy parsing. Raw bytes are converted to strings using unsafe.String — no copying. Header keys are lowercased in-place instead of creating new strings.

Smart worker pool. A fixed goroutine pool with a 16× buffered channel absorbs request bursts. When the queue is full, it spawns a goroutine instead of blocking the event loop. That's the critical difference — the event loop never stalls.

Response serialization without fmt.Sprintf. Status codes are mapped via array index. Buffers are pre-sized. Every nanosecond counts when you're serving 600k+ requests per second.

⚡ Show Me the Code

A complete working server in under 20 lines:

package main

import (
    "runtime"
    "github.com/nelthaarion/breeze"
    middleware "github.com/nelthaarion/breeze/middlewares"
)

func main() {
    router := breeze.NewRouter()
    router.Use(middleware.RecoveryMiddleware())
    router.Use(middleware.LoggingMiddleware())

    router.Handle(breeze.GET, "/", func(ctx *breeze.Context) {
        ctx.JSON(map[string]string{"status": "ok"})
    })

    router.Handle(breeze.GET, "/users/:id", func(ctx *breeze.Context) {
        ctx.JSON(map[string]string{"id": ctx.Param("id")})
    })

    pool := breeze.NewWorkerPool(runtime.NumCPU())
    app  := breeze.New(router, pool)
    app.Run(3000, true) // port, multiCore
}

That's it. One event loop per CPU core, RoundRobin load balancing, TCP_NODELAY enabled by default. No tuning required.

🔌 Native WebSocket — No Goroutine Per Connection

This is the one that makes people do a double-take.

Most Go frameworks spawn a goroutine for every WebSocket connection. Breeze doesn't — the WebSocket handler runs inside the gnet event loop. Zero extra goroutines. Zero per-connection memory overhead.

app := breeze.New(router, pool)
hub := app.WebSocket("/ws", &breeze.WSHandlerFunc{
    Connect: func(conn *breeze.WSConn) {
        conn.SendText("welcome")
    },
    Message: func(conn *breeze.WSConn, opcode byte, payload []byte) {
        hub.BroadcastText(string(payload))
    },
    Close: func(conn *breeze.WSConn, code uint16, reason string) {
        hub.BroadcastText("a user left")
    },
})

The built-in WSHub handles broadcast, room management, and graceful disconnects. RFC 6455 compliant, auto-reconnect on the client side with exponential backoff.

🎨 The Template Engine That Thinks It's an SPA

This is the feature I'm most excited about. Breeze ships a full server-side template engine that automatically turns your multi-page app into a single-page app. No React. No Vue. No build step.

Here's how it works:

1. You write normal server-rendered views with layouts and components:

<!-- views/layout.html -->
{{define "layout"}}
<!DOCTYPE html>
<html>
<body>
    {{component "nav" .}}
    <div id="breeze-app">
        {{template "content" .}}
    </div>
</body>
</html>
{{end}}

<!-- views/home.html -->
{{define "content"}}
<h1>Hello, {{.Data.Name}}!</h1>
{{component "card" (map "title" "Welcome" "body" "Try clicking a link")}}
{{end}}

2. You register routes the simple way:

engine := breeze.NewTemplateEngine(breeze.TemplateConfig{
    ViewsDir:      "views",
    ComponentsDir: "components",
    LayoutFile:    "views/layout.html",
})

router.View("/", engine, "home", func(ctx *breeze.Context) any {
    return map[string]any{"Name": "World"}
})

3. The magic happens automatically. On every full-page render, Breeze injects a JavaScript runtime before </body>. When a user clicks an internal link, the runtime intercepts it, fetches only the content block (via X-Breeze-Partial: true header), and swaps #breeze-app innerHTML. No full page reload. pushState handles the URL. popstate handles back/forward.

Your multi-page app just became a SPA. You didn't write a single line of JavaScript.

But wait — there's more. The template engine also gives you:

Reactive data store — page data is embedded as JSON, accessible via breeze.data(), watchable via breeze.watch()
Client-side re-rendering — breeze.render('card', newData, '#target') re-renders a component without hitting the server (it uses an embedded Go-template subset interpreter)
Fragment routes — router.Fragment('/fragments/stats', engine, "stats", dataFn) serves bare HTML fragments for polling or partial updates
SPA form handling — POST forms are intercepted and submitted via fetch(), response HTML is swapped in. Progressive enhancement means forms still work without JS
Polling built in — breeze.poll('/fragments/stats', '#stats-box', 2000) auto-refreshes a fragment every 2 seconds
Dev mode hot reload — set DevMode: true and template changes are reflected instantly without restarting

🛡️ 9 Middleware, Zero External Dependencies

Everything you need for production, shipped with the framework:

// JWT with access + refresh tokens, role-based auth, custom claims validator
router.Use(middleware.JWTAuthMiddleware(middleware.JWTOptions{
    AccessSecret:  "secret",
    RefreshSecret: "refresh-secret",
    RequiredRoles: []string{"admin"},
}))

// CORS with automatic OPTIONS preflight
router.Use(middleware.CORSMiddleware(middleware.CORSOptions{
    AllowOrigins: "https://myapp.com",
    AllowMethods: "GET,POST,PUT,DELETE,OPTIONS",
}))

// Per-route rate limiting
router.Handle(breeze.POST, "/login", loginHandler,
    middleware.NewRateLimiter(middleware.RateLimiterOptions{
        Requests: 5,
        Per:      time.Minute,
    }),
)

// Auto Brotli → Gzip → Deflate compression
router.Use(middleware.CompressionMiddleware())

// Security headers (CSP, HSTS, X-Frame-Options, etc.)
router.Use(middleware.DefaultSecurityMiddleware())

// Swagger docs from Go struct annotations
router.Use(middleware.SwaggerMiddleware(router, middleware.SwaggerOptions{
    Title: "My API", Version: "1.0.0",
}))

Also included: Logger, Panic Recovery, and ETag Cache.

🆚 How It Compares

	Breeze	Fiber	Gin	Echo
Engine	gnet event loop	fasthttp	net/http	net/http
Hot path allocs	~0	Low	Moderate	Moderate
WebSocket	Native, zero-goroutine	fasthttp-based	gorilla/websocket	gorilla/websocket
Template + SPA	Built-in	Separate	Separate	Separate
Swagger/OpenAPI	Built-in	Third-party	Third-party	Third-party
Middleware	9 built-in	Growing	Largest ecosystem	Good built-in set
net/http compat	No	No	Yes	Yes

Honest take: If you need deep net/http ecosystem compatibility, Gin or Echo are still the safe choices. But if you're starting fresh and want maximum performance with modern features baked in — Breeze is worth a serious look.

📦 Install and Run

go get github.com/nelthaarion/breeze

Requires Go 1.24.3+. Pulls in gnet v2, go-json, brotli, and golang-jwt/jwt.

🔮 What's Next

Real-time Dashboard — live route explorer, request monitor, ORM query monitor (already in progress)
gRPC support — leveraging gnet for high-performance gRPC
More middleware — OAuth2, OpenTelemetry
Template engine enhancements — hot-reload improvements, more built-in functions

Links:

📖 Docs: nelthaarion.github.io/breeze
⭐ GitHub: github.com/nelthaarion/breeze

I built Breeze because I was tired of choosing between speed and features. If that resonates with you, try it out and let me know what you think. I'm active on GitHub issues and open to contributions.

What's your current Go framework of choice, and what would make you switch? Let's talk in the comments. 👇

Tags: #go #golang #webframework #performance #breeze #open_source

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

Farshad Khazaei Fard — Sat, 27 Jun 2026 00:49:42 +0000

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