```html
{{ range .Tips }}
{{ .Description }}
`golang.org/x/sync/singleflight` solves this elegantly. When multiple requests call the same key at the same time, singleflight executes the function once and shares the result with all callers.
```go
import "golang.org/x/sync/singleflight"
var group singleflight.Group
func getUser(id string) (*User, error) {
v, err, _ := group.Do("user:"+id, func() (interface{}, error) {
return db.FetchUser(id) // called once, no matter how many waiters
})
return v.(*User), err
}
```
The difference is significant: without singleflight you make N expensive calls, with it you make one and share the result. It's also faster in aggregate since all waiters get the response as soon as the first call finishes.
One gotcha: errors are shared too. If the underlying call fails, all waiters get that same error. Make sure you're not accidentally caching failures downstream.
---
## Tip 4: Middleware
Go's `http.Handler` interface makes middleware composable without any magic — it's just a function that wraps another function. You can chain as many as you need.
Chi already gives you a set of useful middlewares, and you should use them. But it's also worth writing your own at least once — it's around ten lines and demystifies exactly how the chain works.
A common and practical example is authentication middleware:
```go
func authMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
username, password, ok := r.BasicAuth()
if !ok || !isValid(username, password) {
w.Header().Set("WWW-Authenticate", `Basic realm="restricted"`)
http.Error(w, "Unauthorized", http.StatusUnauthorized)
return
}
next.ServeHTTP(w, r)
})
}
```
If the auth check passes, it calls `next.ServeHTTP` and the chain continues. If it fails, it returns early — the next handler never runs.
One caution: don't use middleware to pass arbitrary data between layers. It obfuscates the flow of data in your application. Use `context.WithValue` sparingly, and only for things like request IDs or the authenticated user — not general application state.
---
## Tip 5: Dependency injection with fx
As your application grows, you accumulate dependencies: a database connection, a cache, a config struct, multiple services, multiple handlers. Wiring all of these by hand in `main.go` becomes a sprawling mess — and changing one constructor signature means updating it in ten places.
[uber-go/fx](https://github.com/uber-go/fx) solves this cleanly. You register constructors with `fx.Provide`, and fx builds the dependency graph automatically. Each constructor declares what it needs as parameters, and fx figures out the wiring.
```go
func main() {
fx.New(
fx.Provide(
config.Load, // Config
database.New, // *sql.DB ← needs Config
NewTipsService, // TipsService ← needs *sql.DB
NewHomeHandler, // Handler ← needs TipsService
NewRouter, // chi.Router ← needs Handler
),
fx.Invoke(StartServer), // ← needs chi.Router + Config
).Run()
}
```
fx also has lifecycle hooks, which integrate cleanly with graceful shutdown:
```go
func StartServer(lc fx.Lifecycle, r *chi.Mux, cfg config.Config) {
srv := &http.Server{Addr: ":" + cfg.Port, Handler: r}
lc.Append(fx.Hook{
OnStart: func(ctx context.Context) error {
go srv.ListenAndServe()
return nil
},
OnStop: func(ctx context.Context) error {
return srv.Shutdown(ctx)
},
})
}
```
The result is a `main.go` that reads like a declaration of what the app needs, not a manual wiring diagram. As you add more handlers, services, and dependencies, the structure stays clean.
One honest trade-off: fx uses reflection under the hood, which can make stack traces harder to read. It's worth the trade-off once you have more than three or four layers. If you prefer compile-time guarantees, [google/wire](https://github.com/google/wire) is the alternative.
---
## Tip 6: Hot reloads with Air
During development, you should not be manually stopping and restarting your server every time you change a file. [Air](https://github.com/air-verse/air) handles this for Go.
You tell Air which files and directories to watch, and it automatically rebuilds and restarts the app when it detects a change. Go files, HTML templates, static assets — whatever matters to you.
Install it and add an `.air.toml` to your project:
```toml
[build]
cmd = "go build -o ./tmp/main ."
bin = "./tmp/main"
include_ext = ["go", "html"]
exclude_dir = ["tmp", "vendor"]
```
Then run `air` instead of `go run`:
```bash
air
```
One thing to pair with this: if you're caching templates at startup (which you should be in production), add an environment variable to switch between disk reads and embedded files. In development, read from disk so Air picks up template changes without a restart.
```go
var tmpl *template.Template
func init() {
if os.Getenv("ENV") == "dev" {
tmpl = template.Must(template.ParseGlob("templates/*.html"))
} else {
tmpl = template.Must(template.ParseFS(embeddedFiles, "templates/*.html"))
}
}
```
The combination of Air and disk-based template reads gives you instant feedback on both Go code changes and template changes — which is exactly what you want when iterating quickly.
---
## nuzur
If you're building a Go web app and want to skip the schema boilerplate entirely, check out [nuzur](https://nuzur.com). You design your data model visually — tables, columns, relationships — and nuzur can generate Go structs, protobuf definitions, repository interfaces and more directly from it. No manual SQL migrations, no copy-pasting schema definitions.
The [MCP connector](https://nuzur.com/blog/nuzur-claude-mcp) also lets your AI assistant query your live schema while you code, so it actually knows your model when you're asking it questions.
---
## Recap
1. **Use chi** — lightweight, idiomatic, great middleware grouping
2. **Use Go templates** — parse once at startup, use `embed.FS` in production
3. **Use singleflight** — prevent thundering herd on cache misses
4. **Write middleware** — composable, explicit, keep `context.WithValue` minimal
5. **Use fx for dependency injection** — clean wiring, built-in lifecycle hooks
6. **Use Air for hot reloads** — never restart your server manually again
Go's simplicity is the feature. These patterns keep that simplicity intact as your app grows.