Blog

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.

Di Belajar Golang dari Nol #8 kita sudah merapikan kode ke dalam package dan module. Struktur project kamu sekarang sudah bersih. Tapi ada satu masalah yang belum kita sentuh: bagaimana kalau satu tugas bisa dikerjakan dengan banyak cara berbeda? Di sinilah interface masuk. Ini salah satu fitur paling penting di Go, dan kabar baiknya, konsepnya sederhana.

Masalah: satu tugas, banyak cara

Bayangkan kamu membangun aplikasi toko online. Setiap kali ada pesanan baru, sistem harus mengirim notifikasi ke pembeli. Ada yang mau lewat WhatsApp, ada yang lewat email, ada yang lewat SMS.

Dengan bekal sampai bagian 8, kamu mungkin akan menulis begini:

func KirimNotifikasi(via string, pesan string) error {
	if via == "wa" {
		// logika kirim WhatsApp
	} else if via == "email" {
		// logika kirim email
	} else if via == "sms" {
		// logika kirim SMS
	}
	return nil
}

Kode ini jalan. Tapi coba pikirkan nasibnya tiga bulan lagi. Perusahaan mau tambah notifikasi lewat Telegram. Kamu harus buka function ini lagi, tambah satu cabang else if lagi. Tambah push notification, tambah cabang lagi. Function-nya makin gemuk, dan setiap perubahan berisiko merusak cabang yang sudah jalan.

Masalah sebenarnya bukan di if else. Masalahnya, function ini harus tahu detail semua cara pengiriman. Padahal yang dia butuhkan cuma satu hal: sesuatu yang bisa mengirim pesan. Titik.

Interface itu kontrak

Interface di Go adalah cara kita menulis kebutuhan itu secara eksplisit. Bentuknya begini:

type Notifier interface {
	Kirim(pesan string) error
}

Baca deklarasi ini seperti kontrak kerja. Perusahaan pasang lowongan: “kami butuh kurir, syaratnya bisa mengantar paket”. Perusahaan tidak peduli kurirnya naik motor, mobil, atau sepeda. Selama bisa mengantar paket, kontrak terpenuhi, dia bisa dipekerjakan.

Notifier adalah kontrak versi kode. Isinya satu syarat: siapa pun yang mau disebut Notifier harus punya method Kirim yang menerima string dan mengembalikan error. Interface tidak berisi implementasi sama sekali. Dia cuma daftar syarat.

Implementasi implisit, ciri khas Go

Di bahasa lain seperti Java atau PHP, kamu harus menulis implements Notifier secara eksplisit di deklarasi class. Go tidak begitu. Di Go, sebuah type otomatis memenuhi interface kalau dia punya semua method yang disyaratkan. Tidak ada kata kunci implements. Tidak ada pendaftaran apa pun.

Kembali ke analogi kontrak kerja: kamu tidak perlu sertifikat bertuliskan “saya kurir”. Kalau kamu terbukti bisa mengantar paket, kamu memenuhi syarat. Kemampuanmu yang bicara, bukan labelmu.

Kenapa ini enak? Dua alasan:

• Kamu bisa membuat interface untuk type yang bukan milikmu. Misalnya type dari library orang lain sudah punya method yang cocok, dia otomatis memenuhi interface buatanmu tanpa mengubah kode library itu.
• Kode implementasi tidak perlu tahu interface apa saja yang dia penuhi. Struct WhatsAppSender cukup fokus mengirim WhatsApp. Urusan dia dipakai sebagai Notifier atau bukan, itu urusan pemakainya.

Contoh utuh: sistem notifikasi

Sekarang kita rakit semuanya. Dua struct, satu interface, satu function yang menerima interface:

package main

import (
	"errors"
	"fmt"
)

type Notifier interface {
	Kirim(pesan string) error
}

type WhatsAppSender struct {
	Nomor string
}

func (w WhatsAppSender) Kirim(pesan string) error {
	if w.Nomor == "" {
		return errors.New("nomor WhatsApp kosong")
	}
	fmt.Println("[WA ke", w.Nomor+"]", pesan)
	return nil
}

type EmailSender struct {
	Alamat string
}

func (e EmailSender) Kirim(pesan string) error {
	if e.Alamat == "" {
		return errors.New("alamat email kosong")
	}
	fmt.Println("[Email ke", e.Alamat+"]", pesan)
	return nil
}

func ProsesNotifikasi(n Notifier, pesan string) {
	err := n.Kirim(pesan)
	if err != nil {
		fmt.Println("Gagal kirim:", err)
	}
}

func main() {
	wa := WhatsAppSender{Nomor: "0812xxxx1234"}
	email := EmailSender{Alamat: "budi@tokokopi.id"}

	ProsesNotifikasi(wa, "Pesanan kamu sudah dikirim")
	ProsesNotifikasi(email, "Pesanan kamu sudah dikirim")
}

