Category: Tutorial

Di Belajar Golang dari Nol #13, API produk kita sudah punya middleware logging dan proteksi API key. Endpoint aman, setiap request tercatat. Tapi ada satu kebiasaan yang masih kita lakukan sejak bagian 11. Setiap selesai mengubah kode, kita jalankan server, buka Postman, lalu klik kirim request satu per satu untuk memastikan semuanya masih jalan.

Cara itu melelahkan. Dan yang lebih bahaya, gampang kelewat. Kamu perbaiki handler POST, lupa cek handler GET, ternyata yang GET ikut rusak. Di bagian ini kita belajar cara yang lebih waras, yaitu menyuruh Go sendiri yang mengetes kode kita. Namanya automated testing, dan Go menyediakannya bawaan tanpa install apa pun.

Kenapa Testing Bukan Kemewahan

Banyak pemula menganggap testing itu urusan nanti, sesuatu yang dikerjakan kalau sempat. Padahal ada tiga alasan kenapa testing justru menghemat waktu.

• Refactor tanpa takut. Mau ganti struktur kode, rapikan function, atau pindah logika ke file lain. Selama test lulus, kamu tahu perilaku kode tidak berubah. Tanpa test, setiap refactor terasa seperti jalan di atas es tipis.
• Bukti kode jalan. Satu perintah go test menggantikan puluhan klik manual di Postman. Sekali tulis, tes bisa diulang ribuan kali secara gratis.
• Syarat kerja tim. Di hampir semua tim backend profesional, kode tanpa test tidak akan lolos code review. Kalau kamu berencana kerja sebagai backend developer Go, kebiasaan menulis test bukan nilai plus lagi. Itu standar minimum.

Kabar baiknya, Go serius soal ini. Tool testing sudah ada di dalam bahasa lewat package testing dan perintah go test. Tidak perlu install framework pihak ketiga seperti di bahasa lain.

Aturan Dasar Testing di Go

Go punya konvensi sederhana. Ikuti aturannya, dan semuanya jalan otomatis.

• File test diberi akhiran _test.go. Contoh: kode ada di produk.go, testnya di produk_test.go. File ini tidak ikut ter-compile saat build biasa.
• Function test harus diawali Test dengan huruf besar setelahnya, dan menerima satu parameter t *testing.T. Contoh: func TestHitungDiskon(t *testing.T).
• Jalankan dengan go test di folder project. Tambahkan -v kalau mau lihat detail tiap test.

go test        # jalankan semua test, hanya tampilkan ringkasan
go test -v     # verbose, tampilkan tiap test dan hasilnya

Tidak ada function main yang perlu dipanggil. Tidak ada registrasi test di mana pun. Go mencari sendiri semua file _test.go dan menjalankan semua function TestXxx di dalamnya.

Test Pertama: Menguji Function Murni

Target paling enak untuk test pertama adalah function murni, yaitu function yang hasilnya hanya bergantung pada input. Tidak menyentuh database, tidak menyentuh network. Dari seri sebelumnya kita sudah punya dua kandidat, yaitu validasi produk dan hitung diskon. Ini versi ringkasnya di produk.go.

func ValidasiProduk(p Produk) error {
	if p.Nama == "" {
		return errors.New("nama produk tidak boleh kosong")
	}
	if p.Harga <= 0 {
		return errors.New("harga harus lebih dari nol")
	}
	if p.Stok < 0 {
		return errors.New("stok tidak boleh minus")
	}
	return nil
}

func HitungDiskon(harga, persen int) (int, error) {
	if persen < 0 || persen > 100 {
		return 0, errors.New("persen diskon harus 0 sampai 100")
	}
	return harga - (harga * persen / 100), nil
}

Sekarang buat file produk_test.go di folder yang sama, lalu tulis test pertama.

package main

import "testing"

func TestHitungDiskon(t *testing.T) {
	got, err := HitungDiskon(100000, 10)
	if err != nil {
		t.Fatalf("tidak mengharapkan error, dapat: %v", err)
	}
	want := 90000
	if got != want {
		t.Errorf("HitungDiskon(100000, 10) = %d, ingin %d", got, want)
	}
}

Polanya selalu sama. Panggil function dengan input tertentu, simpan hasilnya di got, bandingkan dengan nilai harapan di want. Kalau beda, laporkan lewat t.Errorf. Perhatikan pesan errornya. Pesan yang baik menyebut input, hasil yang didapat, dan hasil yang diinginkan. Saat test gagal enam bulan lagi, pesan itu yang menyelamatkanmu dari menebak-nebak.

Ada dua cara melaporkan kegagalan. t.Errorf menandai test gagal tapi lanjut ke baris berikutnya. t.Fatalf menandai gagal dan langsung berhenti. Pakai Fatalf kalau pengecekan berikutnya tidak ada artinya lagi, misalnya errornya saja sudah muncul.

Table Driven Test, Idiom Paling Penting

Satu function biasanya perlu diuji dengan banyak kombinasi input. Menyalin test di atas lima kali dengan angka berbeda jelas bukan solusi. Idiom Go untuk masalah ini bernama table driven test. Idenya, kumpulkan semua kasus dalam satu slice of struct, lalu loop.

func TestHitungDiskonTable(t *testing.T) {
	kasus := []struct {
		nama     string
		harga    int
		persen   int
		want     int
		inginErr bool
	}{
		{"diskon normal 10 persen", 100000, 10, 90000, false},
		{"tanpa diskon", 50000, 0, 50000, false},
		{"diskon penuh", 80000, 100, 0, false},
		{"persen minus harus gagal", 100000, -5, 0, true},
		{"persen di atas 100 harus gagal", 100000, 150, 0, true},
	}

	for _, k := range kasus {
		t.Run(k.nama, func(t *testing.T) {
			got, err := HitungDiskon(k.harga, k.persen)
			if k.inginErr {
				if err == nil {
					t.Errorf("mengharapkan error, tapi dapat nil")
				}
				return
			}
			if err != nil {
				t.Fatalf("tidak mengharapkan error, dapat: %v", err)
			}
			if got != k.want {
				t.Errorf("dapat %d, ingin %d", got, k.want)
			}
		})
	}
}

Setiap kasus punya nama, dan t.Run menjalankannya sebagai subtest terpisah. Saat go test -v jalan, kamu bisa lihat kasus mana yang lulus dan mana yang gagal, lengkap dengan namanya.

Kenapa pola ini enak dirawat. Menambah kasus baru cukup satu baris di tabel, bukan satu function baru. Logika pengujian ditulis sekali, tidak ada copy paste yang bisa melenceng. Dan tabelnya sendiri menjadi dokumentasi perilaku function.

Menguji Kasus yang Harus Gagal

Pemula sering hanya menguji jalur bahagia, yaitu input benar menghasilkan output benar. Padahal bug paling sering muncul di jalur sebaliknya. Input jelek harus ditolak, dan test harus memastikan penolakan itu benar-benar terjadi.

func TestValidasiProdukStokMinus(t *testing.T) {
	p := Produk{Nama: "Kopi Gayo", Harga: 45000, Stok: -3}
	err := ValidasiProduk(p)
	if err == nil {
		t.Errorf("stok minus seharusnya gagal validasi, tapi error nil")
	}
}

Perhatikan logikanya terbalik dari test biasa. Di sini kondisi gagal justru err == nil. Kalau suatu hari ada yang tidak sengaja menghapus pengecekan stok di ValidasiProduk, test ini langsung merah. Tanpa test ini, produk berstok minus bisa masuk database dan baru ketahuan saat pelanggan komplain.

Menguji Handler HTTP dengan httptest

Function murni sudah aman. Sekarang bagian yang lebih menarik, yaitu menguji handler API tanpa menjalankan server sama sekali. Go menyediakan package net/http/httptest untuk ini. Dua pemain utamanya adalah httptest.NewRequest untuk membuat request palsu dan httptest.NewRecorder untuk menangkap response.

Supaya fokus ke teknik testingnya, kita pakai handler versi in-memory yang sederhana. Di project kamu, handler dari bagian 11 dan 12 bisa diuji dengan pola yang sama persis.

var daftarProduk = []Produk{
	{ID: 1, Nama: "Kopi Gayo", Harga: 45000, Stok: 10},
	{ID: 2, Nama: "Teh Melati", Harga: 20000, Stok: 25},
}

func handlerListProduk(w http.ResponseWriter, r *http.Request) {
	w.Header().Set("Content-Type", "application/json")
	json.NewEncoder(w).Encode(daftarProduk)
}

func handlerTambahProduk(w http.ResponseWriter, r *http.Request) {
	var p Produk
	if err := json.NewDecoder(r.Body).Decode(&p); err != nil {
		http.Error(w, "body JSON tidak valid", http.StatusBadRequest)
		return
	}
	if err := ValidasiProduk(p); err != nil {
		http.Error(w, err.Error(), http.StatusBadRequest)
		return
	}
	p.ID = len(daftarProduk) + 1
	daftarProduk = append(daftarProduk, p)
	w.Header().Set("Content-Type", "application/json")
	w.WriteHeader(http.StatusCreated)
	json.NewEncoder(w).Encode(p)
}

Menguji handler GET produk

func TestHandlerListProduk(t *testing.T) {
	req := httptest.NewRequest(http.MethodGet, "/produk", nil)
	rec := httptest.NewRecorder()

	handlerListProduk(rec, req)

	if rec.Code != http.StatusOK {
		t.Fatalf("status = %d, ingin %d", rec.Code, http.StatusOK)
	}

	var hasil []Produk
	if err := json.Unmarshal(rec.Body.Bytes(), &hasil); err != nil {
		t.Fatalf("body bukan JSON valid: %v", err)
	}
	if len(hasil) == 0 {
		t.Errorf("daftar produk kosong, ingin minimal 1 produk")
	}
}

