Göktay Logo

2026'da Her Backend Mühendisinin Bilmesi Gereken Go Kütüphaneleri

5 dk okuma

Go’nun en sevdiğim yanlarından biri, backend ekosistemindeki en güçlü standart kütüphanelerden birine sahip olması. Bu konuyu Go Standart Kütüphanesi yazımda uzun uzun anlatmıştım. Ama gerçek production sistemleri — API’ler, mikroservisler, dağıtık sistemler, CLI’lar, arka plan işçileri — kurmaya başladığınızda, standart kütüphanenin her zaman yetmediğini hızla fark edersiniz.

Asıl zorluk kütüphane bulmak değil; hangilerinin gerçekten öğrenmeye değer olduğunu bilmek. Aşağıda, yıllar içinde neredeyse her ciddi Go projesinde karşıma çıkan, benim de bir backend mühendisinin cephaneliğinde olması gerektiğine inandığım kütüphaneleri kategorilere ayırdım.

HTTP ve Routing

chi — Standart Kütüphaneye Sadık Router

net/http felsefesine yakın, hafif ve birleştirilebilir (composable) bir router istiyorsanız ilk önerim chi olur. Framework mimarisini size dayatmaz; küçük bileşenleri kompozisyonla birleştirir.

r := chi.NewRouter()
r.Use(middleware.Logger)
r.Use(middleware.Recoverer)
r.Route("/users/{id}", func(r chi.Router) {
    r.Get("/", getUser)
    r.Put("/", updateUser)
    r.Delete("/", deleteUser)
})

Minimal soyutlama, mükemmel net/http uyumu ve kolay test edilebilirlik. Laravel gibi full-stack bir framework’ten geliyorsanız chi, Go’nun “tek dev framework yerine küçük parçalar + kompozisyon” yaklaşımının güzel bir örneğidir.

gin — Hızlıca API Kurmak

Bazen her şeyi kendiniz kurmak istemez, sadece hızlıca bir API yazmak istersiniz. İşte orada gin devreye girer: routing, middleware, JSON binding, validation ve hata yönetimi kutudan gelir. Gin’i sıfırdan, HTTP temellerinden production’a kadar ayrı bir Golang Gin Rehberi yazısında ele aldım — merak edenler oradan derinlemesine bakabilir.

Production Notu: chi mi gin mi? Kural basit: net/http’ye yakın kalıp middleware’i kompozisyonla kurmak istiyorsanız chi; “hızlıca, batteries-included bir API” istiyorsanız gin. İkisi de sağlamdır; yanlış seçim yoktur, yalnızca önceliğinize göre doğru seçim vardır.

Veritabanı

pgx — Go için PostgreSQL

Ciddi bir backend kuruyorsanız, muhtemelen PostgreSQL kullanacaksınız. Ve Go ile PostgreSQL kullanıyorsanız, pgx bilmeniz gereken en önemli kütüphanelerden biridir. Veritabanını ağır bir soyutlamanın arkasına saklamadan doğrudan erişim verir:

pool, err := pgxpool.New(context.Background(), os.Getenv("DATABASE_URL"))
if err != nil {
    log.Fatal(err)
}
var name string
err = pool.QueryRow(context.Background(),
    "SELECT name FROM users WHERE id=$1", userID,
).Scan(&name)

Connection pooling, transaction’lar, prepared statement’lar, PostgreSQL’e özgü tipler, COPY ve LISTEN/NOTIFY… hepsi elinizin altında.

Tavsiyem: Go backend geliştirmede ciddiyseniz, doğrudan bir ORM’e atlamadan önce SQL + pgx öğrenin. Uygulamanızın altındaki veritabanını anlamak, herhangi bir ORM’in sağlayacağından çok daha değerlidir.

sqlc — Tip Güvenli SQL

Ekosistemdeki en sevdiğim araçlardan biri sqlc. Elle Scan çağrıları yazmak yerine SQL yazarsınız:

-- name: GetUser :one
SELECT id, name, email FROM users WHERE id = $1;

sqlc, bundan tip güvenli Go kodu üretir. SQL esnekliğinden ödün vermeden statik tip güvenliği elde edersiniz — ikisinin en iyisi.

Mühendislik Notu: SQL şemanızdan Go modelleri ve struct’lar üretmenin mantığını sevdiyseniz, aynı işi tarayıcıda hızlıca yapan SQL to GORM Model Converter ve JSON → Schema & Struct Üretici araçlarımı da kullanabilirsiniz. Repository katmanını bu modellerin üstüne nasıl kurduğumu ise repository pattern yazımda anlattım.

golang-migrate — Veritabanı Migration’ları

Şemanızı ileri (ve geri) taşımanın güvenilir bir yoluna ihtiyacınız var. golang-migrate, ekosistemin en yaygın migration araçlarından biri; şema değişikliklerini kodunuzla birlikte sürüm kontrolünde tutar:

