Belajar GraphQL - Implementasi Resolvers dan Data Fetching

#Pendahuluan

Jika schema adalah contract, resolver adalah eksekutornya. Setiap field di schema — mulai dari root query sampai field terdalam — punya resolver yang menentukan dari mana data diambil. Episode 6 membedah resolver secara menyeluruh.

Kita akan mempelajari signature resolver dengan empat parameter (parent, args, context, info), bagaimana data mengalir antar resolver (resolver chains), cara membangun context object, pola async resolver, serta strategi mengorganisasi resolver agar tetap terawat seiring proyek membesar.

#Resolver Basics

#Anatomy Fungsi Resolver

Secara umum, sebuah resolver adalah fungsi dengan empat parameter:

Signature resolver

async function userResolver(parent, args, context, info) {
  return context.dataSources.users.findById(args.id);
}

Empat parameter tersebut adalah:

• parent: nilai yang dikembalikan resolver induk (parent field).
• args: objek berisi argument yang diberikan client.
• context: objek bersama untuk semua resolver dalam satu request.
• info: metadata eksekusi seperti AST field yang dipilih.

#Default Resolvers

Resolvers bersifat opsional. Jika sebuah field tidak memiliki resolver, GraphQL memakai default resolver: membaca property dengan nama yang sama dari objek parent. Jadi jika resolver user mengembalikan objek { id, username }, field username otomatis terisi tanpa perlu resolver tambahan.

Default resolver bekerja otomatis

export const resolvers = {
  Query: {
    user: (_, args) => ({ id: args.id, username: "arman" }),
  },
};

Di sini field username mengambil nilainya langsung dari objek yang dikembalikan, tanpa resolver eksplisit.

#Parent Parameter dan Resolver Chains

#Aliran Data Antar Resolver

Parameter parent menghubungkan resolver induk dengan resolver anak — inilah yang disebut resolver chain:

Resolver chain dengan parent

export const resolvers = {
  Query: {
    post: async (_, args, ctx) => ctx.db.posts.find(args.id),
  },
  Post: {
    author: async (post, _, ctx) =>
      ctx.db.users.find(post.authorId),
  },
};

Perhatikan alurnya: resolver post mengembalikan objek post, lalu resolver Post.author menerima objek tersebut sebagai parent dan memakai post.authorId untuk mengambil penulisnya. Data mengalir dari atas ke bawah, dan setiap level bisa mengambil data baru berdasarkan nilai dari level atas.

#Nested Resolvers

Untuk query yang bersarang dalam (misalnya post.author.company), setiap level membangun resolver chain berikutnya. Keuntungannya: resolver hanya dipanggil untuk field yang benar-benar diminta client. Ini pula yang menyebabkan masalah N+1 bila tidak hati-hati — topik yang dibedah di episode 9.

#Context Object

#Membangun Context

Context adalah objek yang dibangun sekali per request dan dibagikan ke semua resolver. Tempat yang tepat untuk user yang sedang login, koneksi database, data loader, dan header penting:

Membangun context

const server = new ApolloServer({
  typeDefs,
  resolvers,
});
 
const { url } = await startStandaloneServer(server, {
  context: async ({ req }) => ({
    user: await authenticateUser(req.headers.authorization),
    db: createDbConnection(),
  }),
});

Perhatikan pola di atas: context dibangun dengan fungsi context yang menerima objek request. Di dalamnya, token dari header authorization dipakai untuk memvalidasi user — detail lengkap autentikasi akan dibahas di episode 13.

#Sharing Data Melalui Context

Semua resolver bisa mengakses context, sehingga data seperti context.user dan context.db tidak perlu diambil ulang di tiap resolver. Ini juga membuat resolver tetap "tipis": resolver hanya memanggil fungsi dari context, bukan menulis logika database di dalamnya. Kita akan kembali ke pola ini saat membangun data loader di episode 9 dan 20.

#Info Parameter dan Async Resolvers

#Info dan Optimasi

Parameter info (bertipe GraphQLResolveInfo) berisi detail eksekusi termasuk field yang dipilih client. Ini jarang dipakai, tetapi berguna untuk optimasi lanjutan — misalnya hanya men-query kolom database yang diminta, atau membangun query dinamis. Jangan memakai info sebelum dibutuhkan; kompleksitasnya tinggi.

#Async Resolvers

Resolver yang mengambil data dari database atau API bersifat asynchronous. Pola yang dipakai adalah async dan await:

Async resolver

export const resolvers = {
  Query: {
    users: async (_, __, ctx) => ctx.db.users.findAll(),
  },
};

Jika error terjadi di dalam resolver async, throw error tersebut. GraphQL akan menangkapnya, mengembalikan error ke client, dan memastikan field lain yang independen tetap berjalan — detail strategi error ini akan dibahas di episode 11.

#Organisasi Resolver

#Struktur File Modular

Saat schema membesar, satu file resolver menjadi tidak terawat. Pola modular yang umum:

src/
  resolvers/
    user.resolver.ts
    post.resolver.ts
    comment.resolver.ts
  schema/
    user.graphql
    post.graphql

Struktur ini bisa kalian buat dengan mkdir -p src/resolvers src/schema. Setiap modul mengekspor resolver-nya sendiri, lalu digabung di satu titik. Pemecahan ini sesuai dengan pola modular resolver dan memudahkan code review. Ketika proyek sangat besar, pertimbangkan federation di episode 22 atau code-first library seperti Type-GraphQL di episode 30.

#Penutup

Inti yang harus dibawa pulang:

• Resolver adalah fungsi dengan parameter parent, args, context, dan info.
• Default resolver membaca property dari objek parent; resolver custom menimpa perilaku ini.
• Resolver chain mengalirkan data dari resolver induk ke resolver anak melalui parent.
• Context dibangun sekali per request dan berbagi user, koneksi DB, dan data loader.
• Resolver async memakai pola async dan await; selalu throw error agar ditangani GraphQL.
• Organisasi resolver secara modular menjaga proyek tetap terawat.

Di episode 7 selanjutnya kalian akan mempelajari membuat GraphQL Server dengan Apollo Server — instalasi, konstruksi schema, integrasi dengan Express dan Next.js, Apollo Sandbox untuk testing, hingga setup development dengan TypeScript. Ini episode pertama di mana semua konsep menyatu menjadi server yang benar-benar berjalan!