Many Go developers reach for frameworks out of habit, but the standard library — net/http, encoding/json, database/sql — is capable enough for most production services. Fewer dependencies mean fewer surprises.
Frameworks in Go are thin compared to other ecosystems anyway; most of them wrap the standard library rather than replace it.
Build an API with stdlib only
The net/http package provides routing, middleware and server management out of the box.
- http.ServeMux for routing, with method patterns.
- encoding/json for requests and responses.
- Middleware via a simple wrapping handler function.
- http.Server with timeouts for production behavior.
Start with the standard library. Add a framework only when you hit a concrete pain: complex routing, code generation, or team conventions that demand it.
When a framework still makes sense
Larger teams may want the conventions that frameworks enforce, and specialized needs — WebSockets, gRPC, OpenAPI generation — have first-class libraries anyway. The point is to choose deliberately, not by default.
The practical stack
For most backends: stdlib net/http, a SQL driver with database/sql, and a small validation helper. That is a production stack with a dependency count you can audit by hand.
package main
import (
"encoding/json"
"net/http"
)
type Note struct {
ID int `json:"id"`
Text string `json:"text"`
}
func getNote(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json")
json.NewEncoder(w).Encode(Note{ID: 1, Text: "Hello"})
}
func main() {
mux := http.NewServeMux()
mux.HandleFunc("GET /notes/{id}", getNote)
http.ListenAndServe(":8080", mux)
}Go stdlib FAQ
Is the standard library production-ready?
Yes. The net/http server powers many high-traffic services. The important part is configuring timeouts and middleware yourself, since the defaults are intentionally conservative.
What about routing with path parameters?
Go 1.22+ ServeMux supports method and wildcard patterns natively, removing the main reason teams reached for routers.
