Blog

Di Belajar Golang dari Nol #22 kita keluar rumah sebentar. Kita belajar memanggil API pihak ketiga dengan HTTP client. Sekarang kita pulang lagi ke database. Ada dua pekerjaan rumah yang belum selesai sejak bagian 12. Dua-duanya baru terasa sakit saat aplikasi kamu benar-benar dipakai orang. Kalau kamu baru bergabung di tengah seri, cek dulu daftar lengkap seri supaya tidak ada yang terlewat.

Dua Masalah yang Belum Kita Jawab

Di bagian 12 kita sudah bisa insert, update, dan query lewat database/sql. Di bagian 16 kita rapikan dengan repository pattern. Cukup untuk latihan. Belum cukup untuk production. Ada dua lubang besar.

Masalah pertama: operasi berangkai yang harus semua-atau-tidak-sama-sekali. Contoh paling klasik ada di aplikasi toko. Saat ada order masuk, kamu harus memotong stok produk dan mencatat order baru. Dua query berbeda. Kalau query pertama sukses lalu query kedua gagal, datamu rusak. Stok sudah berkurang, tapi ordernya tidak ada.

Masalah kedua: mengubah struktur tabel di database yang sudah berisi data. Di bagian 12 kita membuat tabel lewat CREATE TABLE IF NOT EXISTS di kode Go. Itu jalan sekali, lalu diam selamanya. Begitu aplikasi live dan kamu butuh kolom baru, cara itu tidak menolong sama sekali. Kamu tidak mungkin drop tabel yang isinya data pelanggan.

Jawaban untuk masalah pertama adalah transaksi. Jawaban untuk masalah kedua adalah migrasi skema. Kita bahas satu per satu.

Kenapa Transaksi Itu Penting

Cerita nyata dulu. Bayangkan API toko online kamu menerima order. Kodenya menjalankan dua langkah: potong stok, lalu insert order. Suatu malam, koneksi database putus sepersekian detik. Tepat di antara dua langkah itu. Stok kaos sudah terpotong satu. Order gagal tercatat. Pembeli tidak dapat apa-apa, tapi stok di sistem berkurang.

Kejadian seperti ini tidak muncul di laptop kamu saat development. Ia muncul di production, jam dua pagi, saat traffic sedang ramai. Selisihnya kecil, satu dua unit. Tapi menumpuk. Akhir bulan tim gudang bingung. Stok di sistem bilang habis, stok fisik masih ada. Ini yang biasa disebut stok bocor.

Transaksi menutup lubang ini. Konsepnya sederhana. Kamu membungkus beberapa query jadi satu paket. Paket itu hanya punya dua kemungkinan akhir. Semua query berhasil dan disimpan permanen, itu namanya commit. Atau salah satu gagal dan semuanya dibatalkan seolah tidak pernah terjadi, itu namanya rollback. Tidak ada kondisi setengah jadi.

Anatomi Transaksi di Go

Di database/sql, transaksi dimulai dengan db.BeginTx. Fungsi ini menerima context, jadi ilmu dari bagian 17 langsung terpakai. Kalau request dibatalkan atau timeout, transaksinya ikut dibatalkan. Setelah itu semua query dijalankan lewat objek tx, bukan db.

tx, err := db.BeginTx(ctx, nil)
if err != nil {
    return err
}
defer tx.Rollback()

// jalankan query lewat tx, bukan db
_, err = tx.ExecContext(ctx, "UPDATE produk SET stok = stok - 1 WHERE id = ?", 1)
if err != nil {
    return err
}

return tx.Commit()

Perhatikan baris defer tx.Rollback(). Ini pola paling penting di sini. Ditulis sekali, tepat setelah BeginTx berhasil. Logikanya begini. Kalau ada error di tengah dan fungsi return lebih awal, defer memastikan rollback tetap jalan. Transaksi tidak menggantung dan mengunci baris di database.

Lalu bagaimana kalau semuanya sukses sampai Commit? Bukankah defer tetap memanggil Rollback setelahnya? Benar, tetap dipanggil. Tapi tidak berbahaya. Transaksi yang sudah di-commit statusnya sudah selesai. Rollback setelah commit hanya mengembalikan error sql.ErrTxDone dan tidak melakukan apa-apa ke database. Karena kita tidak memeriksa nilai baliknya, error itu lewat begitu saja. Satu baris defer, dua skenario aman.