migrations/
├── 000001_create_users.up.sql
├── 000001_create_users.down.sql
├── 000002_create_orders.up.sql
└── 000002_create_orders.down.sql

Altyapı: Cache ve Loglama

go-redis — Redis

Redis modern backend’lerde her yerdedir: cache, dağıtık kilit (distributed lock), rate limit, oturum, kuyruk, sayaç, geçici durum. Go için go-redis cephaneliğinizde olmalı:

err := client.Set(ctx, "user:123", userJSON, time.Hour).Err()
value, err := client.Get(ctx, "user:123").Result()

Ama sadece kütüphaneyi değil, Redis’in kendisini öğrenin: TTL, eviction, pipeline, pub/sub, stream’ler ve dağıtık kilitler. Aracı bilmek yeterli değil; altındaki mekaniği anlamak sizi güçlü kılar.

zap — Yapılandırılmış Loglama

Loglama, uygulamayı deploy ettikten sonra düşünülecek bir şey değil, mimarinizin bir parçası olmalı. Uber’in zap kütüphanesi, yüksek performanslı ve yapılandırılmış (structured) bir logger’dır:

logger, _ := zap.NewProduction()
defer logger.Sync()
logger.Info("kullanıcı oluşturuldu",
    zap.Int64("user_id", user.ID),
    zap.String("email", user.Email),
)

"User 123 created" gibi düz metin yerine, log platformlarının kolayca işleyebileceği yapılandırılmış veri elde edersiniz.

Production Notu: Go 1.21 ile gelen standart log/slog paketi, yapılandırılmış loglamayı artık kutudan sunuyor (bunu standart kütüphane yazımda ele almıştım). Yeni bir projeye başlıyorsanız önce slog’u deneyin; zap’ı ancak onun sunduğunun ötesinde ekstra performans veya özellik gerçekten gerektiğinde ekleyin.

API Yardımcıları

go-playground/validator — Doğrulama

Girdi doğrulama, her API’nin eninde sonunda ihtiyaç duyduğu şeydir. validator, struct etiketleriyle bildirimsel doğrulama sağlar:

type CreateUserRequest struct {
    Name  string `validate:"required,min=3"`
    Email string `validate:"required,email"`
}

Bu kütüphaneyi zaten dolaylı olarak kullanıyor olabilirsiniz: Gin’in binding etiketleri arka planda tam da bunu çalıştırır. DTO tarzı istek struct’larıyla çok iyi çalışır.

Araçlar: CLI ve Konfigürasyon

cobra — Güçlü CLI Uygulamaları

Geliştirici araçları veya komut satırı uygulamaları yazıyorsanız cobra öğrenin. Pek çok popüler Go projesinin (kubectl, hugo…) temelidir ve hiyerarşik komutlar kurmanızı sağlar:

myapp
├── server
├── migrate
└── user
    ├── create
    ├── delete
    └── list

viper — Konfigürasyon Yönetimi

viper, ortam değişkenleri, konfigürasyon dosyaları ve flag’leri farklı ortamlar için yönetmenin popüler bir yoludur. Ama bir uyarı: hemen viper’a koşmayın. Basit uygulamalar için os.Getenv() artı küçük bir konfigürasyon struct’ı çoğu zaman yeterlidir. Karmaşıklık, yerini hak etmelidir.

Bir Uyarı: Her Şey İçin Kütüphane Şart Değil

Bu listeyi bir “hepsini hemen ekle” davetiyesi olarak okumayın. Her eklediğiniz bağımlılık, gelecekte güncellenecek, güvenlik açıkları takip edilecek ve bir gün kırılabilecek bir bakım borcudur. Aşırı mühendislik yazımda savunduğum ilke burada da geçerli: bir kütüphaneyi eklemeden önce sorun — “Bunu standart kütüphaneyle yapabilir miyim? Bu bağımlılığın kazandırdığı zaman, taşıyacağı maliyete değer mi?”

İşte bu yüzden viper yerine bazen os.Getenv, zap yerine bazen slog, bir ORM yerine bazen pgx doğru cevaptır. Kod üretimi (code generation) ihtiyacı doğduğunda ise, harici bir jeneratör kurmadan önce JSON → Schema & Struct Üretici ve Golang Struct Generator gibi hazır araçlarla tekrar eden struct’ları saniyeler içinde üretebilirsiniz.

Sonuç

Go ekosistemi olgunlaştı; neredeyse her yaygın backend problemi için sağlam bir kütüphane var. Ama iyi bir mühendis, kütüphane listesi ezberleyen değil, hangi problemi hangi araçla çözeceğini bilen kişidir. Bu listedeki her kütüphaneyi öğrenin — ama her birini, çözdüğü problemi gerçekten yaşadığınızda ekleyin.

Kısacası: önce standart kütüphaneyi tanıyın, sonra bu kütüphaneleri ihtiyaç doğdukça cephaneliğinize katın. Aracın kendisini değil, altındaki problemi anladığınızda, hangi kütüphaneyi seçtiğiniz ikincil bir detaya dönüşür.