Alurnya tiga langkah. Buat request palsu, siapkan recorder, panggil handler seperti function biasa. Recorder menyimpan semua yang ditulis handler, yaitu status code di rec.Code dan body di rec.Body. Kita cek status 200, lalu pastikan bodynya JSON valid. Semua terjadi di memori, tanpa port terbuka, tanpa server jalan, selesai dalam hitungan milidetik.

Menguji POST dengan body invalid

Sekarang jalur gagalnya. Kirim produk dengan nama kosong, dan handler harus menjawab 400.

func TestHandlerTambahProdukBodyInvalid(t *testing.T) {
	body := strings.NewReader(`{"nama": ""}`)
	req := httptest.NewRequest(http.MethodPost, "/produk", body)
	rec := httptest.NewRecorder()

	handlerTambahProduk(rec, req)

	if rec.Code != http.StatusBadRequest {
		t.Errorf("status = %d, ingin %d", rec.Code, http.StatusBadRequest)
	}
}

Body request dibuat dari string biasa lewat strings.NewReader. Test ini menjaga kontrak API kita. Selama test ini lulus, klien yang mengirim data kacau dijamin dapat 400, bukan 500 atau lebih parah lagi, data kacau yang tersimpan diam-diam.

Menguji Endpoint yang Dilindungi API Key

Di bagian 13 kita membungkus handler dengan middleware cekAPIKey yang memeriksa header X-API-Key. Middleware juga bisa diuji dengan httptest. Kuncinya, bungkus handler dengan middleware dulu, lalu panggil lewat ServeHTTP.

func TestMiddlewareAPIKey(t *testing.T) {
	handler := cekAPIKey(http.HandlerFunc(handlerListProduk))

	t.Run("tanpa API key ditolak", func(t *testing.T) {
		req := httptest.NewRequest(http.MethodGet, "/produk", nil)
		rec := httptest.NewRecorder()

		handler.ServeHTTP(rec, req)

		if rec.Code != http.StatusUnauthorized {
			t.Errorf("status = %d, ingin %d", rec.Code, http.StatusUnauthorized)
		}
	})

	t.Run("dengan API key benar lolos", func(t *testing.T) {
		req := httptest.NewRequest(http.MethodGet, "/produk", nil)
		req.Header.Set("X-API-Key", "rahasia123")
		rec := httptest.NewRecorder()

		handler.ServeHTTP(rec, req)

		if rec.Code != http.StatusOK {
			t.Errorf("status = %d, ingin %d", rec.Code, http.StatusOK)
		}
	})
}

Dua skenario dalam satu test. Request tanpa header harus mentok di 401, request dengan key yang benar harus tembus dan dapat 200. Test seperti ini penting karena bug di lapisan auth adalah bug keamanan. Kalau ada perubahan yang tidak sengaja mematikan pengecekan API key, test ini langsung gagal sebelum kode naik ke server.

Coverage: Melihat Bagian yang Belum Teruji

Go bisa menghitung berapa persen baris kode yang tersentuh test.

$ go test -cover
PASS
coverage: 75.9% of statements
ok      toko-api        0.018s

Satu hal yang perlu diluruskan sejak awal. Angka coverage bukan tujuan, melainkan petunjuk. Coverage 75.9% artinya masih ada sekitar seperempat kode yang belum pernah dijalankan oleh test mana pun, dan di situlah bug bisa bersembunyi. Mengejar 100% dengan test asal-asalan jauh lebih buruk daripada 75% dengan test yang benar-benar memeriksa perilaku penting. Pakai coverage untuk menemukan lubang, bukan untuk pamer angka.

Kebiasaan Sehat Menulis Test

• Test kecil dan cepat. Satu test menguji satu perilaku. Test yang lambat akan malas dijalankan, dan test yang tidak dijalankan sama saja tidak ada.
• Nama test menjelaskan skenario. TestHandlerTambahProdukBodyInvalid langsung terbaca maksudnya. TestProduk2 tidak menceritakan apa pun.
• Jalankan sebelum commit. Biasakan go test ./... sebelum git commit. Perintah ini menjalankan test di semua package dalam project.
• Kenali t.Helper. Kalau kamu membuat function bantuan untuk test, panggil t.Helper() di baris pertamanya. Dengan begitu saat gagal, Go menunjuk baris pemanggilnya, bukan baris di dalam helper. Cukup tahu dulu, kamu akan membutuhkannya saat file test mulai panjang.

Latihan: produk_test.go Utuh

Sebagai latihan penutup, gabungkan semuanya. Ini file test untuk function validasi CRUD produk dengan table driven, ditambah satu handler test.

package main

import (
	"encoding/json"
	"net/http"
	"net/http/httptest"
	"testing"
)

func TestValidasiProduk(t *testing.T) {
	kasus := []struct {
		nama     string
		produk   Produk
		inginErr bool
	}{
		{"produk valid", Produk{Nama: "Kopi Gayo", Harga: 45000, Stok: 10}, false},
		{"nama kosong", Produk{Nama: "", Harga: 45000, Stok: 10}, true},
		{"harga nol", Produk{Nama: "Kopi Gayo", Harga: 0, Stok: 10}, true},
		{"harga minus", Produk{Nama: "Kopi Gayo", Harga: -100, Stok: 10}, true},
		{"stok minus", Produk{Nama: "Kopi Gayo", Harga: 45000, Stok: -3}, true},
	}

	for _, k := range kasus {
		t.Run(k.nama, func(t *testing.T) {
			err := ValidasiProduk(k.produk)
			if k.inginErr && err == nil {
				t.Errorf("mengharapkan error, tapi dapat nil")
			}
			if !k.inginErr && err != nil {
				t.Errorf("tidak mengharapkan error, dapat: %v", err)
			}
		})
	}
}

func TestHandlerListProduk(t *testing.T) {
	req := httptest.NewRequest(http.MethodGet, "/produk", nil)
	rec := httptest.NewRecorder()

	handlerListProduk(rec, req)

	if rec.Code != http.StatusOK {
		t.Fatalf("status = %d, ingin %d", rec.Code, http.StatusOK)
	}

	var hasil []Produk
	if err := json.Unmarshal(rec.Body.Bytes(), &hasil); err != nil {
		t.Fatalf("body bukan JSON valid: %v", err)
	}
}

Jalankan dengan go test -v. Kalau semuanya benar, hasilnya seperti ini.

$ go test -v
=== RUN   TestValidasiProduk
=== RUN   TestValidasiProduk/produk_valid
=== RUN   TestValidasiProduk/nama_kosong
=== RUN   TestValidasiProduk/harga_nol
=== RUN   TestValidasiProduk/harga_minus
=== RUN   TestValidasiProduk/stok_minus
--- PASS: TestValidasiProduk (0.00s)
    --- PASS: TestValidasiProduk/produk_valid (0.00s)
    --- PASS: TestValidasiProduk/nama_kosong (0.00s)
    --- PASS: TestValidasiProduk/harga_nol (0.00s)
    --- PASS: TestValidasiProduk/harga_minus (0.00s)
    --- PASS: TestValidasiProduk/stok_minus (0.00s)
=== RUN   TestHandlerListProduk
--- PASS: TestHandlerListProduk (0.00s)
PASS
ok      toko-api        0.017s

Barisan PASS itu bukan sekadar hiasan. Itu bukti tertulis bahwa validasi produk dan handler API kamu berperilaku sesuai harapan, dan bukti itu bisa diperbarui kapan saja dengan satu perintah. Coba tambahkan sendiri test untuk handlerTambahProduk dengan kasus sukses, lalu ukur lagi dengan go test -cover dan lihat angkanya naik.

Selanjutnya: Naik ke Server

API produk kita sekarang punya endpoint CRUD, database, middleware, proteksi API key, dan barisan test yang menjaga semuanya. Tinggal satu langkah besar yang belum, yaitu keluar dari laptop. Di bagian 15, Deploy API Go ke Server: dari Laptop ke Production, kita akan membawa API ini ke server sungguhan supaya bisa diakses siapa pun.

Kalau kamu ingin membangun API atau sistem aplikasi yang teruji dan siap production tanpa mengerjakan semuanya sendiri, tim Arrazy bisa membantu dari perancangan sampai deployment.

Di Belajar Golang dari Nol #12 kita sudah menyambungkan API produk ke database. Data sekarang tersimpan beneran, bukan hilang tiap server restart. Tapi ada satu masalah besar yang belum kita sentuh. API kita masih terbuka lebar. Siapa pun yang tahu alamatnya bisa POST produk baru, mengubah harga, bahkan menghapus data. Di bagian ini kita tutup lubang itu pakai dua konsep: middleware dan autentikasi sederhana.

Masalahnya: API kita masih pintu tanpa kunci

Coba bayangkan API produk dari bagian 12 sudah kamu deploy ke server. Alamatnya ketahuan orang. Apa yang terjadi?

• Orang iseng bisa kirim POST /produk dan mengisi database kamu dengan data sampah.
• Kompetitor bisa hapus semua produk lewat DELETE.
• Kamu tidak tahu siapa yang mengakses, kapan, dan endpoint mana yang paling sering dipanggil.

Jadi ada dua kebutuhan yang berbeda tapi berkaitan. Pertama, kita perlu tahu siapa pemanggil API dan menolak yang tidak berhak. Itu namanya autentikasi. Kedua, pengecekan ini harus jalan di banyak endpoint sekaligus. Kalau kita tulis kode cek di setiap handler satu per satu, itu copy paste yang bakal jadi mimpi buruk saat endpoint bertambah. Solusi untuk masalah kedua ini namanya middleware.