Contoh Utuh: BuatOrder dalam Satu Transaksi

Sekarang kita gabungkan jadi method repository yang layak production. Method ini memotong stok dan mencatat order dalam satu transaksi. Kalau stok kurang, semuanya batal.

var ErrStokKurang = errors.New("stok tidak mencukupi")

type OrderRepository struct {
    db *sql.DB
}

func (r *OrderRepository) BuatOrder(ctx context.Context, produkID int64, jumlah int) (int64, error) {
    tx, err := r.db.BeginTx(ctx, nil)
    if err != nil {
        return 0, fmt.Errorf("mulai transaksi: %w", err)
    }
    defer tx.Rollback()

    // langkah 1: potong stok, hanya kalau stok cukup
    res, err := tx.ExecContext(ctx,
        "UPDATE produk SET stok = stok - ? WHERE id = ? AND stok >= ?",
        jumlah, produkID, jumlah,
    )
    if err != nil {
        return 0, fmt.Errorf("potong stok: %w", err)
    }

    baris, err := res.RowsAffected()
    if err != nil {
        return 0, err
    }
    if baris == 0 {
        // tidak ada baris berubah, artinya stok kurang.
        // return di sini memicu defer tx.Rollback()
        return 0, ErrStokKurang
    }

    // langkah 2: catat order
    hasil, err := tx.ExecContext(ctx,
        "INSERT INTO orders (produk_id, jumlah, status) VALUES (?, ?, 'baru')",
        produkID, jumlah,
    )
    if err != nil {
        return 0, fmt.Errorf("simpan order: %w", err)
    }

    orderID, err := hasil.LastInsertId()
    if err != nil {
        return 0, err
    }

    if err := tx.Commit(); err != nil {
        return 0, fmt.Errorf("commit: %w", err)
    }

    return orderID, nil
}

Ikuti alur gagalnya. Misal stok tinggal 2 dan pembeli minta 5. Query update tidak menemukan baris yang cocok karena syarat stok >= 5 tidak terpenuhi. RowsAffected mengembalikan 0. Fungsi return dengan ErrStokKurang. Defer menjalankan rollback. Insert order tidak pernah terjadi, dan stok tidak tersentuh. Database kembali bersih, seolah request itu tidak pernah datang.

Dua Pembeli, Satu Barang Terakhir

Ada satu jebakan lagi yang perlu kamu tahu, walau kita bahas ringan saja. Bayangkan stok tinggal satu, lalu dua request masuk bersamaan. Kalau kodemu bergaya cek dulu baru update, dua-duanya bisa lolos. Request A membaca stok, dapat 1. Sebelum A sempat update, request B juga membaca stok, dapat 1 juga. Keduanya merasa berhak. Keduanya memotong stok. Hasil akhir stok jadi minus satu, dan dua orang membeli barang yang cuma ada satu.

Masalah semacam ini disebut race condition di level database, dan topik isolasi transaksi bisa jadi satu artikel sendiri. Untungnya, untuk kasus stok ada solusi praktis yang sudah kamu lihat di kode tadi. Jangan pisahkan cek dan update. Gabungkan keduanya dalam satu query atomik:

UPDATE produk SET stok = stok - ? WHERE id = ? AND stok >= ?

Database menjamin satu statement UPDATE dieksekusi utuh, satu per satu terhadap baris yang sama. Request pertama yang sampai akan memotong stok. Request kedua menemukan syarat stok >= ? sudah tidak terpenuhi, sehingga RowsAffected bernilai 0 dan order ditolak rapi. RowsAffected sendiri sudah kamu kenal sejak bagian 12. Sekarang dia naik pangkat, dari sekadar info jadi penjaga gerbang.

Masalah Kedua: Skema yang Ikut Bertumbuh

Aplikasi yang hidup pasti berubah. Bulan ini tabel produk cukup dengan nama, harga, dan stok. Bulan depan tim minta kolom foto. Di sinilah pendekatan bagian 12 mentok. CREATE TABLE IF NOT EXISTS hanya bekerja saat tabel belum ada. Kalau tabel sudah ada, statement itu diam saja. Dia tidak bisa menambah kolom, tidak bisa mengubah tipe data, tidak bisa apa-apa.