Perhatikan ProsesNotifikasi. Parameternya bertipe Notifier, bukan WhatsAppSender atau EmailSender. Function ini tidak tahu dan tidak peduli pesan dikirim lewat apa. Dia cuma pegang kontrak: apa pun yang masuk, pasti bisa dipanggil method Kirim-nya.

Output program di atas:

[WA ke 0812xxxx1234] Pesanan kamu sudah dikirim
[Email ke budi@tokokopi.id] Pesanan kamu sudah dikirim

Karena Notifier adalah type biasa, kamu juga bisa membuat slice berisi campuran implementasi. Ini pola broadcast yang sering dipakai:

	daftar := []Notifier{
		WhatsAppSender{Nomor: "0812xxxx1234"},
		EmailSender{Alamat: "budi@tokokopi.id"},
		EmailSender{},
	}

	for _, n := range daftar {
		ProsesNotifikasi(n, "Promo akhir bulan dimulai")
	}

Elemen ketiga sengaja dibuat kosong supaya kelihatan jalur error-nya:

[WA ke 0812xxxx1234] Promo akhir bulan dimulai
[Email ke budi@tokokopi.id] Promo akhir bulan dimulai
Gagal kirim: alamat email kosong

Sekarang bandingkan dengan versi if else di awal. Mau tambah Telegram? Buat struct TelegramSender dengan method Kirim, selesai. ProsesNotifikasi tidak disentuh sama sekali. Kode lama tetap aman, fitur baru tinggal ditambahkan. Ini yang dimaksud kode fleksibel.

Interface kecil itu idiomatik

Perhatikan Notifier cuma punya satu method. Ini bukan kebetulan. Di Go, interface yang bagus justru yang kecil. Makin sedikit syarat di kontrak, makin banyak type yang bisa memenuhinya, makin fleksibel kodemu.

Standard library Go penuh contoh interface satu method. Dua yang paling sering kamu temui:

error ternyata interface

Masih ingat bagian 3 waktu kita belajar error handling? Waktu itu saya bilang error akan kita bahas lebih dalam nanti. Ini dia bayarannya. error yang selama ini kamu pakai sebenarnya interface bawaan:

type error interface {
	Error() string
}

Artinya, type apa pun yang punya method Error() string bisa dipakai sebagai error. Itulah kenapa kamu bisa mengembalikan hasil errors.New, hasil fmt.Errorf, atau error buatan library mana pun dari function yang sama. Semuanya cuma memenuhi satu kontrak kecil.

fmt.Stringer

Interface kecil lain yang berguna adalah fmt.Stringer, kontraknya satu method String() string. Kalau struct kamu memenuhinya, fmt.Println otomatis memakai method itu saat mencetak:

package main

import "fmt"

type Produk struct {
	Nama  string
	Harga int
}

func (p Produk) String() string {
	return fmt.Sprintf("%s (Rp%d)", p.Nama, p.Harga)
}

func main() {
	p := Produk{Nama: "Kopi Gayo 250g", Harga: 85000}
	fmt.Println(p)
}

Tanpa method String, outputnya format default: {Kopi Gayo 250g 85000}. Dengan method itu, outputnya jadi Kopi Gayo 250g (Rp85000). Kamu tidak pernah mendaftarkan apa pun ke package fmt. Dia cuma mengecek: type ini memenuhi kontrak Stringer atau tidak. Implementasi implisit bekerja diam-diam di sini.

any, interface kosong, dan type assertion

Ada satu interface ekstrem: interface tanpa syarat sama sekali, ditulis interface{} atau alias modernnya, any. Karena kontraknya kosong, semua type otomatis memenuhinya. Variabel bertipe any bisa diisi apa saja.

Kedengarannya praktis, tapi hati-hati. Begitu data masuk ke any, compiler tidak bisa lagi menjaga kamu. Kamu kehilangan informasi type, dan itu mahal. Untuk mengambil kembali type aslinya, kamu butuh type assertion:

var data any = "halo"

s, ok := data.(string)
if ok {
	fmt.Println("panjang teks:", len(s))
} else {
	fmt.Println("data bukan string")
}

Bentuk data.(string) artinya “saya yakin isi data adalah string, tolong keluarkan”. Variabel ok bernilai true kalau tebakanmu benar. Selalu pakai bentuk dua nilai ini. Bentuk satu nilai tanpa ok akan membuat program panic kalau tebakannya salah.

Aturan praktisnya: pakai any hanya kalau memang tidak ada pilihan, misalnya saat menangani JSON yang strukturnya tidak tentu. Untuk kode sehari-hari, interface dengan kontrak jelas seperti Notifier hampir selalu lebih baik.

Kapan tidak perlu interface