Apa itu middleware

Middleware adalah function yang membungkus handler. Dia berdiri di antara request masuk dan handler yang memprosesnya.

Analoginya begini. Bayangkan gedung kantor dengan banyak ruangan. Setiap ruangan adalah handler: ruang produk, ruang laporan, ruang admin. Middleware adalah satpam di lobi. Semua tamu harus lewat dia dulu, mau ke ruangan mana pun. Satpam bisa mencatat tamu di buku (logging), memeriksa kartu identitas (auth), atau menolak tamu yang mencurigakan. Ruangan tidak perlu tahu urusan pemeriksaan itu. Mereka cukup fokus pada pekerjaannya.

Bentuk middleware di Go

Di Go, middleware punya bentuk yang khas:

func namaMiddleware(next http.Handler) http.Handler

Baca pelan. Function ini menerima sebuah http.Handler dan mengembalikan http.Handler juga. Masih ingat dua materi lama kita? http.Handler adalah interface, yaitu apa pun yang punya method ServeHTTP. Dan function di Go adalah nilai yang bisa dioper dan dikembalikan seperti angka atau string. Middleware menggabungkan keduanya. Dia menerima handler asli lewat parameter next, lalu mengembalikan handler baru yang menjalankan logika tambahan sebelum atau sesudah memanggil next.

Karena input dan output sama-sama http.Handler, hasil bungkusan bisa dibungkus lagi. Ini yang bikin middleware bisa dirangkai.

Middleware pertama: logging

Kita mulai dari yang paling tidak berbahaya: mencatat setiap request. Method apa, path apa, dan berapa lama diproses.

func logging(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        mulai := time.Now()
        next.ServeHTTP(w, r)
        log.Printf("%s %s selesai dalam %v", r.Method, r.URL.Path, time.Since(mulai))
    })
}

Perhatikan alurnya. Kita catat waktu mulai, panggil handler asli lewat next.ServeHTTP(w, r), lalu hitung durasinya pakai time.Since. Kode sebelum next.ServeHTTP jalan sebelum handler. Kode sesudahnya jalan setelah handler selesai.

http.HandlerFunc di sini adalah adapter yang sudah kita kenal sejak bagian 11. Dia mengubah function biasa menjadi sesuatu yang memenuhi interface http.Handler.

Cara pasangnya: bungkus mux sebelum diserahkan ke server.

mux := http.NewServeMux()
mux.HandleFunc("GET /produk", listProduk)

log.Fatal(http.ListenAndServe(":8080", logging(mux)))

Karena yang dibungkus adalah mux, semua endpoint otomatis tercatat. Satu function, berlaku di mana-mana. Tidak ada copy paste.

Middleware kedua: API key

Sekarang bagian auth. Cara paling sederhana adalah API key: sebuah string rahasia yang harus dikirim client lewat header. Kalau key cocok, request lolos. Kalau tidak, tolak dengan status 401 Unauthorized.

func cekAPIKey(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        kunci := os.Getenv("API_KEY")
        if kunci == "" || r.Header.Get("X-API-Key") != kunci {
            w.Header().Set("Content-Type", "application/json")
            w.WriteHeader(http.StatusUnauthorized)
            json.NewEncoder(w).Encode(map[string]string{"error": "API key salah atau tidak ada"})
            return
        }
        next.ServeHTTP(w, r)
    })
}

Ada beberapa hal penting di sini.

Pertama, key aslinya diambil dari environment variable lewat os.Getenv, bukan ditulis langsung di kode. Kenapa? Karena kode biasanya masuk Git. Kalau key kamu hardcode, siapa pun yang bisa baca repo tahu rahasianya. Dengan environment variable, key hidup di server, terpisah dari kode. Ganti key pun tidak perlu compile ulang.

Kedua, kita cek kunci == "" dulu. Kalau server lupa diset API_KEY, semua request ditolak. Ini lebih aman daripada sebaliknya, yaitu semua request lolos karena membandingkan string kosong dengan string kosong.

Ketiga, jangan lupa return setelah menulis respons 401. Tanpa itu, eksekusi lanjut ke next.ServeHTTP dan handler tetap jalan. Ini bug klasik middleware.

Satu catatan jujur. API key statis seperti ini cocok untuk API internal atau komunikasi antar sistem, misalnya server kamu dipanggil oleh server kantor lain yang sudah kamu kenal. Untuk login user publik dengan ribuan akun, ini tidak cukup. Kita bahas alasannya di bawah.

Merangkai beberapa middleware

Karena middleware menerima handler dan mengembalikan handler, kita bisa menumpuknya:

handler := logging(cekAPIKey(mux))
log.Fatal(http.ListenAndServe(":8080", handler))

Urutan bacanya dari luar ke dalam. Request masuk ke logging dulu, lalu cekAPIKey, baru sampai ke mux dan handler. Respons berjalan sebaliknya, dari dalam ke luar.

Cara paling gampang membuktikan urutan adalah menambah log sementara di tiap middleware. Kalau kamu tambahkan log.Println("masuk logging") di awal logging dan log.Println("masuk cekAPIKey") di awal cekAPIKey, outputnya seperti ini:

2026/07/26 10:15:02 masuk logging
2026/07/26 10:15:02 masuk cekAPIKey
2026/07/26 10:15:02 POST /produk selesai dalam 3.1ms

Terlihat jelas. Middleware terluar jalan duluan. Baris durasi muncul terakhir karena dia ditulis setelah next.ServeHTTP selesai. Urutan ini penting saat middleware saling bergantung. Logging biasanya paling luar supaya request yang ditolak auth pun tetap tercatat.

Middleware selektif: tidak semua endpoint butuh kunci

Ada masalah baru. Kalau cekAPIKey membungkus seluruh mux, endpoint GET /produk ikut terkunci. Padahal daftar produk biasanya memang untuk publik. Yang perlu dijaga hanya operasi tulis: POST, PUT, DELETE.

Solusinya, pasang middleware per route, bukan di mux. mux.Handle menerima http.Handler, jadi kita bisa membungkus handler tertentu saja:

mux := http.NewServeMux()

// publik, tanpa kunci
mux.HandleFunc("GET /produk", listProduk)
mux.HandleFunc("GET /produk/{id}", detailProduk)

// dilindungi API key
mux.Handle("POST /produk", cekAPIKey(http.HandlerFunc(tambahProduk)))
mux.Handle("PUT /produk/{id}", cekAPIKey(http.HandlerFunc(ubahProduk)))
mux.Handle("DELETE /produk/{id}", cekAPIKey(http.HandlerFunc(hapusProduk)))

// logging tetap membungkus semua
handler := logging(mux)

Pola "POST /produk" dengan method di depan adalah fitur routing Go 1.22 yang sudah kita pakai sejak bagian 11. Sekarang terasa manfaatnya: satu path bisa punya perlakuan beda per method.

Sekilas jujur soal auth user sungguhan

API key cukup untuk API internal. Tapi begitu kamu bikin aplikasi dengan user yang mendaftar dan login sendiri, kebutuhannya beda jauh. Ada tiga hal yang minimal harus kamu tahu namanya.

Pertama, password tidak boleh disimpan mentah di database. Password harus di-hash pakai algoritma yang memang dirancang untuk itu, misalnya bcrypt. Hash itu satu arah. Kalau database bocor, penyerang tidak langsung dapat password asli.

Kedua, setelah user login, server perlu mengingat dia di request berikutnya. Ada dua pendekatan umum. Session: server menyimpan data login dan memberi user sebuah ID lewat cookie. Token JWT: server memberi user token berisi data yang sudah ditandatangani, dan server tinggal memverifikasi tanda tangannya tanpa menyimpan apa pun.

Ketiga, masing-masing pendekatan punya konsekuensi soal logout, expiry, dan keamanan yang tidak bisa dijelaskan dua paragraf. Jadi kita tidak implement sekarang. Topik ini butuh bagian sendiri, dan enaknya dibahas setelah kita bisa menulis test. Kode auth tanpa test itu ngeri.

Bonus singkat: CORS

Satu lagi middleware yang cepat atau lambat kamu butuhkan. Kalau nanti API ini dipanggil dari frontend JavaScript yang berjalan di domain lain, misalnya localhost:3000 memanggil localhost:8080, browser akan memblokir responsnya. Ini kebijakan keamanan browser bernama same-origin policy. Supaya diizinkan, server harus mengirim header CORS yang menyatakan siapa boleh mengakses.

func cors(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Access-Control-Allow-Origin", "*")
        w.Header().Set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS")
        w.Header().Set("Access-Control-Allow-Headers", "Content-Type, X-API-Key")
        if r.Method == http.MethodOptions {
            w.WriteHeader(http.StatusNoContent)
            return
        }
        next.ServeHTTP(w, r)
    })
}

Tanda * berarti semua domain boleh. Untuk produksi, ganti dengan domain frontend kamu. Detail CORS panjang, tapi bentuk middleware-nya sama saja dengan yang sudah kita pelajari.

Program utuh

Sekarang kita gabungkan semuanya dengan API produk dari bagian 12. Struktur handler tidak berubah, kita hanya menambah lapisan di depannya.

package main

import (
    "database/sql"
    "encoding/json"
    "log"
    "net/http"
    "os"
    "time"

    _ "github.com/go-sql-driver/mysql"
)

type Produk struct {
    ID    int    `json:"id"`
    Nama  string `json:"nama"`
    Harga int    `json:"harga"`
}

var db *sql.DB

