99 Kontribusi ke Open Source graphql-go: Pengalaman, Praktik Terbaik, dan Pembelajaran

Open source bukan sekadar istilah; di dunia software engineering, ia adalah ruang belajar, tumbuh, dan kolaborasi nyata. Salah satu pengalaman paling berharga dalam perjalanan open source saya adalah berkontribusi hingga 99 pull request pada proyek graphql-go, sebuah pustaka utama GraphQL di ekosistem Golang.

Artikel ini merangkum perjalanan saya: motivasi, tipe kontribusi, tantangan, simulasi kode, hingga praktik terbaik yang saya temukan sepanjang jalan. Jika Anda ingin menjadi kontributor handal, atau tim Anda ingin membangun budaya open source yang sehat, baca hingga akhir!

Mengapa graphql-go?

Sebelum memulai, berikut beberapa alasan kenapa saya memilih graphql-go:

1. Digunakan luas – Banyak proyek production di Indonesia dan dunia memakai Go untuk backend, dan GraphQL jadi API masa kini.
2. Ekosistem berkembang – graphql-go sangat open untuk kontributor, dengan issue tracker aktif dan banyak kebutuhan fitur.
3. Tantangan nyata – Implementasi GraphQL di Go butuh pemahaman type system, reflection, performance, dan keamanan.

99 Kontribusi Itu… Apa Saja?

Tak semua kontribusi harus berupa fitur “wah”. Berikut adalah breakdown dari 99 kontribusi saya ke graphql-go:

Menarik bukan? Hanya 17 dari 99 PR berbentuk fitur baru. Selebihnya memastikan stabilitas, keterbacaan, dan kualitas kode.

Proses Kontribusi: Simulasi Nyata

Mari simulasikan salah satu kontribusi sederhana yang ternyata menambah value signifikan: menambah validasi field Enum.

Masalah Asli

Dalam implementasi lama, Enum tidak melakukan pengecekan case-sensitiveness dengan optimal. User bisa mengirimkan enum STATUS_active, padahal seharusnya hanya menerima STATUS_ACTIVE.

Diagram Alur: Validasi Enum

flowchart TD
    A[Query Masuk] --> B{Field Type Enum?}
    B -- Tidak --> C[Lewat Normal]
    B -- Ya --> D{Value Valid?}
    D -- Tidak --> E[Kembalikan Error]
    D -- Ya --> F[Lanjutkan Resolving]

Kode Sebelumnya

// Sebelum patch: Enum tanpa case checking yang baik
if enumType, ok := field.Type.(*graphql.Enum); ok {
    value := params.Args["status"]
    // Accepted tanpa case-sensitive check
    if _, ok := enumType.ValuesMap[strings.ToUpper(value.(string))]; !ok {
        return nil, errors.New("Invalid enum value")
    }
}

Kode Setelah Patch

// Setelah perbaikan: strict case-sensitive check
if enumType, ok := field.Type.(*graphql.Enum); ok {
    value := params.Args["status"]
    // Accept hanya jika persis match
    if _, ok := enumType.ValuesMap[value.(string)]; !ok {
        return nil, errors.New("Nilai enum tidak valid")
    }
}

Perbaikan kecil? Ya. Tapi PR ini mengurangi silent errors dan meningkatkan developer experience downstream.

Pembelajaran Kunci dari Setiap Tahap

1. Pentingnya Dokumentasi

Sebelum menulis kode, saya sering perbaiki docstring dan README. Dokumentasi yang baik mempercepat onboarding kontributor baru.

“Write the docs you wish you had.” — nasihat kontributor open source senior

2. Comprehensive Testing

Menulis tes bukan hanya tentang mengcover kode, tapi juga safety net bagi penerus.

Contoh test table-driven basic Enum di Go:

func TestEnumStrictCase(t *testing.T) {
    enumType := graphql.NewEnum(graphql.EnumConfig{
        Name: "Status",
        Values: graphql.EnumValueConfigMap{
            "ACTIVE": &graphql.EnumValueConfig{Value: 1},
            "INACTIVE": &graphql.EnumValueConfig{Value: 2},
        },
    })
    cases := []struct{
        input string
        valid bool
    }{
        {"ACTIVE", true},
        {"active", false},
        {"INACTIVE", true},
        {"INACTIVITY", false},
    }
    for _, c := range cases {
        _, ok := enumType.ValuesMap[c.input]
        if ok != c.valid {
            t.Errorf("for input %v, expected %v, got %v", c.input, c.valid, ok)
        }
    }
}

3. Komunikasi Efektif

Setiap PR selalu saya lengkapi description: “Motivasi”, “Solusi”, “Demo”, “Impact kompatibilitas”. Ini mempercepat review dan menghemat waktu maintainer.

4. Refactoring Bertahap

Refactoring besar membuat codebase mudah dipahami.

Saya mulai dari split file monolith menjadi per modul:

$ git mv schema.go schema/types.go
$ git mv executor.go executor/resolve.go

Hasilnya, kontributor baru mudah mengenali entry point sesuai concerns.

5. Review dan Support Kontributor Lain

Memberikan review ke PR kontributor lain bukan cuma sopan-santun, tapi memperkuat sense of ownership bersama.

Praktik Terbaik Berdasarkan Pengalaman 99 PR

1. Open small, focused PRs. Satu PR, satu perubahan mayor. Lebih mudah direview.
2. Test before push. Gunakan go test ./... dan pastikan coverage naik.
3. Tulis commit message jelas. fix(enum): strict case checking jauh lebih baik dari update enum.
4. Aktif di Diskusi. Buka issue, komentari, ajak diskusi implementasi.
5. Review dokumentasi, bukan kode saja. Perubahan code ≠ selesai tanpa docs update.
6. Rangkul feedback. Saran dari maintainer = ruang belajar yang kadang lebih penting dari coding itu sendiri.

Dampak Pengalaman Ini Pada Karir Saya

Setelah 99 kontribusi, saya:

• Lebih percaya diri membaca large codebase
• Paham proses upstream bugfixing dan release open source
• Punya networking dengan engineer luar negeri lewat review dan diskusi issue
• Mendapat tawaran kerja remote berkat aktivitas OSS

Bahkan kontribusi kecil, saat konsisten, mendorong kepercayaan tim dan menambah visibility di komunitas global.

Menyusun Roadmap Kontribusi: Simulasi

Bagaimana strategi agar kontribusi Anda optimal? Berikut roadmap 5 langkah berdasar pengalaman:

flowchart TD
    A[Mulai Dari Isu Mudah] --> B[Perbaiki Dokumentasi & Tes]
    B --> C[Lanjut Refactoring Minor]
    C --> D[Implementasi Fitur Kecil]
    D --> E[Review PR & Aktif Diskusi]

Jangan langsung “big PR”. Semakin dalam kontribusi, semakin banyak trust yang Anda bangun dengan maintainer dan komunitas.

Penutup

Berjalan mencapai 99 kontribusi di open source graphql-go mengajarkan saya bahwa impact bukan hanya dari baris kode, tapi kolaborasi, dokumentasi, dan keuletan bersama.

Tidak peduli berapa banyak PR Anda, yang penting setiap kontribusi membawa kualitas lebih. Dan, jangan salah: small PRs menggerakkan OSS lebih cepat daripada big commit jarang-jarang.

Sudah siap menulis kontribusi #1 Anda?

Buka repo graphql-go hari ini dan temukan isu sederhana – dunia open source selalu terbuka buat yang ingin belajar!

Happy contributing, and see you on the next pull request! 🚀