Setelah paham interface, ada godaan untuk membuatnya di mana-mana. Tahan dulu. Interface itu abstraksi, dan abstraksi ada biayanya: kode jadi lebih sulit dilacak karena pembaca harus mencari implementasi aslinya.

Patokan sederhananya:

• Kalau cuma ada satu implementasi dan belum ada rencana nyata menambah yang lain, pakai struct langsung. Jangan bikin UserServiceInterface hanya karena terlihat rapi.
• Buat interface saat kebutuhannya muncul: ada implementasi kedua, atau kamu perlu memisahkan kode dari dependensi eksternal.
• Definisikan interface di sisi pemakai, bukan di sisi implementasi. Ini kebiasaan idiomatik di Go, beda dengan kebiasaan di Java.

Ingat prinsipnya: interface menjawab masalah “banyak cara untuk satu tugas”. Kalau caranya memang cuma satu, tidak ada masalah yang perlu dijawab.

Latihan: sistem pembayaran mini

Sekarang giliran kamu. Kita buat sistem checkout yang menerima beberapa metode pembayaran. Kontraknya satu: bisa membayar sejumlah uang. Aturan validasinya beda per metode. Transfer bank punya minimal nominal, e-wallet dibatasi saldo.

package main

import (
	"errors"
	"fmt"
)

type MetodePembayaran interface {
	Bayar(jumlah float64) error
}

type TransferBank struct {
	NamaBank   string
	NoRekening string
}

func (t TransferBank) Bayar(jumlah float64) error {
	if t.NoRekening == "" {
		return errors.New("nomor rekening belum diisi")
	}
	if jumlah < 10000 {
		return errors.New("minimal transfer bank Rp10.000")
	}
	fmt.Printf("Transfer Rp%.0f via %s berhasil\n", jumlah, t.NamaBank)
	return nil
}

type EWallet struct {
	Provider string
	Saldo    float64
}

func (e EWallet) Bayar(jumlah float64) error {
	if jumlah > e.Saldo {
		return errors.New("saldo " + e.Provider + " tidak cukup")
	}
	fmt.Printf("Bayar Rp%.0f pakai %s berhasil\n", jumlah, e.Provider)
	return nil
}

func Checkout(m MetodePembayaran, total float64) {
	fmt.Printf("Memproses pembayaran Rp%.0f...\n", total)
	err := m.Bayar(total)
	if err != nil {
		fmt.Println("Pembayaran gagal:", err)
		return
	}
	fmt.Println("Pesanan dikonfirmasi")
}

func main() {
	bca := TransferBank{NamaBank: "BCA", NoRekening: "1234567890"}
	dana := EWallet{Provider: "Dana", Saldo: 50000}

	Checkout(bca, 150000)
	Checkout(dana, 35000)
	Checkout(dana, 100000)
	Checkout(TransferBank{NamaBank: "BRI"}, 150000)
}

Jalankan dengan go run main.go. Outputnya:

Memproses pembayaran Rp150000...
Transfer Rp150000 via BCA berhasil
Pesanan dikonfirmasi
Memproses pembayaran Rp35000...
Bayar Rp35000 pakai Dana berhasil
Pesanan dikonfirmasi
Memproses pembayaran Rp100000...
Pembayaran gagal: saldo Dana tidak cukup
Memproses pembayaran Rp150000...
Pembayaran gagal: nomor rekening belum diisi

Amati dua hal. Pertama, Checkout memperlakukan semua metode sama rata lewat kontrak MetodePembayaran, padahal aturan validasi di baliknya berbeda. Kedua, dua kasus gagal ditangani rapi tanpa satu pun if else soal jenis metode di dalam Checkout.

Untuk latihan mandiri, coba tambah KartuKredit dengan validasi limit, lalu masukkan ke pemanggilan Checkout. Kalau kamu tidak perlu mengubah function Checkout sama sekali, berarti kamu sudah paham inti bab ini.

Rangkuman dan bagian selanjutnya

Hari ini kamu belajar bahwa interface adalah kontrak: daftar method yang harus dipenuhi, tanpa implementasi. Go memakai implementasi implisit, jadi type cukup punya method yang cocok. Interface kecil seperti error dan fmt.Stringer adalah gaya idiomatik Go. any ada untuk kasus khusus, dan type assertion adalah pintu keluarnya. Terakhir, jangan bikin interface untuk satu implementasi tanpa alasan.

Di bagian 10 kita masuk ke materi yang membuat Go terkenal: “Goroutine dan Channel: Kenalan dengan Concurrency”. Sampai ketemu di sana.

Kalau bisnismu butuh aplikasi yang dibangun dengan fondasi rapi seperti ini, tim Arrazy menyediakan jasa pengembangan sistem aplikasi dari perancangan sampai perawatan.