func logging(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        mulai := time.Now()
        next.ServeHTTP(w, r)
        log.Printf("%s %s selesai dalam %v", r.Method, r.URL.Path, time.Since(mulai))
    })
}

func cekAPIKey(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        kunci := os.Getenv("API_KEY")
        if kunci == "" || r.Header.Get("X-API-Key") != kunci {
            w.Header().Set("Content-Type", "application/json")
            w.WriteHeader(http.StatusUnauthorized)
            json.NewEncoder(w).Encode(map[string]string{"error": "API key salah atau tidak ada"})
            return
        }
        next.ServeHTTP(w, r)
    })
}

func listProduk(w http.ResponseWriter, r *http.Request) {
    rows, err := db.Query("SELECT id, nama, harga FROM produk")
    if err != nil {
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }
    defer rows.Close()

    produk := []Produk{}
    for rows.Next() {
        var p Produk
        if err := rows.Scan(&p.ID, &p.Nama, &p.Harga); err != nil {
            http.Error(w, err.Error(), http.StatusInternalServerError)
            return
        }
        produk = append(produk, p)
    }

    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(produk)
}

func tambahProduk(w http.ResponseWriter, r *http.Request) {
    var p Produk
    if err := json.NewDecoder(r.Body).Decode(&p); err != nil {
        http.Error(w, "body tidak valid", http.StatusBadRequest)
        return
    }

    hasil, err := db.Exec("INSERT INTO produk (nama, harga) VALUES (?, ?)", p.Nama, p.Harga)
    if err != nil {
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }

    id, _ := hasil.LastInsertId()
    p.ID = int(id)

    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(http.StatusCreated)
    json.NewEncoder(w).Encode(p)
}

func main() {
    var err error
    db, err = sql.Open("mysql", os.Getenv("DSN"))
    if err != nil {
        log.Fatal(err)
    }
    if err := db.Ping(); err != nil {
        log.Fatal(err)
    }

    mux := http.NewServeMux()
    mux.HandleFunc("GET /produk", listProduk)
    mux.Handle("POST /produk", cekAPIKey(http.HandlerFunc(tambahProduk)))

    log.Println("Server jalan di :8080")
    log.Fatal(http.ListenAndServe(":8080", logging(mux)))
}

Jalankan dengan environment variable yang lengkap:

export DSN="root:passwordmu@tcp(127.0.0.1:3306)/belajar_golang"
export API_KEY="rahasia-123"
go run main.go

Uji dengan curl

Coba POST tanpa API key dulu:

curl -i -X POST http://localhost:8080/produk \
  -H "Content-Type: application/json" \
  -d '{"nama":"Kopi Arabika","harga":85000}'

Responsnya ditolak:

HTTP/1.1 401 Unauthorized
Content-Type: application/json

{"error":"API key salah atau tidak ada"}

Sekarang ulangi dengan header X-API-Key:

curl -i -X POST http://localhost:8080/produk \
  -H "Content-Type: application/json" \
  -H "X-API-Key: rahasia-123" \
  -d '{"nama":"Kopi Arabika","harga":85000}'

Kali ini berhasil:

HTTP/1.1 201 Created
Content-Type: application/json

{"id":4,"nama":"Kopi Arabika","harga":85000}

Sementara itu GET /produk tetap bisa diakses siapa saja tanpa header apa pun. Dan di terminal server, setiap request tercatat rapi oleh middleware logging.

Penutup

API produk kita sekarang punya satpam. Logging mencatat semua tamu, API key menjaga pintu operasi tulis, dan tidak ada satu pun kode pengecekan yang di-copy paste antar handler. Kamu juga sudah paham kenapa pola func(http.Handler) http.Handler bisa dirangkai, dan kapan API key cukup serta kapan butuh auth yang lebih serius.

Tapi jujur saja, dari bagian 11 sampai sekarang kita mengetes API cuma lewat curl dan mata. Begitu kode makin panjang, cara itu tidak bisa diandalkan. Di bagian 14 kita bahas “Testing di Go: Menguji Function dan Handler API” supaya setiap perubahan bisa diverifikasi otomatis.

Kalau kamu sedang membangun API atau sistem internal untuk bisnis dan butuh bantuan yang serius, tim kami di Arrazy Inovasi menyediakan jasa pembuatan sistem aplikasi dari perancangan sampai deployment.

Di Belajar Golang dari Nol #11 kita sudah membuat REST API produk yang berjalan. Handler-nya rapi, JSON-nya jalan, endpoint-nya lengkap. Tapi ada satu masalah besar yang sengaja saya tunda. Data produk disimpan di slice, alias di memory. Begitu server dimatikan atau restart, semua data hilang. Di bagian ini kita selesaikan masalah itu. Kita sambungkan API ke database sungguhan pakai package standar database/sql.

Kenapa Harus Database

Menyimpan data di slice itu cukup untuk belajar. Untuk aplikasi nyata, tidak. Ada tiga alasan utama kenapa kita butuh database.

• Data bertahan setelah restart. Database menyimpan data ke file di disk, bukan ke RAM. Server mati, data tetap ada.
• Data bisa dicari dan difilter. Mau cari produk dengan stok di bawah 5? Satu query selesai. Kalau pakai slice, Anda harus tulis loop sendiri setiap kali.
• Aman diakses banyak proses. Database dirancang untuk menangani banyak koneksi sekaligus. Urusan lock dan konsistensi sudah diurus di level database.

Di Go, akses database lewat package database/sql. Package ini menarik karena isinya hampir semuanya interface, materi yang sudah kita bahas di bagian 9. database/sql hanya mendefinisikan kontrak: cara buka koneksi, cara kirim query, cara baca hasil. Implementasi aslinya disediakan oleh driver, yaitu package terpisah yang tahu cara bicara dengan database tertentu. Satu kontrak, banyak implementasi. Kode Anda relatif sama mau databasenya apa pun.

Di tutorial ini kita pakai SQLite lewat driver modernc.org/sqlite. Alasannya praktis. SQLite menyimpan seluruh database dalam satu file, jadi Anda tidak perlu install dan menjalankan server database apa pun. Polanya persis sama untuk MySQL atau PostgreSQL, tinggal ganti driver dan connection string-nya.

Install Driver dan Buka Koneksi

Masuk ke folder proyek API dari bagian 11, lalu install driver.

go get modernc.org/sqlite

Driver ini ditulis murni dalam Go, jadi tidak butuh compiler C. Sekarang buka koneksi di main.go.

package main

import (
	"database/sql"
	"log"

	_ "modernc.org/sqlite"
)

var db *sql.DB

func main() {
	var err error
	db, err = sql.Open("sqlite", "toko.db")
	if err != nil {
		log.Fatal(err)
	}
	defer db.Close()

	if err := db.Ping(); err != nil {
		log.Fatal("gagal konek ke database:", err)
	}

	log.Println("database siap")
}

Ada dua hal yang perlu diperhatikan di sini. Pertama, import driver pakai underscore. Kita tidak memanggil fungsi apa pun dari package itu secara langsung. Import dengan underscore hanya menjalankan kode registrasinya, sehingga driver mendaftarkan diri ke database/sql dengan nama sqlite. Nama itulah yang kita pakai sebagai argumen pertama sql.Open.

Kedua, sql.Open tidak langsung membuat koneksi. Fungsi ini hanya menyiapkan objek *sql.DB dan memvalidasi argumennya. Koneksi sebenarnya baru dibuat saat dibutuhkan. Karena itu kita panggil db.Ping() untuk memaksa satu koneksi terbentuk. Kalau file database tidak bisa dibuat atau konfigurasi salah, kita tahu sejak awal, bukan saat request pertama masuk.

Membuat Tabel

SQLite akan membuat file toko.db otomatis saat pertama diakses. Tapi tabelnya harus kita buat sendiri. Untuk perintah SQL yang tidak mengembalikan baris data, pakai db.Exec.

func buatTabel() error {
	_, err := db.Exec(`CREATE TABLE IF NOT EXISTS produk (
		id INTEGER PRIMARY KEY AUTOINCREMENT,
		nama TEXT,
		harga REAL,
		stok INTEGER
	)`)
	return err
}

Klausa IF NOT EXISTS membuat fungsi ini aman dipanggil berulang. Tabel hanya dibuat sekali, panggilan berikutnya tidak melakukan apa-apa. Kolom id memakai AUTOINCREMENT, jadi database yang mengurus penomoran. Anda tidak perlu lagi menghitung ID sendiri seperti di bagian 11. Panggil buatTabel() di main tepat setelah db.Ping() berhasil.

INSERT dan Bahaya SQL Injection

Menyimpan data juga pakai db.Exec. Perhatikan tanda tanya di dalam query.

hasil, err := db.Exec(
	"INSERT INTO produk (nama, harga, stok) VALUES (?, ?, ?)",
	"Kopi Arabika", 45000, 10,
)
if err != nil {
	log.Fatal(err)
}

id, _ := hasil.LastInsertId()
log.Println("produk tersimpan dengan id", id)

Tanda tanya itu namanya placeholder. Nilai aslinya dikirim terpisah dari teks query, lalu database yang menggabungkannya dengan aman. Ini bukan sekadar gaya penulisan. Ini keharusan.

Bandingkan dengan cara yang salah: menggabungkan input user langsung ke string query.

// JANGAN PERNAH seperti ini
query := "SELECT * FROM produk WHERE nama = '" + input + "'"

Kelihatannya jalan. Sampai ada user iseng yang mengirim input berisi ' OR '1'='1. Query yang sampai ke database berubah menjadi SELECT * FROM produk WHERE nama = '' OR '1'='1'. Kondisi '1'='1' selalu benar, jadi semua baris ikut terambil. Dengan input yang lebih jahat, penyerang bisa menghapus tabel atau membaca data user lain. Teknik ini namanya SQL injection, dan sampai sekarang masih jadi salah satu celah keamanan paling umum di dunia. Dengan placeholder, input tadi diperlakukan murni sebagai teks biasa, bukan bagian dari perintah SQL. Serangannya mati sebelum sempat jalan.