Solusi naifnya mengerikan: drop tabel lalu buat ulang. Di development mungkin tidak apa-apa. Di production itu artinya menghapus seluruh data pelanggan. Jelas bukan pilihan.

Solusi yang dipakai industri adalah migrasi skema. Idenya begini. Setiap perubahan struktur database ditulis sebagai file SQL bernomor urut. File pertama membuat tabel. File kedua menambah kolom. File ketiga menambah index. Dan seterusnya. Setiap perubahan punya pasangan: file up untuk menerapkan perubahan, dan file down untuk membatalkannya. Database mencatat sudah sampai nomor berapa dia bermigrasi. Jadi database lama dan database baru bisa dibawa ke struktur yang sama, cukup dengan menjalankan migrasi yang belum dieksekusi.

Praktik dengan golang-migrate

Tool paling populer di ekosistem Go untuk urusan ini adalah golang-migrate. Kita pakai versi CLI-nya. Install dulu:

go install -tags 'mysql' github.com/golang-migrate/migrate/v4/cmd/migrate@latest

Lalu buat folder migrasi dan file pertamanya:

mkdir -p db/migrations
migrate create -ext sql -dir db/migrations -seq buat_tabel_produk

Perintah itu menghasilkan dua file kosong dengan format nama yang penting kamu pahami: 000001_buat_tabel_produk.up.sql dan 000001_buat_tabel_produk.down.sql. Angka di depan adalah urutan eksekusi. Isi file up dengan struktur tabel kita:

-- 000001_buat_tabel_produk.up.sql
CREATE TABLE produk (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    nama VARCHAR(100) NOT NULL,
    harga INT NOT NULL,
    stok INT NOT NULL DEFAULT 0
);

CREATE TABLE orders (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    produk_id BIGINT NOT NULL,
    jumlah INT NOT NULL,
    status VARCHAR(20) NOT NULL,
    dibuat_pada TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (produk_id) REFERENCES produk(id)
);

File down berisi kebalikannya. Urutannya dibalik karena orders bergantung pada produk:

-- 000001_buat_tabel_produk.down.sql
DROP TABLE orders;
DROP TABLE produk;

Jalankan migrasinya:

migrate -path db/migrations \
  -database "mysql://user:rahasia@tcp(localhost:3306)/toko" up

Kalau kamu intip databasenya sekarang, ada satu tabel tambahan bernama schema_migrations. Tabel ini milik golang-migrate. Isinya nomor versi terakhir yang sudah diterapkan. Berkat tabel ini, menjalankan migrate up dua kali aman. Migrasi yang sudah jalan tidak diulang.

Sekarang skenario kolom baru. Di bagian 20 kita belajar upload file, dan produk kita butuh kolom untuk menyimpan nama file fotonya. Jangan sentuh file 000001. Buat migrasi kedua:

migrate create -ext sql -dir db/migrations -seq tambah_kolom_foto

-- 000002_tambah_kolom_foto.up.sql
ALTER TABLE produk ADD COLUMN foto VARCHAR(255) NULL;

-- 000002_tambah_kolom_foto.down.sql
ALTER TABLE produk DROP COLUMN foto;

Jalankan migrate up lagi. Golang-migrate melihat database sudah di versi 1, jadi hanya file 000002 yang dieksekusi. Data produk lama tetap utuh, hanya bertambah satu kolom kosong. Kalau ternyata ada masalah, migrate down 1 mengembalikan satu langkah ke belakang lewat file down.

Aturan Emas Migrasi di Production

Tiga aturan ini pendek, tapi menyelamatkan banyak database.

• Jangan pernah edit migrasi lama yang sudah jalan. File migrasi yang sudah diterapkan itu sejarah. Kalau butuh perubahan, selalu bikin file migrasi baru. Mengedit file lama membuat database yang sudah bermigrasi dan yang belum jadi punya struktur berbeda, dan itu sulit sekali dilacak.
• Backup dulu sebelum migrate di production. File down membantu, tapi ada perubahan yang tidak bisa dibalik. DROP COLUMN yang sudah jalan tidak bisa mengembalikan isi kolomnya. Rutinitas mysqldump yang kita bahas di bagian 15 adalah jaring pengamanmu di sini.
• Jalankan migrasi sebagai bagian dari deploy. Urutannya: backup, migrate up, baru jalankan versi aplikasi terbaru. Dengan begitu kode baru tidak pernah bertemu skema lama.

