DEV Community

Farshad Khazaei Fard
Farshad Khazaei Fard

Posted on

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

#go #devops #breeze

**

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:

  1. Check your server logs in Terminal 1.
  2. Open your database GUI to see if the data was written.
  3. Check your Redis client to see if the cache was invalidated.
  4. Open Swagger to verify the payload shape.
  5. 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)
Enter fullscreen mode Exit fullscreen mode

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

Top comments (0)