Membaca Data: Query dan QueryRow

Untuk mengambil banyak baris, pakai db.Query. Hasilnya berupa *sql.Rows yang kita telusuri satu per satu.

func ambilSemuaProduk() ([]Produk, error) {
	rows, err := db.Query("SELECT id, nama, harga, stok FROM produk")
	if err != nil {
		return nil, err
	}
	defer rows.Close()

	var daftar []Produk
	for rows.Next() {
		var p Produk
		if err := rows.Scan(&p.ID, &p.Nama, &p.Harga, &p.Stok); err != nil {
			return nil, err
		}
		daftar = append(daftar, p)
	}
	return daftar, rows.Err()
}

Alurnya selalu sama. rows.Next() maju ke baris berikutnya dan mengembalikan false saat baris habis. rows.Scan menyalin nilai kolom ke variabel Anda, urutannya harus cocok dengan urutan kolom di SELECT. Dan defer rows.Close() wajib ada. Tanpa itu, koneksi database tertahan terus dan lama-lama aplikasi kehabisan koneksi. Terakhir, rows.Err() menangkap error yang mungkin terjadi di tengah iterasi.

Untuk mengambil tepat satu baris, ada jalur yang lebih pendek: QueryRow.

func ambilProdukByID(id int) (Produk, error) {
	var p Produk
	err := db.QueryRow(
		"SELECT id, nama, harga, stok FROM produk WHERE id = ?", id,
	).Scan(&p.ID, &p.Nama, &p.Harga, &p.Stok)
	return p, err
}

Kalau tidak ada baris yang cocok, Scan mengembalikan error khusus bernama sql.ErrNoRows. Error ini bukan tanda ada yang rusak. Artinya cuma satu: datanya memang tidak ada. Nanti di handler, error inilah yang kita terjemahkan menjadi respons 404.

UPDATE dan DELETE

Keduanya memakai db.Exec, sama seperti INSERT. Yang menarik adalah cara mengecek apakah perintahnya benar-benar mengubah sesuatu.

hasil, err := db.Exec(
	"UPDATE produk SET stok = ? WHERE id = ?", 25, 3,
)
if err != nil {
	log.Fatal(err)
}

jumlah, _ := hasil.RowsAffected()
if jumlah == 0 {
	log.Println("tidak ada produk dengan id itu")
}

UPDATE ke ID yang tidak ada itu bukan error di mata database. Query-nya valid, hanya saja tidak ada baris yang kena. Karena itu kita cek RowsAffected(). Nol artinya tidak ada yang berubah, dan di API biasanya itu diterjemahkan jadi 404. DELETE polanya persis sama.

hasil, err := db.Exec("DELETE FROM produk WHERE id = ?", 3)

Menyambungkan ke API Bagian 11

Sekarang bagian yang ditunggu. Kita ganti penyimpanan slice di API bagian 11 dengan database. Tiga fungsi tadi, ambilSemuaProduk, ambilProdukByID, dan satu lagi simpanProduk di bawah ini, jadi satu-satunya tempat kode SQL berada.

func simpanProduk(p Produk) (int64, error) {
	hasil, err := db.Exec(
		"INSERT INTO produk (nama, harga, stok) VALUES (?, ?, ?)",
		p.Nama, p.Harga, p.Stok,
	)
	if err != nil {
		return 0, err
	}
	return hasil.LastInsertId()
}

Memisahkan akses database ke fungsi sendiri seperti ini adalah kebiasaan yang layak dipelihara sejak awal. Handler jadi fokus mengurus HTTP: baca request, panggil fungsi data, tulis respons. Fungsi data fokus mengurus SQL. Kalau suatu hari pindah dari SQLite ke PostgreSQL, yang berubah hanya lapisan fungsi data, handler tidak tersentuh. Di dunia kerja pola ini punya nama sendiri, tapi intinya sesederhana itu: satu lapisan, satu tanggung jawab.

Berikut tiga handler yang berubah. Routing, struct Produk, dan sisanya tetap sama seperti bagian 11, jadi tidak saya ulang.

func handleDaftarProduk(w http.ResponseWriter, r *http.Request) {
	daftar, err := ambilSemuaProduk()
	if err != nil {
		http.Error(w, "gagal membaca data", http.StatusInternalServerError)
		return
	}
	w.Header().Set("Content-Type", "application/json")
	json.NewEncoder(w).Encode(daftar)
}

func handleDetailProduk(w http.ResponseWriter, r *http.Request) {
	id, err := strconv.Atoi(r.PathValue("id"))
	if err != nil {
		http.Error(w, "id tidak valid", http.StatusBadRequest)
		return
	}

	p, err := ambilProdukByID(id)
	if errors.Is(err, sql.ErrNoRows) {
		http.Error(w, "produk tidak ditemukan", http.StatusNotFound)
		return
	}
	if err != nil {
		http.Error(w, "gagal membaca data", http.StatusInternalServerError)
		return
	}

	w.Header().Set("Content-Type", "application/json")
	json.NewEncoder(w).Encode(p)
}

Perhatikan urutan pengecekan error. sql.ErrNoRows dicek dulu pakai errors.Is, materi error dari bagian sebelumnya, lalu diterjemahkan jadi 404. Error lain berarti ada masalah di sisi server, jadi 500.

func handleTambahProduk(w http.ResponseWriter, r *http.Request) {
	var p Produk
	if err := json.NewDecoder(r.Body).Decode(&p); err != nil {
		http.Error(w, "body tidak valid", http.StatusBadRequest)
		return
	}

	id, err := simpanProduk(p)
	if err != nil {
		http.Error(w, "gagal menyimpan data", http.StatusInternalServerError)
		return
	}
	p.ID = int(id)

	w.Header().Set("Content-Type", "application/json")
	w.WriteHeader(http.StatusCreated)
	json.NewEncoder(w).Encode(p)
}

Ada bonus yang enak di refactor ini. Mutex dari bagian 11 boleh dihapus. Objek *sql.DB memang dirancang aman dipakai banyak goroutine sekaligus, lengkap dengan connection pool di dalamnya. Satu kerumitan hilang.

Satu catatan kecil untuk nanti. Setiap fungsi di atas punya versi ber-context: QueryContext, ExecContext, dan kawan-kawannya. Context berguna untuk membatalkan query yang kelamaan, misalnya saat client keburu menutup koneksi. Kita bahas layak-layaknya di bagian lanjutan, sekarang cukup tahu dulu bahwa versi itu ada.

Uji Coba: Momen Kemenangannya

Jalankan server, lalu tambah produk lewat curl.

go run .

curl -X POST http://localhost:8080/produk \
  -H "Content-Type: application/json" \
  -d '{"nama":"Teh Melati","harga":12000,"stok":30}'

Cek daftarnya.

curl http://localhost:8080/produk

Produk muncul. Sekarang bagian pentingnya. Matikan server dengan Ctrl+C. Di bagian 11, langkah ini menghapus semua data. Jalankan lagi go run ., lalu panggil endpoint daftar sekali lagi.

curl http://localhost:8080/produk

Datanya masih ada. Teh Melati tetap di sana, lengkap dengan ID-nya. Inilah bedanya API mainan dan API yang bisa dipakai sungguhan. Semua tersimpan di file toko.db, dan Anda bisa buka file itu kapan saja pakai tool SQLite mana pun.

Rangkuman dan Bagian Selanjutnya

Hari ini Anda belajar banyak hal penting. database/sql sebagai interface standar dan driver sebagai implementasinya. sql.Open yang ternyata tidak langsung konek, sehingga perlu Ping. Exec untuk perintah tulis, Query dan QueryRow untuk baca, Scan untuk menyalin hasil, RowsAffected untuk memastikan ada yang berubah. Plus satu aturan yang tidak boleh ditawar: selalu pakai placeholder, jangan pernah menyambung input user ke string SQL.

API Anda sekarang punya ingatan permanen. Tapi siapa pun masih bisa menambah dan menghapus produk seenaknya. Itu masalah berikutnya. Di bagian 13 kita bahas Middleware dan Auth Sederhana untuk API.

Kalau Anda sedang butuh aplikasi bisnis yang datanya rapi dan tidak hilang-hilangan, tim kami juga mengerjakan pengembangan sistem aplikasi dari desain database sampai API-nya.

Di Belajar Golang dari Nol #10 kamu sudah kenal goroutine dan channel. Materi itu terasa abstrak buat sebagian orang. Hari ini abstraksi itu langsung kepakai. Kita akan membuat REST API pertamamu dengan package bawaan Go, yaitu net/http. Tanpa framework, tanpa library tambahan. Di akhir artikel, kamu punya API produk mini yang bisa diakses lewat curl, browser, atau aplikasi frontend.

Apa itu REST API

Bayangkan kamu bikin aplikasi kasir. Ada aplikasi Android untuk pelayan, ada dashboard web untuk pemilik toko. Dua aplikasi itu butuh data yang sama: daftar produk, harga, stok. Data itu tidak disimpan di HP pelayan atau di browser pemilik. Data itu ada di satu tempat, yaitu backend. Nah, REST API adalah cara aplikasi lain ngobrol dengan backendmu. Mereka kirim permintaan lewat HTTP, backendmu balas dengan data dalam format JSON. Frontend minta “kasih daftar produk”, backend jawab dengan array JSON berisi produk. Sesederhana itu konsepnya.