Latihan: Rangkai Semuanya

Waktunya latihan utuh. Susun project kecil dengan struktur ini: dua file migrasi seperti di atas di folder db/migrations, lalu OrderRepository dengan method BuatOrder yang sudah kita tulis. Sambungkan ke handler HTTP sederhana:

func (h *OrderHandler) Buat(w http.ResponseWriter, r *http.Request) {
    var req struct {
        ProdukID int64 `json:"produk_id"`
        Jumlah   int   `json:"jumlah"`
    }
    if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
        http.Error(w, "body tidak valid", http.StatusBadRequest)
        return
    }

    orderID, err := h.repo.BuatOrder(r.Context(), req.ProdukID, req.Jumlah)
    if errors.Is(err, ErrStokKurang) {
        http.Error(w, "stok tidak mencukupi", http.StatusConflict)
        return
    }
    if err != nil {
        http.Error(w, "terjadi kesalahan server", http.StatusInternalServerError)
        return
    }

    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(map[string]int64{"order_id": orderID})
}

Lalu uji alurnya dengan curl. Pertama, jalankan migrasi dan isi satu produk dengan stok 3. Kemudian coba order yang melebihi stok:

curl -X POST http://localhost:8080/orders \
  -H "Content-Type: application/json" \
  -d '{"produk_id": 1, "jumlah": 10}'

Kamu akan menerima status 409 dengan pesan stok tidak mencukupi. Sekarang cek stoknya lewat endpoint produk atau langsung di database. Stok masih 3, tidak tersentuh sama sekali. Itu bukti rollback bekerja. Terakhir, order dengan jumlah 2. Order tercatat, stok jadi 1, dan keduanya berubah bersama dalam satu transaksi. Coba juga tembak dua request bersamaan saat stok tinggal satu, dan lihat sendiri hanya satu yang berhasil.

Penutup

Hari ini kamu menutup dua lubang production yang paling sering menggigit pemula. Transaksi memastikan operasi berangkai selesai utuh atau batal total, dengan pola BeginTx, defer tx.Rollback(), dan Commit. Migrasi skema membuat struktur database bisa bertumbuh bersama aplikasimu tanpa mengorbankan data, dengan file up dan down yang berurutan dan tercatat rapi di schema_migrations.

Di bagian 24 kita naik satu level lagi soal performa. Judulnya “Caching dengan Redis: Bikin API Terasa Instan”. Sampai ketemu di sana.

Kalau kamu sedang membangun aplikasi yang datanya tidak boleh bocor, misalnya sistem inventaris atau POS dengan stok yang harus akurat, tim kami terbiasa menangani kasus seperti ini. Lihat layanan pengembangan sistem aplikasi Arrazy untuk cerita lengkapnya.

Di Belajar Golang dari Nol #21 kita belajar mengirim email dari aplikasi Go, lengkap dengan retry saat SMTP bermasalah. Sekarang arah pandangnya kita balik. Sejak bagian 11 aplikasi kita selalu jadi server, pihak yang dipanggil. Kali ini kita jadi pihak yang memanggil. Aplikasi kita akan bertamu ke API milik orang lain. Kalau kamu baru bergabung di seri ini, mampir dulu ke daftar lengkap seri supaya urutannya jelas.

Kenapa aplikasimu hampir pasti butuh HTTP client

Hampir tidak ada aplikasi bisnis yang hidup sendirian. Toko online perlu cek ongkir ke API kurir sebelum checkout. Sistem kasir perlu memotong pembayaran lewat payment gateway seperti Midtrans atau Xendit. Aplikasi PPDB perlu kirim notifikasi lewat WhatsApp gateway. Dashboard keuangan perlu ambil kurs dollar hari ini.

Semua kebutuhan itu jalannya sama: aplikasimu mengirim HTTP request ke server orang lain, lalu membaca balasannya. Alatnya sudah ada di paket net/http yang kita pakai sejak membangun REST API. Bedanya, sekarang kita memakai sisi client-nya.

Jangan pakai http.Get polos di production

Cara tercepat memanggil API memang satu baris:

resp, err := http.Get("https://api.contoh.com/data")

