Belajar Backend Developer - GraphQL & API Modern

#Pendahuluan

Selama series ini kita membangun REST API (episode 4). Episode 24 memperkenalkan paradigma lain yang menantangnya: GraphQL — dan juga melihat sekilas protokol modern lain seperti tRPC. Bukan untuk menggantikan REST, melainkan untuk memahami trade-off-nya: GraphQL bukan "REST yang lebih baik", ia memecahkan masalah yang berbeda.

Mengapa penting? Karena masalah paling nyata REST adalah over-fetching dan under-fetching: mobile app butuh 3 field tapi API mengembalikan 20, atau sebuah layar butuh 4 endpoint padahal satu cukup. Di aplikasi mobile dengan bandwidth terbatas, ini berdampak besar. GraphQL menjawab dengan satu endpoint yang mengembalikan persis apa yang diminta.

#Konsep Inti

GraphQL adalah query language + runtime. Tiga konsep:

• Schema — kontrak tipe data yang bisa di-query (paling kuat di REST tanpa OpenAPI).
• Query — client meminta data spesifik; satu request, satu response sesuai permintaan.
• Resolver — fungsi yang mengisi setiap field.

#Schema

type Product {
  id: ID!
  name: String!
  price: Float!
  stock: Int!
  reviews: [Review!]
}
 
type Review {
  id: ID!
  rating: Int!
  comment: String
  author: String!
}
 
type Query {
  product(id: ID!): Product
  products(category: String, limit: Int = 20): [Product!]!
}
 
type Mutation {
  createReview(productId: ID!, rating: Int!, comment: String): Review!
}

! menandakan field non-null — kontrak yang ter-enforce. Schema ini adalah dokumentasi hidup sekaligus validasi otomatis (mirip protobuf gRPC di episode 13).

#Resolver: Mengisi Field

Resolver menentukan dari mana data tiap field diambil:

export const resolvers = {
  Query: {
    product: async (_parent, { id }: { id: string }) => {
      const { rows } = await db.query(
        "SELECT * FROM products WHERE id = $1", [id])
      return rows[0]
    },
    products: async (_parent, { category, limit }: any) => {
      const { rows } = await db.query(
        `SELECT * FROM products
         WHERE ($1::text IS NULL OR category = $1)
         ORDER BY created_at DESC LIMIT $2`,
        [category, limit],
      )
      return rows
    },
  },
  Mutation: {
    createReview: async (_parent, args: any, ctx) => {
      requireAuth(ctx) // episode 7
      const { rows } = await db.query(
        `INSERT INTO reviews (product_id, rating, comment, author)
         VALUES ($1, $2, $3, $4) RETURNING *`,
        [args.productId, args.rating, args.comment, ctx.user.name],
      )
      return rows[0]
    },
  },
  Product: {
    reviews: async (parent) => {
      const { rows } = await db.query(
        "SELECT * FROM reviews WHERE product_id = $1", [parent.id])
      return rows
    },
  },
}

Perhatikan: resolver Product.reviews dipanggil hanya jika client memintanya. Inilah kekuatan GraphQL — biaya query ditentukan permintaan client, bukan fixed endpoint.

#Keuntungan vs Tantangan

#Keuntungan

#Tantangan

#Keamanan GraphQL

GraphQL memperkenalkan vektor serangan baru:

#1. Query Depth

Query bersarang dalam bisa membebani server. Batasi kedalaman:

import depthLimit from "graphql-depth-limit"
 
const server = new ApolloServer({
  typeDefs,
  resolvers,
  validationRules: [depthLimit(5)],
})

#2. Complexity

Field mahal (yang trigger agregasi besar) diberi "bobot"; request yang melampaui total bobot ditolak.

#3. Introspection Off di Produksi

Introspection memberi peta seluruh schema — matikan di produksi untuk mengurangi informasi bagi penyerang (episode 17-18).

#4. Auth dan Rate Limit

Setiap resolver wajib requireAuth (episode 7), dan endpoint /graphql tetap di-rate limit (episode 20). Otorisasi per-field: user jangan bisa membaca field email milik orang lain.

#GraphQL vs REST: Kapan Memilih Mana

Aturan praktis:

• REST untuk API publik, API sederhana, dan tim kecil — mayoritas kasus.
• GraphQL untuk client yang banyak & beragam (mobile + web), kebutuhan data lintas resource yang kompleks, dan team yang siap memelihara schema + DataLoader.
• Keduanya bisa hidup bersama — GraphQL di satu layanan, REST di layanan lain (episode 12-13).

#Praktik: GraphQL API Kecil

curl -s -X POST http://localhost:4000/graphql \
  -H "Content-Type: application/json" \
  -d '{
    "query": "query { products(limit: 2) { id name price reviews { rating } } }"
  }'

{
  "data": {
    "products": [
      { "id": "1", "name": "Keyboard", "price": 750000, "reviews": [] },
      { "id": "2", "name": "Mouse", "price": 150000, "reviews": [] }
    ]
  }
}

Satu request, satu response, tanpa field yang tidak diminta — perbandingan langsung dengan GET /v1/products REST yang selalu mengembalikan semua field.

#Common Pitfalls

#GraphQL Tanpa DataLoader

N+1 membuat GraphQL lebih lambat dari REST. DataLoader wajib.

#Tanpa Batas Depth/Complexity

Query dalam mematikan server — sama seriusnya dengan DDoS (episode 20).

#Resolver Tanpa Auth

Satu resolver yang lupa requireAuth = kebocoran. Auth per-resolver, bukan sekali di endpoint.

#Memaksakan GraphQL untuk API Sederhana

CRUD sederhana lebih baik di REST. GraphQL menambah kompleksitas yang tidak terbayar.

#Penutup

Episode 24 membuka paradigma API modern: schema dan resolver GraphQL, keuntungan anti over-fetching, tantangan N+1 dan caching, keamanan query depth/complexity, serta aturan kapan REST vs GraphQL.

Inti yang harus dibawa pulang:

• GraphQL = schema wajib + client mengontrol data; bukan REST yang lebih baik, tapi alat berbeda.
• Resolver per-field → butuh DataLoader untuk mencegah N+1.
• Security: batas depth/complexity, introspection off, auth per-resolver, rate limit.
• REST untuk publik/sederhana; GraphQL untuk client kompleks; bisa hidup bersama.
• tRPC/gRPC untuk internal TypeScript.

Di episode 25 selanjutnya kita akan mengoptimalkan performa sampai ke level produksi: performance tuning lanjutan — profiling, connection pooling, dan analisis bottleneck. Sampai jumpa di episode 25!