Kenapa ini penting buat kamu yang lagi belajar Go? Karena hampir semua lowongan backend developer intinya ya ini: membuat dan merawat API. Login, checkout, notifikasi, laporan, semuanya jalan lewat API. Kalau kamu paham cara menerima request, memproses data, dan mengembalikan JSON dengan status code yang benar, kamu sudah pegang gerbang masuk dunia kerja backend. Sisanya tinggal memperdalam.

Server HTTP Pertamamu

Kita mulai dari yang paling kecil. Buat folder baru, jalankan go mod init belajar-api, lalu buat file main.go:

package main

import (
	"fmt"
	"net/http"
)

func main() {
	http.HandleFunc("GET /produk", func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintln(w, "daftar produk")
	})

	fmt.Println("Server jalan di http://localhost:8080")
	http.ListenAndServe(":8080", nil)
}

Ada dua pemain utama di sini. Pertama, http.HandleFunc mendaftarkan handler, yaitu function yang dipanggil setiap ada request masuk ke pola tertentu. Pola "GET /produk" artinya handler ini hanya melayani request GET ke path /produk. Kedua, http.ListenAndServe(":8080", nil) menyalakan server di port 8080 dan membuatnya menunggu request terus menerus. Program tidak akan berhenti sendiri, dan memang itu yang kita mau.

Setiap handler menerima dua parameter. w http.ResponseWriter adalah tempat kamu menulis balasan. r *http.Request berisi semua detail request yang masuk: method, path, header, dan body. Perhatikan juga, r di sini pointer. Materi pointer di bagian 7 kepakai lagi.

Jalankan dengan go run main.go, lalu buka terminal kedua dan tes dengan curl:

curl http://localhost:8080/produk

Hasilnya:

daftar produk

Selamat, kamu baru saja membuat web server. Serius, itu saja kodenya. Go memang menyertakan HTTP server production-grade di standard library.

Kalau muncul error address already in use, artinya port 8080 sedang dipakai program lain. Matikan program itu, atau ganti port di kodemu jadi ":8081" misalnya. Kamu juga bisa tes lewat browser dengan membuka http://localhost:8080/produk, karena browser mengirim request GET secara default. Untuk POST nanti kita tetap butuh curl.

Membalas dengan JSON

Teks polos tidak berguna buat frontend. Mereka butuh JSON. Di Go, cara paling umum adalah mendefinisikan struct, lalu meng-encode struct itu jadi JSON dengan package encoding/json:

type Produk struct {
	ID    int    `json:"id"`
	Nama  string `json:"nama"`
	Harga int    `json:"harga"`
}

Bagian `json:"nama"` disebut struct tag. Tag ini memberi tahu package encoding/json: saat struct ini diubah jadi JSON, pakai nama field nama, bukan Nama. Tanpa tag, field akan tampil persis seperti nama di struct, huruf besar di depan. Konvensi JSON umumnya huruf kecil, jadi tag ini hampir selalu dipakai. Ingat juga aturan dari bagian 4: field harus diawali huruf besar supaya terlihat oleh package lain, termasuk encoding/json. Field huruf kecil akan diabaikan diam diam.

Sekarang ubah handler kita supaya membalas JSON:

http.HandleFunc("GET /produk", func(w http.ResponseWriter, r *http.Request) {
	daftar := []Produk{
		{ID: 1, Nama: "Kopi Arabika", Harga: 45000},
		{ID: 2, Nama: "Teh Melati", Harga: 20000},
	}

	w.Header().Set("Content-Type", "application/json")
	json.NewEncoder(w).Encode(daftar)
})

Dua hal baru. w.Header().Set("Content-Type", "application/json") memberi tahu klien bahwa isi balasan adalah JSON, bukan teks biasa. Banyak library frontend bergantung pada header ini untuk mem-parsing respons secara otomatis. Lalu json.NewEncoder(w).Encode(daftar) mengubah slice kita jadi JSON dan langsung menulisnya ke respons. Praktis, satu baris selesai. Jangan lupa tambahkan "encoding/json" di import.

Tes lagi dengan curl, hasilnya sudah JSON:

[{"id":1,"nama":"Kopi Arabika","harga":45000},{"id":2,"nama":"Teh Melati","harga":20000}]

Routing dengan Method dan Path Parameter

Sejak Go 1.22, router bawaan (ServeMux) jadi jauh lebih enak dipakai. Kamu bisa menulis method langsung di pola, dan bisa menangkap bagian path yang dinamis:

http.HandleFunc("GET /produk", listProduk)
http.HandleFunc("POST /produk", tambahProduk)
http.HandleFunc("GET /produk/{id}", detailProduk)

Di sinilah gaya REST mulai terlihat. Konvensinya sederhana: method HTTP menentukan jenis aksinya. GET untuk membaca data, POST untuk membuat data baru, PUT untuk mengubah, DELETE untuk menghapus. Path-nya menunjuk ke sumber datanya, biasanya kata benda jamak seperti /produk atau /pelanggan. Jadi kamu tidak perlu bikin path seperti /ambilSemuaProduk atau /hapusProdukById. Kombinasi method dan path sudah cukup menjelaskan maksudnya, dan developer lain langsung paham tanpa baca dokumentasi panjang.

Tiga baris ini artinya: GET ke /produk masuk ke listProduk, POST ke path yang sama masuk ke tambahProduk, dan GET ke /produk/5 masuk ke detailProduk. Bagian {id} disebut path parameter. Di dalam handler, nilainya diambil dengan r.PathValue("id"):

func detailProduk(w http.ResponseWriter, r *http.Request) {
	id := r.PathValue("id") // untuk /produk/5, id berisi "5"
	// ...
}

Nilai yang dikembalikan selalu string, jadi kalau butuh angka kamu konversi dulu dengan strconv.Atoi. Satu catatan: di Go versi lama sebelum 1.22, pola method dan {id} belum ada, jadi orang mengecek r.Method manual atau pakai router pihak ketiga seperti chi dan gorilla/mux. Pastikan saja Go kamu minimal 1.22, cek dengan go version.

Menerima Data Lewat POST

GET dipakai untuk membaca data. POST dipakai untuk mengirim data baru. Data dari klien dikirim lewat body request dalam bentuk JSON, dan tugas kita membacanya dengan json.NewDecoder:

func tambahProduk(w http.ResponseWriter, r *http.Request) {
	var p Produk
	if err := json.NewDecoder(r.Body).Decode(&p); err != nil {
		w.Header().Set("Content-Type", "application/json")
		w.WriteHeader(http.StatusBadRequest)
		json.NewEncoder(w).Encode(map[string]string{"error": "body bukan JSON yang valid"})
		return
	}

	if p.Nama == "" || p.Harga <= 0 {
		w.Header().Set("Content-Type", "application/json")
		w.WriteHeader(http.StatusBadRequest)
		json.NewEncoder(w).Encode(map[string]string{"error": "nama wajib diisi dan harga harus lebih dari 0"})
		return
	}

	// simpan datanya, lalu balas 201
	w.Header().Set("Content-Type", "application/json")
	w.WriteHeader(http.StatusCreated)
	json.NewEncoder(w).Encode(p)
}

Polanya kebalikan dari encoder tadi. json.NewDecoder(r.Body).Decode(&p) membaca body request dan mengisi struct p. Kita kirim pointer supaya function bisa mengubah isi struct aslinya, persis seperti yang kamu pelajari di bagian pointer. Kalau body-nya bukan JSON yang valid, Decode mengembalikan error dan kita hentikan proses di situ.

Setelah decode berhasil, jangan langsung percaya datanya. Klien bisa saja kirim nama kosong atau harga minus. Validasi sederhana seperti di atas sudah cukup untuk tahap ini.

Perhatikan juga w.WriteHeader. Ini cara kita menentukan status code respons. Status code itu bahasa universal HTTP. http.StatusCreated (201) artinya data berhasil dibuat. http.StatusBadRequest (400) artinya request-nya bermasalah dari sisi klien. Kenapa penting? Karena frontend mengambil keputusan berdasarkan angka ini. Kalau semua respons kamu 200 padahal isinya error, frontend harus menebak-nebak dari isi body, dan itu resep bug. Status yang benar bikin API-mu jujur dan mudah dipakai orang lain.

Menyimpan Data di Memory, dan Kenapa Butuh Mutex

API kita butuh tempat menyimpan produk. Untuk sekarang, kita pakai slice biasa yang hidup di memory. Tapi ada satu jebakan. Ingat pelajaran bagian 10: server HTTP di Go menjalankan setiap request di goroutine terpisah. Kalau dua request POST datang bersamaan, dua goroutine bisa menulis ke slice yang sama di saat yang sama. Itu race condition, dan hasilnya data bisa rusak. Solusinya sync.Mutex: kunci dulu sebelum menyentuh data, lepas setelah selesai. Satu goroutine masuk, yang lain antre.

Di program utuh nanti, kamu akan lihat polanya selalu sama: mu.Lock() di awal, lalu defer mu.Unlock() tepat di bawahnya. Pakai defer supaya kunci pasti dilepas saat function selesai, lewat jalur mana pun function itu keluar. Lupa melepas kunci akibatnya fatal, semua request berikutnya menggantung menunggu kunci yang tidak pernah dilepas.

Satu kejujuran penting: data di memory hilang setiap server restart. Kamu matikan program, semua produk yang ditambahkan lenyap. Untuk latihan ini tidak masalah. Penyimpanan permanen pakai database akan kita bahas di bagian 12.

Program Utuh: API Produk Mini