Kode ini jalan, dan justru itu bahayanya. http.Get memakai http.DefaultClient, dan DefaultClient tidak punya timeout sama sekali. Kalau server tujuan lambat atau koneksinya menggantung, request-mu ikut menggantung. Bukan sebentar. Selamanya.

Di bagian 17 kita sudah bahas kenapa timeout itu nyawa. Setiap request yang menggantung menahan satu goroutine, satu koneksi, dan kadang satu user yang menunggu di depan layar. Kalau API pihak ketiga sedang down dan kamu tidak pasang timeout, antrean request menumpuk sampai aplikasimu ikut tumbang. Padahal yang rusak bukan aplikasimu.

Solusinya sederhana: buat http.Client sendiri dengan timeout eksplisit, lalu pakai ulang di seluruh aplikasi.

var httpClient = &http.Client{
	Timeout: 10 * time.Second,
}

Satu client ini aman dipakai dari banyak goroutine sekaligus. Jangan membuat client baru tiap request, karena client menyimpan pool koneksi yang bisa dipakai ulang.

GET yang benar: context, Body.Close, cek status

Begini pola lengkap request GET yang layak masuk production:

func ambilTodo(ctx context.Context) ([]byte, error) {
	ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
	defer cancel()

	req, err := http.NewRequestWithContext(ctx, http.MethodGet,
		"https://jsonplaceholder.typicode.com/todos/1", nil)
	if err != nil {
		return nil, err
	}

	resp, err := httpClient.Do(req)
	if err != nil {
		return nil, fmt.Errorf("request gagal: %w", err)
	}
	defer resp.Body.Close()

	if resp.StatusCode != http.StatusOK {
		return nil, fmt.Errorf("status tidak terduga: %d", resp.StatusCode)
	}

	return io.ReadAll(resp.Body)
}

Ada tiga kebiasaan penting di sini.

Pertama, http.NewRequestWithContext. Request ini membawa context, jadi kalau user membatalkan halaman atau deadline lewat, request ke pihak ketiga ikut dibatalkan. Ini sambungan langsung dari materi context di bagian 17.

Kedua, defer resp.Body.Close(). Ini wajib, bukan hiasan. Selama body belum ditutup, koneksi TCP di baliknya tidak bisa dikembalikan ke pool. Lupa menutup body di satu fungsi yang dipanggil ribuan kali berarti ribuan koneksi bocor. Gejalanya pelan: aplikasi makin lama makin berat, file descriptor habis, lalu error aneh muncul di jam sibuk. Tulis defer resp.Body.Close() tepat setelah cek error, sebelum kode lain.

Ketiga, cek resp.StatusCode sebelum parse. Server yang membalas error 500 sering mengirim halaman HTML, bukan JSON. Kalau kamu langsung decode tanpa cek status, error yang muncul adalah “invalid character” yang membingungkan, padahal masalah aslinya server sedang rusak.

Decode JSON respons ke struct

Untuk latihan, pakai API publik yang stabil seperti jsonplaceholder.typicode.com atau httpbin.org. Keduanya gratis dan memang disediakan untuk uji coba. Endpoint /todos/1 di jsonplaceholder membalas JSON seperti ini:

{
  "userId": 1,
  "id": 1,
  "title": "delectus aut autem",
  "completed": false
}

Kita tampung ke struct dengan json tag, persis seperti saat kita menerima request body di bagian 11, hanya arahnya terbalik:

type Todo struct {
	UserID    int    `json:"userId"`
	ID        int    `json:"id"`
	Title     string `json:"title"`
	Completed bool   `json:"completed"`
}

func main() {
	body, err := ambilTodo(context.Background())
	if err != nil {
		log.Fatal(err)
	}

	var todo Todo
	if err := json.Unmarshal(body, &todo); err != nil {
		log.Fatal(err)
	}
	fmt.Printf("judul: %s, selesai: %t\n", todo.Title, todo.Completed)
}

Field yang tidak ada di struct akan diabaikan, jadi kamu cukup mendeklarasikan field yang benar-benar kamu pakai. Respons API pihak ketiga sering gemuk, ambil yang perlu saja.

POST JSON: kirim data plus kunci API

Memanggil payment gateway atau WhatsApp gateway hampir selalu berupa POST dengan body JSON dan header autentikasi. Polanya begini:

