125 Performance Tips untuk gqlgen di Produksi

Banyak dari kita mengenal dan mencintai kecepatan serta tipikal schema-first dari gqlgen , salah satu GraphQL server paling populer di ekosistem Go. Namun, ketika aplikasi kita mulai dipakai oleh ribuan, bahkan jutaan user di produks,i performa sering jadi bottleneck yang mahal. Di artikel ini, saya akan mengumpulkan 125 tips performa — mulai dari fondasi hingga micro-optimisasi — untuk kamu yang serius menjalankan gqlgen di production, lengkap dengan kode, data, hingga flowchart.

Roadmap Optimasi gqlgen

Sebelum masuk ke 125 tips, mari kita lihat roadmap optimasi gqlgen secara umum.

graph TD
    subgraph Fundamental
        A[Schema Design]
        B[Efficient Go Code]
        C[Proper Database Usage]
    end
    subgraph Intermediate
        D[Batching & Caching]
        E[Middleware/Instrumentation]
        F[Concurrency]
    end
    subgraph Advanced
        G[Field-level Optimizations]
        H[Custom Extensions/Plugins]
        I[Profiling/Benchmarks]
    end

    A --> D
    D --> G
    B --> E
    C --> F
    E --> H
    F --> I

graph TD
    subgraph Fundamental
        A[Schema Design]
        B[Efficient Go Code]
        C[Proper Database Usage]
    end
    subgraph Intermediate
        D[Batching & Caching]
        E[Middleware/Instrumentation]
        F[Concurrency]
    end
    subgraph Advanced
        G[Field-level Optimizations]
        H[Custom Extensions/Plugins]
        I[Profiling/Benchmarks]
    end

    A --> D
    D --> G
    B --> E
    C --> F
    E --> H
    F --> I

I. Schema dan Modularisasi Basics (1–20)

1. Desain Skema Minimalis
   Hanya expose field & tipe yang benar2 dibutuhkan klien.

2. Gunakan Scalar Types
   Hindari tipe ‘meh-n’ atau custom berlebih; default scalar Go (int, float, string, boolean) di-mapping ke backend lebih efisien.

3. Restructure Nested Object
   Hindari nested object terlalu dalam, group field yang sering dipakai bersama.

4. Document your Schema
   Developer baru tak perlu menebak sehingga mengurangi technical debt.

 1# Efficient
 2type User {
 3    id: ID!
 4    name: String!
 5    email: String!
 6    posts: [Post!]!
 7}
 8
 9# Too Bloated
10type User {
11    id: ID!
12    name: String!
13    email: String
14    mobilePhone: String
15    address: String
16    twitter: String
17    facebook: String
18    linkedin: String
19    # ...dan seterusnya
20}

5. Group Query/Mutaion Berdasarkan Modul
   Pisahkan query user, transaksi, dsb ke file/module terpisah.

…

20. Gunakan schema stitching HANYA jika perlu
    Stitching schema sangat powerful tapi juga mahal secara performa.

II. Optimisasi Resolver (21–55)

21. Avoid N+1
    Gunakan dataloader untuk batch data fetching.

1postsLoader := dataloader.NewBatchedLoader(fetchPostsBatch)

22. Kembalikan Hanya Field yang Perlu
    Query di GQL memungkinkan klien memilih field, pastikan resolvers hanya fetch field yang diminta.

23. Optimalisasi Resolver Chain
    Jangan lakukan pekerjaan berat di chain resolver, delegasikan ke layer lain.

24. Gunakan Context dengan Bijak
    Pass context hanya bila memang butuh; jangan pernah bawa context.Background() by default.

25. Parallel Resolve
    Resolver dengan operasi IO-heavy (HTTP, DB) bisa run concurrency (menggunakan goroutine & channel).

 1go func() {
 2    // long running
 3    result := fetchFromRemote(ctx)
 4    ch <- result
 5}()
 6select {
 7    case res := <-ch: 
 8        // gunakan hasil
 9    case <-ctx.Done(): 
10        // timeout / cancell
11}