Sekarang kita rakit semuanya jadi satu file. API ini punya tiga endpoint: GET daftar produk, GET satu produk berdasarkan id (balas 404 kalau tidak ketemu), dan POST tambah produk. Supaya tidak mengulang kode, kita buat dua helper kecil untuk menulis respons:

package main

import (
	"encoding/json"
	"fmt"
	"net/http"
	"strconv"
	"sync"
)

type Produk struct {
	ID    int    `json:"id"`
	Nama  string `json:"nama"`
	Harga int    `json:"harga"`
}

var (
	mu     sync.Mutex
	produk = []Produk{
		{ID: 1, Nama: "Kopi Arabika", Harga: 45000},
		{ID: 2, Nama: "Teh Melati", Harga: 20000},
	}
	nextID = 3
)

func tulisJSON(w http.ResponseWriter, status int, data any) {
	w.Header().Set("Content-Type", "application/json")
	w.WriteHeader(status)
	json.NewEncoder(w).Encode(data)
}

func tulisError(w http.ResponseWriter, status int, pesan string) {
	tulisJSON(w, status, map[string]string{"error": pesan})
}

func listProduk(w http.ResponseWriter, r *http.Request) {
	mu.Lock()
	defer mu.Unlock()
	tulisJSON(w, http.StatusOK, produk)
}

func detailProduk(w http.ResponseWriter, r *http.Request) {
	id, err := strconv.Atoi(r.PathValue("id"))
	if err != nil {
		tulisError(w, http.StatusBadRequest, "id harus angka")
		return
	}

	mu.Lock()
	defer mu.Unlock()
	for _, p := range produk {
		if p.ID == id {
			tulisJSON(w, http.StatusOK, p)
			return
		}
	}
	tulisError(w, http.StatusNotFound, "produk tidak ditemukan")
}

func tambahProduk(w http.ResponseWriter, r *http.Request) {
	var p Produk
	if err := json.NewDecoder(r.Body).Decode(&p); err != nil {
		tulisError(w, http.StatusBadRequest, "body bukan JSON yang valid")
		return
	}
	if p.Nama == "" || p.Harga <= 0 {
		tulisError(w, http.StatusBadRequest, "nama wajib diisi dan harga harus lebih dari 0")
		return
	}

	mu.Lock()
	defer mu.Unlock()
	p.ID = nextID
	nextID++
	produk = append(produk, p)
	tulisJSON(w, http.StatusCreated, p)
}

func main() {
	http.HandleFunc("GET /produk", listProduk)
	http.HandleFunc("GET /produk/{id}", detailProduk)
	http.HandleFunc("POST /produk", tambahProduk)

	fmt.Println("Server jalan di http://localhost:8080")
	http.ListenAndServe(":8080", nil)
}

Jalankan dengan go run main.go, lalu tes ketiga endpoint. Pertama, ambil daftar produk:

curl http://localhost:8080/produk

[{"id":1,"nama":"Kopi Arabika","harga":45000},{"id":2,"nama":"Teh Melati","harga":20000}]

Kedua, ambil satu produk. Coba id yang ada dan yang tidak ada:

curl http://localhost:8080/produk/1

{"id":1,"nama":"Kopi Arabika","harga":45000}

curl http://localhost:8080/produk/99

{"error":"produk tidak ditemukan"}

Ketiga, tambah produk baru lewat POST. Flag -X POST menentukan method, -d mengisi body:

curl -X POST http://localhost:8080/produk \
  -H "Content-Type: application/json" \
  -d '{"nama":"Gula Aren","harga":15000}'

{"id":3,"nama":"Gula Aren","harga":15000}

Panggil lagi GET /produk, dan Gula Aren sudah muncul di daftar. API-mu hidup dan datanya nyambung antar endpoint.

Satu Kebiasaan Baik: Struktur Respons yang Konsisten

Perhatikan satu detail dari program di atas. Semua respons kita JSON, termasuk saat error. Sukses balas data, gagal balas {"error": "..."}. Klien jadi selalu tahu format apa yang akan diterima, apa pun hasilnya. Kebiasaan kecil ini membedakan API yang enak dipakai dengan API yang bikin frontend developer mengelus dada. Pertahankan sejak proyek pertamamu.

Penutup

Hari ini kamu sudah membuat REST API lengkap hanya dengan standard library: server HTTP, routing dengan method dan path parameter, encode dan decode JSON, validasi input, status code yang benar, plus mutex supaya aman dari race condition. Coba modifikasi sendiri sebagai latihan, misalnya tambah endpoint DELETE /produk/{id} atau field stok di struct Produk.

Masalah yang tersisa jelas: data hilang saat server restart. Di bagian 12, “Menghubungkan API ke Database dengan database/sql”, kita selesaikan itu dengan menyimpan produk ke database sungguhan. Pola API seperti inilah yang kami pakai sehari hari saat membangun sistem aplikasi untuk bisnis dan instansi, jadi kuasai dasarnya baik baik. Sampai ketemu di bagian 12.

Selamat datang lagi. Di Belajar Golang dari Nol #9 kita sudah kenalan dengan interface, cara Go membuat kode jadi fleksibel. Sampai bagian itu, semua program yang kita tulis berjalan satu jalur. Baris pertama selesai dulu, baru baris berikutnya jalan. Kali ini kita belajar hal yang membuat Go terkenal: menjalankan banyak pekerjaan sekaligus. Namanya concurrency.

Bayangkan Antrean di Minimarket

Bayangkan minimarket dengan satu kasir. Ada sepuluh pembeli mengantre. Kasir melayani satu per satu. Pembeli kesepuluh harus menunggu sembilan orang di depannya. Ini yang disebut sequential. Satu pekerjaan selesai, baru pekerjaan berikutnya mulai.

Sekarang bayangkan minimarket itu membuka tiga kasir. Antrean terpecah. Sepuluh pembeli selesai jauh lebih cepat. Ini gambaran concurrent. Beberapa pekerjaan berjalan dalam waktu yang beririsan.

Program kita juga sering menghadapi antrean seperti ini. Ambil data dari database, panggil API pembayaran, kirim email notifikasi. Kalau semua dikerjakan bergiliran, pengguna menunggu lama. Go menyediakan cara yang sangat sederhana untuk membuka kasir tambahan. Inilah salah satu alasan besar kenapa perusahaan seperti Google, Uber, dan Gojek memilih Go untuk backend mereka.

Goroutine: Kasir Tambahan di Programmu

Goroutine adalah function yang berjalan bersamaan dengan function lain. Membuatnya gampang sekali. Cukup tambahkan kata go di depan pemanggilan function.

package main

import "fmt"

func sapa() {
	fmt.Println("Halo dari goroutine")
}

func main() {
	go sapa()
	fmt.Println("Main selesai")
}

Coba jalankan. Kemungkinan besar outputnya cuma satu baris:

Main selesai

Tulisan dari sapa tidak muncul sama sekali. Kenapa?

Function main sendiri sebenarnya juga goroutine. Namanya main goroutine. Saat main selesai, program langsung berhenti. Semua goroutine lain ikut mati, tidak peduli sudah sempat jalan atau belum. Di contoh tadi, go sapa() hanya menitipkan pekerjaan. Main tidak menunggu. Dia lanjut ke baris berikutnya, mencetak “Main selesai”, lalu program tutup. Goroutine sapa belum sempat kebagian giliran.

Kalau pakai analogi kasir: kamu membuka kasir kedua, tapi sebelum kasirnya sempat melayani siapa pun, tokonya sudah kamu tutup.

Menunggu dengan sync.WaitGroup

Kita butuh cara untuk bilang ke main: tunggu dulu, masih ada pekerjaan yang belum selesai. Alat paling umum untuk itu adalah sync.WaitGroup. Cara pakainya tiga langkah:

• Add(1) dipanggil setiap kali kamu menitipkan satu pekerjaan
• Done() dipanggil goroutine saat pekerjaannya selesai
• Wait() membuat main menunggu sampai hitungannya kembali nol

Biar manfaatnya terasa, kita simulasikan mengunduh tiga data. Setiap unduhan kita anggap butuh dua detik, ditiru dengan time.Sleep. Versi sekuensial dulu.

package main

import (
	"fmt"
	"time"
)

func unduhData(nama string) {
	fmt.Println("Mulai mengunduh", nama)
	time.Sleep(2 * time.Second)
	fmt.Println("Selesai mengunduh", nama)
}

func main() {
	mulai := time.Now()

	unduhData("laporan.pdf")
	unduhData("foto.zip")
	unduhData("video.mp4")

	fmt.Println("Total waktu:", time.Since(mulai))
}

Total waktunya sekitar enam detik. Wajar. Tiga pekerjaan, masing-masing dua detik, dikerjakan bergiliran seperti satu kasir melayani tiga pembeli. Sekarang versi concurrent.

package main

import (
	"fmt"
	"sync"
	"time"
)

func unduhData(nama string, wg *sync.WaitGroup) {
	defer wg.Done()
	fmt.Println("Mulai mengunduh", nama)
	time.Sleep(2 * time.Second)
	fmt.Println("Selesai mengunduh", nama)
}

func main() {
	mulai := time.Now()

	var wg sync.WaitGroup
	daftar := []string{"laporan.pdf", "foto.zip", "video.mp4"}

	for _, nama := range daftar {
		wg.Add(1)
		go unduhData(nama, &wg)
	}

	wg.Wait()
	fmt.Println("Total waktu:", time.Since(mulai))
}

Jalankan dan perhatikan angkanya. Total waktunya sekitar dua detik saja. Tiga unduhan berjalan bersamaan, seperti tiga kasir melayani tiga pembeli sekaligus. Perhatikan juga defer wg.Done(). Dengan defer, Done pasti terpanggil saat function berakhir, apa pun yang terjadi di tengah jalan.