type PermintaanBayar struct {
	OrderID string `json:"order_id"`
	Jumlah  int64  `json:"jumlah"`
	Metode  string `json:"metode"`
}

func buatTagihan(ctx context.Context) error {
	payload, err := json.Marshal(PermintaanBayar{
		OrderID: "INV-2026-001",
		Jumlah:  150000,
		Metode:  "qris",
	})
	if err != nil {
		return err
	}

	req, err := http.NewRequestWithContext(ctx, http.MethodPost,
		"https://api.pembayaran.example.com/v1/charge",
		bytes.NewReader(payload))
	if err != nil {
		return err
	}
	req.Header.Set("Content-Type", "application/json")
	req.Header.Set("Authorization", "Bearer "+os.Getenv("PAYMENT_API_KEY"))

	resp, err := httpClient.Do(req)
	if err != nil {
		return fmt.Errorf("request gagal: %w", err)
	}
	defer resp.Body.Close()

	if resp.StatusCode != http.StatusOK && resp.StatusCode != http.StatusCreated {
		body, _ := io.ReadAll(resp.Body)
		return fmt.Errorf("pembayaran ditolak, status %d: %s", resp.StatusCode, body)
	}
	return nil
}

Urutannya selalu sama: marshal struct jadi byte, bungkus dengan bytes.NewReader, set header Content-Type supaya server tahu isi body-nya JSON, lalu set Authorization dengan kunci API yang diambil dari environment variable. Bukan dari string yang ditulis langsung di kode.

Tiga jenis kegagalan, tiga perlakuan berbeda

Saat memanggil API eksternal, error itu bukan satu jenis. Ada tiga, dan perlakuannya beda.

Error jaringan. httpClient.Do mengembalikan error: DNS gagal, koneksi ditolak, atau timeout. Kamu bahkan tidak dapat respons. Kegagalan seperti ini sering sementara, jadi retry masuk akal.

Status 4xx. Server menerima request-mu dan menolaknya. 400 berarti body-mu salah format, 401 kunci API salah, 404 endpoint keliru, 422 datanya tidak valid. Ini bug di sisimu. Mengulang request yang sama akan ditolak lagi dengan alasan yang sama. Jangan retry, catat errornya dan perbaiki penyebabnya.

Status 5xx. Server pihak ketiga sedang bermasalah. Bukan salahmu, dan biasanya sembuh sendiri. Retry pantas di sini, dengan jeda yang membesar seperti pola backoff yang kita pakai untuk email di bagian 21.

func doDenganRetry(ctx context.Context,
	buatReq func() (*http.Request, error)) (*http.Response, error) {

	var errTerakhir error
	for percobaan := 1; percobaan <= 3; percobaan++ {
		req, err := buatReq()
		if err != nil {
			return nil, err
		}

		resp, err := httpClient.Do(req)
		if err != nil {
			errTerakhir = err // error jaringan, coba lagi
		} else if resp.StatusCode >= 500 {
			resp.Body.Close()
			errTerakhir = fmt.Errorf("server membalas %d", resp.StatusCode)
		} else {
			return resp, nil // sukses atau 4xx, keduanya final
		}

		jeda := time.Duration(percobaan*percobaan) * time.Second
		select {
		case <-time.After(jeda):
		case <-ctx.Done():
			return nil, ctx.Err()
		}
	}
	return nil, fmt.Errorf("menyerah setelah 3 percobaan: %w", errTerakhir)
}

Perhatikan dua detail. Request dibuat ulang lewat buatReq di tiap percobaan, karena body request hanya bisa dibaca sekali. Dan jeda backoff dipotong oleh ctx.Done(), jadi kalau user sudah pergi, kita tidak sibuk mengulang untuk siapa-siapa.

Bungkus jadi client struct yang rapi

Kalau kode pemanggilan API berserakan di handler, tiap perubahan endpoint memaksa kamu mengedit banyak tempat. Ikuti struktur proyek yang kita susun di bagian 16: bungkus semua urusan satu layanan eksternal ke dalam satu struct.

type OngkirClient struct {
	baseURL    string
	apiKey     string
	httpClient *http.Client
}