26. Gunakan ErrorList daripada Panic
    gqlgen akan mengembalikan error yang clean, memungkinkan partial success.

…

50. Batasi Size Query/Mutation
    Pakai limit & offset, opsional: pagination.

…

55. Caching Partial Field di Resolver
    Untuk field-field berat, gunakan cache (mis: redis) berdasarkan subquery key.

III. Optimasi Database Layer (56–80)

56. Gunakan Query Builder
    Lihat package squirrel atau sqlc demi query yang aman dan optimal.

57. Limit Field SQL
    Select hanya kolom yang benar2 dibutuhkan.

58. Gunakan Index yang Tepat
    Identifikasi field filter/finding terbesar.

59. Bulk Insert/Update
    Setiap resolver insert data masal/array lakukan bulk, bukan loop-insert.

…

65. Short-Lived SQL Conn & Pool
    Set max idle/active connection jangan lebih besar dari max goroutine resolver.

…

70. Optimasi Proyeksi DB Berdasarkan Field Query
    Dynamic SELECT berdasarkan field di selection set GraphQL.

…

80. Prepared Statement
    Minim overhead parsing SQL: gunakan prepared/parameterized query.

IV. Concurrency & Parallelism (81–95)

81. Resolver Pooling
    Implement worker-pool pattern jika ada resolver berat.

82. Max Worker Limit
    Pastikan jumlah worker sebanding kapasitas CPU, hindari deadlock.

1func worker(jobs <-chan Job, results chan<- Result, db *sql.DB) {
2    for job := range jobs {
3        res, err := processJob(job, db)
4        results <- Result{res, err}
5    }
6}

…

90. Set Connection Timeout
    Batasi waktu backend/database supaya free resource.

…

95. Monitor Goroutine Leaks
    Gunakan pprof untuk profiling goroutine usage setiap deploy.

V. Caching & Batching External Calls (96–115)

96. Dataloader Pattern
    Gunakan library github.com/graph-gophers/dataloader utk batch field.

97. Per-Request Caching
    Cache query dalam scope satu request, terutama lookup yang berulang.

…

105. Distributed Cache
     Untuk data heavy, gunakan Redis/Memcached.

…

110. Cache Invalidation Policy
     Implement strategi invalidasi pada update.

…

115. Cache Field-level Partial Result
     Untuk field berat, key-kan berdasarkan input dan selection set.

VI. Instrumentation & Observability (116–125)

116. Metrics pada Resolver
     Track durasi masing2 resolver, mis: via Prometheus:

1prometheus.NewTimer(prometheus.ObserverFunc(func(v float64) {
2    //store timing
3})).ObserveDuration()

117. Implement Logging Context-aware
     Logging harus bawa query id/request id.

118. Distributed Tracing
     Gunakan OpenTelemetry agar jejak antar microservices.

119. PPROF, Trace Routine
     Pprof diintegrasikan di /debug/pprof/ endpoint.

…

124. Load Test Pra-Production
     Benchmark skenario worst-case query.

125. Audit Schema dan Deprecated Field
     Hapus field yang sudah tak digunakan, tiap kuartal.

Simulasi: Efek Optimasi Caching & Dataloader

Berikut simulasi sederhana dampak batch resolver dengan dataloader:

Tanpa Dataloader (N+1 Problem)

Dengan Dataloader (Batching)

Contoh Setup Caching Dataloader

1type loaders struct {
2    UserLoader *dataloader.Loader
3    PostLoader *dataloader.Loader
4}
5
6func DataloaderMiddleware(l *loaders) func(http.Handler) http.Handler {
7   //inject loader ke ctx request
8}

Penutup

Optimasi gqlgen bukan checklist one-off. Ini maraton iteratif yang harus diiringi monitor, benchmark, dan review terus menerus seiring pertumbuhan aplikasi. Dengan 125 tips ini, semoga kamu bisa memilih best practice yang tepat sesuai konteks production mu — dari schema, batch, concurrency, hingga observability — untuk GraphQL API yang gesit, scalable, dan maintainable.

Punya tips atau pengalaman lain? Sharing di komentar ya!