Satu catatan. WaitGroup dikirim sebagai pointer, *sync.WaitGroup. Kamu sudah tahu alasannya dari bagian pointer. Kalau dikirim sebagai salinan, hitungan yang dipegang main tidak akan pernah berkurang, dan Wait() menunggu selamanya.

Channel: Jalur Kirim Data Antar Goroutine

Goroutine di atas hanya mencetak ke layar. Bagaimana kalau goroutine perlu mengirim hasil kerjanya kembali ke main? Jangan tergoda menulis ke variabel bersama. Cara yang aman di Go adalah channel.

Channel itu jalur serah terima data antar goroutine. Satu pihak menyerahkan, pihak lain menerima. Membuatnya pakai make, mengirim pakai panah ke arah channel, menerima pakai panah dari channel.

package main

import "fmt"

func main() {
	ch := make(chan string)

	go func() {
		ch <- "pesan dari goroutine"
	}()

	pesan := <-ch
	fmt.Println(pesan)
}

Ada satu sifat penting yang wajib kamu pahami: channel tanpa buffer bersifat blocking. Pengirim berhenti menunggu sampai ada yang menerima. Penerima juga berhenti menunggu sampai ada yang mengirim.

Bayangkan serah terima barang secara langsung. Kurir dan penerima harus sama-sama hadir. Kalau kurir datang dan rumah kosong, kurir menunggu di depan pintu. Kalau kamu menunggu di rumah dan kurir belum datang, ya kamu yang menunggu. Barang baru berpindah saat keduanya bertemu.

Sifat blocking ini pula yang membuat contoh di atas jalan tanpa WaitGroup. Baris pesan := <-ch menahan main sampai goroutine mengirim sesuatu.

Pola Worker: Hasil Kerja Mengalir Lewat Channel

Sekarang kita gabungkan. Satu goroutine bertugas memproses daftar pekerjaan, hasilnya dikirim satu per satu lewat channel. Main tinggal duduk manis menerima.

package main

import (
	"fmt"
	"strings"
)

func worker(tugas []string, hasil chan string) {
	for _, t := range tugas {
		hasil <- strings.ToUpper(t)
	}
	close(hasil)
}

func main() {
	tugas := []string{"laporan", "invoice", "surat jalan"}
	hasil := make(chan string)

	go worker(tugas, hasil)

	for h := range hasil {
		fmt.Println("Selesai diproses:", h)
	}
}

Ada dua hal baru di sini:

• close(hasil) menandakan pengiriman sudah selesai. Menutup channel adalah tugas pengirim, bukan penerima.
• for h := range hasil terus menerima dari channel sampai channel ditutup. Kalau lupa close, loop ini menunggu selamanya dan program berakhir deadlock.

Buffered Channel, Sekilas Saja

Channel biasa tidak punya ruang tunggu. Buffered channel punya. Kamu tentukan kapasitasnya saat membuat.

package main

import "fmt"

func main() {
	ch := make(chan string, 2)

	ch <- "pesanan pertama"
	ch <- "pesanan kedua"

	fmt.Println(<-ch)
	fmt.Println(<-ch)
}

Dengan kapasitas dua, pengirim bisa menaruh dua pesan tanpa menunggu penerima hadir. Pengirim baru terblokir saat buffernya penuh. Ini seperti loker paket di depan rumah. Kurir bisa titip barang lalu pergi, selama lokernya belum penuh.

Buffered channel berguna saat pengirim dan penerima bekerja dengan tempo berbeda, misalnya satu goroutine memproduksi data cepat dan penerimanya mencerna lebih lambat. Untuk sekarang, pakai channel tanpa buffer dulu sampai kamu menemukan alasan yang jelas.

select: Menunggu Beberapa Channel Sekaligus

select mirip switch, tapi khusus untuk channel. Dia menunggu, lalu memilih cabang yang channelnya lebih dulu siap. Pemakaian paling umum untuk pemula adalah timeout: kita hanya mau menunggu sampai batas waktu tertentu.

package main

import (
	"fmt"
	"time"
)

func main() {
	ch := make(chan string)

	go func() {
		time.Sleep(3 * time.Second)
		ch <- "data siap"
	}()

	select {
	case pesan := <-ch:
		fmt.Println(pesan)
	case <-time.After(2 * time.Second):
		fmt.Println("Kelamaan, kita batalkan saja")
	}
}

Goroutine butuh tiga detik, batas sabar kita dua detik. Jadi cabang time.After yang menang. time.After sendiri mengembalikan channel yang mengirim sinyal setelah durasi tertentu, cocok dipasangkan dengan select. Pola select masih banyak variasinya. Detailnya kita simpan untuk bagian lanjutan seri ini.

Peringatan: Jangan Tabur Goroutine di Semua Tempat

Goroutine memang ringan. Satu program Go bisa menjalankan ribuan goroutine tanpa masalah. Tapi bukan berarti semua kode harus dibuat concurrent. Kode sekuensial lebih mudah dibaca, lebih mudah dicari salahnya. Pakai goroutine saat memang ada yang layak dikerjakan bersamaan, misalnya beberapa panggilan jaringan yang saling bebas.

Bahaya paling umum di dunia concurrency namanya race condition. Ini terjadi saat dua goroutine atau lebih menulis ke variabel yang sama pada waktu beririsan. Hasilnya tidak bisa ditebak.

package main

import (
	"fmt"
	"sync"
)

func main() {
	var wg sync.WaitGroup
	counter := 0

	for i := 0; i < 1000; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			counter++
		}()
	}

	wg.Wait()
	fmt.Println("Counter:", counter)
}

Logikanya counter harus 1000. Coba jalankan beberapa kali. Angkanya sering meleset. Penyebabnya, counter++ sebenarnya tiga langkah: baca nilai, tambah satu, tulis balik. Saat dua goroutine melakukannya bersamaan, langkah mereka bisa saling menimpa.

Solusinya ada dua jalur: mengunci akses dengan mutex, atau mengubah desain supaya data mengalir lewat channel seperti contoh worker tadi. Keduanya akan kita bedah di kesempatan lain. Yang perlu kamu ingat sekarang, Go punya detektor bawaan. Jalankan programmu dengan go run -race main.go, dan Go akan melapor kalau menemukan race condition.

Latihan: Cek Harga dari Tiga Supplier

Saatnya latihan utuh. Skenarionya begini. Aplikasi gudangmu perlu membandingkan harga satu barang dari tiga supplier. Setiap supplier punya waktu respons berbeda, kita tiru dengan delay. Kalau dicek satu per satu, total waktunya adalah jumlah semua delay. Kita kerjakan secara concurrent, kumpulkan hasilnya lewat channel, lalu cari penawaran termurah.

package main

import (
	"fmt"
	"time"
)

type Penawaran struct {
	Supplier string
	Harga    int
}

func cekHarga(supplier string, harga int, delay time.Duration, hasil chan Penawaran) {
	time.Sleep(delay)
	hasil <- Penawaran{Supplier: supplier, Harga: harga}
}

func main() {
	mulai := time.Now()
	hasil := make(chan Penawaran)

	go cekHarga("Supplier A", 152000, 2*time.Second, hasil)
	go cekHarga("Supplier B", 148500, 1*time.Second, hasil)
	go cekHarga("Supplier C", 150000, 3*time.Second, hasil)

	var termurah Penawaran

	for i := 0; i < 3; i++ {
		p := <-hasil
		fmt.Printf("%s menawarkan Rp%d\n", p.Supplier, p.Harga)

		if termurah.Harga == 0 || p.Harga < termurah.Harga {
			termurah = p
		}
	}

	fmt.Printf("Termurah: %s dengan harga Rp%d\n", termurah.Supplier, termurah.Harga)
	fmt.Println("Total waktu:", time.Since(mulai))
}

Kalau dicek sekuensial, total delaynya enam detik. Versi concurrent ini selesai sekitar tiga detik, mengikuti supplier yang paling lambat. Tiga kasir bekerja, toko tutup begitu pembeli terakhir selesai.

Perhatikan juga urutan hasilnya. Supplier B muncul paling dulu karena delaynya paling pendek. Hasil dari channel datang sesuai siapa yang selesai duluan, bukan sesuai urutan pemanggilan. Kita menerima tepat tiga kali lewat loop, jadi tidak perlu close di sini karena jumlah datanya sudah pasti.

Untuk latihan mandiri: tambahkan supplier keempat, lalu coba pasang timeout dengan select supaya supplier yang jawabnya lebih dari dua detik dianggap gugur.

Rangkuman dan Lanjut ke Mana

Hari ini kamu sudah memegang dasar concurrency di Go:

• Kata go menjalankan function sebagai goroutine
• Main yang selesai duluan mematikan semua goroutine, jadi kita menunggu dengan sync.WaitGroup
• Channel adalah jalur serah terima data yang aman, sifat dasarnya blocking
• close dan range dipakai saat jumlah kiriman tidak pasti
• Buffered channel memberi ruang tunggu, select memilih channel yang siap duluan
• Race condition nyata, dan go run -race membantu menangkapnya

Materi ini akan langsung terpakai. Di bagian berikutnya, Belajar Golang dari Nol #11: Membuat REST API Pertamamu dengan net/http, kamu akan lihat bahwa setiap request yang masuk ke server Go dilayani oleh goroutine sendiri. Konsep hari ini adalah pondasinya.

Kalau ada yang terlewat, ulangi dulu bagian 9 tentang interface sebelum lanjut. Dan kalau bisnismu butuh sistem aplikasi yang cepat dan andal seperti yang biasa dibangun dengan Go, tim Arrazy siap membantu.