func NewOngkirClient(baseURL, apiKey string) *OngkirClient {
	return &OngkirClient{
		baseURL:    baseURL,
		apiKey:     apiKey,
		httpClient: &http.Client{Timeout: 10 * time.Second},
	}
}

type Ongkir struct {
	Kurir    string `json:"kurir"`
	Biaya    int64  `json:"biaya"`
	Estimasi string `json:"estimasi"`
}

func (c *OngkirClient) CekOngkir(ctx context.Context,
	asal, tujuan string, beratGram int) ([]Ongkir, error) {

	url := fmt.Sprintf("%s/ongkir?asal=%s&tujuan=%s&berat=%d",
		c.baseURL, asal, tujuan, beratGram)

	req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
	if err != nil {
		return nil, err
	}
	req.Header.Set("Authorization", "Bearer "+c.apiKey)

	resp, err := c.httpClient.Do(req)
	if err != nil {
		return nil, fmt.Errorf("gagal menghubungi API ongkir: %w", err)
	}
	defer resp.Body.Close()

	if resp.StatusCode != http.StatusOK {
		return nil, fmt.Errorf("API ongkir membalas status %d", resp.StatusCode)
	}

	var daftar []Ongkir
	if err := json.NewDecoder(resp.Body).Decode(&daftar); err != nil {
		return nil, fmt.Errorf("respons ongkir tidak valid: %w", err)
	}
	return daftar, nil
}

Perhatikan tipe kembaliannya: []Ongkir, struct domain milikmu sendiri. Bukan []byte, bukan map[string]interface{}. Pemakai client ini tidak perlu tahu bentuk JSON pihak ketiga. Kalau suatu hari kamu ganti penyedia ongkir, cukup ubah isi client ini, seluruh handler tetap aman.

Bonus besar dari pola ini: gampang dites. Karena baseURL bisa disuntik dari luar, kamu bisa mengarahkannya ke server palsu buatan httptest.NewServer, alat yang sudah kita kenal di bagian 14.

func TestCekOngkir(t *testing.T) {
	server := httptest.NewServer(http.HandlerFunc(
		func(w http.ResponseWriter, r *http.Request) {
			fmt.Fprint(w, `[{"kurir":"JNE","biaya":9000,"estimasi":"2-3 hari"}]`)
		}))
	defer server.Close()

	client := NewOngkirClient(server.URL, "kunci-tes")
	hasil, err := client.CekOngkir(context.Background(), "purwokerto", "semarang", 1000)
	if err != nil {
		t.Fatalf("tidak mengharapkan error: %v", err)
	}
	if hasil[0].Kurir != "JNE" {
		t.Errorf("kurir salah: %s", hasil[0].Kurir)
	}
}

Tes ini jalan tanpa internet, tanpa kunci API asli, dan selesai dalam hitungan milidetik.

Rahasia di env, dan sopan santun ke pihak ketiga

Dua aturan terakhir sebelum latihan. Pertama, kunci API adalah rahasia. Simpan di environment variable seperti yang kita biasakan di bagian 18, dan jangan pernah menuliskannya ke log. Baris seperti log.Printf("memanggil API dengan key %s", apiKey) kelihatan sepele saat debugging, tapi log tersimpan lama dan dibaca banyak orang. Log-lah nama layanan dan status, bukan kredensialnya.

Kedua, hormati rate limit. Hampir semua API komersial membatasi jumlah request per menit, dan membalas 429 kalau kamu kebablasan. Baca dokumentasi limitnya, beri jeda antar request massal, dan kalau kebutuhanmu besar, atur antrean dengan worker pool seperti di bagian 19. Akun yang terus menabrak limit bisa diblokir, dan itu masalah yang jauh lebih mahal daripada menambah satu time.Sleep.

Latihan: client kurs dipakai dari handler produk

Sekarang kita gabungkan semuanya. Program di bawah ini punya tiga bagian: server palsu dari httptest yang berperan sebagai API kurs, sebuah KursClient, dan handler /produk yang memakai client itu untuk menghitung harga rupiah.

package main

import (
	"context"
	"encoding/json"
	"fmt"
	"log"
	"net/http"
	"net/http/httptest"
	"time"
)

type KursClient struct {
	baseURL    string
	apiKey     string
	httpClient *http.Client
}

func NewKursClient(baseURL, apiKey string) *KursClient {
	return &KursClient{
		baseURL:    baseURL,
		apiKey:     apiKey,
		httpClient: &http.Client{Timeout: 5 * time.Second},
	}
}

type Kurs struct {
	Kode  string  `json:"kode"`
	Nilai float64 `json:"nilai"`
}

func (c *KursClient) Ambil(ctx context.Context, kode string) (Kurs, error) {
	req, err := http.NewRequestWithContext(ctx, http.MethodGet,
		c.baseURL+"/kurs?kode="+kode, nil)
	if err != nil {
		return Kurs{}, err
	}
	req.Header.Set("Authorization", "Bearer "+c.apiKey)

	resp, err := c.httpClient.Do(req)
	if err != nil {
		return Kurs{}, fmt.Errorf("gagal menghubungi API kurs: %w", err)
	}
	defer resp.Body.Close()

	if resp.StatusCode != http.StatusOK {
		return Kurs{}, fmt.Errorf("API kurs membalas status %d", resp.StatusCode)
	}

	var k Kurs
	if err := json.NewDecoder(resp.Body).Decode(&k); err != nil {
		return Kurs{}, fmt.Errorf("respons kurs tidak valid: %w", err)
	}
	return k, nil
}

func main() {
	// API palsu, berperan sebagai penyedia kurs sungguhan
	palsu := httptest.NewServer(http.HandlerFunc(
		func(w http.ResponseWriter, r *http.Request) {
			if r.URL.Query().Get("kode") != "USD" {
				http.Error(w, `{"error":"kode tidak dikenal"}`, http.StatusNotFound)
				return
			}
			w.Header().Set("Content-Type", "application/json")
			fmt.Fprint(w, `{"kode":"USD","nilai":16250}`)
		}))
	defer palsu.Close()

	client := NewKursClient(palsu.URL, "kunci-rahasia")

	http.HandleFunc("/produk", func(w http.ResponseWriter, r *http.Request) {
		kurs, err := client.Ambil(r.Context(), "USD")
		if err != nil {
			log.Printf("cek kurs gagal: %v", err)
			http.Error(w, `{"error":"layanan kurs sedang bermasalah"}`,
				http.StatusBadGateway)
			return
		}

		hargaUSD := 25.0
		w.Header().Set("Content-Type", "application/json")
		fmt.Fprintf(w, `{"produk":"Lisensi Pro","harga_rupiah":%.0f}`,
			hargaUSD*kurs.Nilai)
	})

	log.Println("server jalan di :8080")
	log.Fatal(http.ListenAndServe(":8080", nil))
}

Jalankan dengan go run main.go, lalu coba dari terminal lain. Ini output saat semuanya lancar:

$ curl localhost:8080/produk
{"produk":"Lisensi Pro","harga_rupiah":406250}

Sekarang uji jalur gagalnya. Ubah kode mata uang di handler dari "USD" menjadi "EUR", jalankan ulang, lalu panggil lagi:

$ curl localhost:8080/produk
{"error":"layanan kurs sedang bermasalah"}

// di log server:
2026/07/27 10:15:03 cek kurs gagal: API kurs membalas status 404

Perhatikan pembagian perannya. User hanya menerima pesan yang sopan dan status 502, sedangkan detail teknisnya masuk ke log untukmu. API pihak ketiga boleh rusak, aplikasimu tetap berdiri dan menjawab dengan jelas. Itu inti dari seluruh bagian ini.

Sebagai latihan tambahan, ganti httptest.Server di atas dengan API publik sungguhan, atau tambahkan doDenganRetry ke dalam method Ambil supaya error 5xx dicoba ulang otomatis.

Selanjutnya: bicara serius dengan database

Aplikasi kita sekarang bisa melayani request, mengirim email, dan memanggil layanan lain. Di bagian 23 kita kembali ke dalam: Transaksi Database dan Migrasi Skema. Kamu akan belajar menjaga data tetap konsisten saat beberapa operasi harus berhasil bersama-sama, dan mengelola perubahan struktur tabel tanpa drama.

Kalau sistemmu perlu terhubung ke payment gateway, WhatsApp gateway, atau API internal antar divisi, tim Arrazy sudah sering mengerjakan integrasi seperti ini. Lihat layanan pengembangan sistem aplikasi kami untuk berdiskusi soal kebutuhanmu.