66 Pengenalan Federated GraphQL Architecture

GraphQL terus menjadi pilihan populer dalam mendesain API modern, terutama karena kemampuannya untuk mengurangi over-fetching, under-fetching, dan memberikan API surface yang konsisten untuk berbagai klien. Namun seiring bertambahnya kebutuhan skala dan kompleksitas sistem, muncul satu tantangan fundamental: bagaimana mengelola banyak domain microservice yang ingin diakses dengan satu endpoint GraphQL yang terpusat? Di sinilah konsep Federated GraphQL Architecture, yang dipopulerkan oleh Apollo, menjadi solusi mutakhir.

Artikel ini membahas konsep arsitektur Federated GraphQL, mengapa ia penting untuk skala microservices, serta simulasi sederhana implementasinya—meliputi contoh kode dan diagram alur untuk memperjelas arsitektur ini.

Mengapa Butuh Federation?

Pada aplikasi skala kecil hingga menengah, arsitektur GraphQL tradisional—dengan satu schema dan satu server—sudah cukup efektif. Namun, saat aplikasi tumbuh dan tim mulai mengadopsi microservices, pendekatan single schema menjadi bottleneck. Berikut masalah-masalah yang sering ditemui:

Contoh: divisi tim “User” dan “Product” ingin mengembangkan API dengan timeline dan ritme deployment masing-masing. Jika schema dan resolver terlokalisasi di satu monolith GraphQL, konflik ownership dan scaling hampir pasti terjadi.

Masuk ke Federated Architecture

Apollo Federation membawa pendekatan distributed schema composition. Setiap domain service mendefinisikan schema GraphQL beserta resolver masing-masing. Sebuah “gateway” akan menggabungkan mereka secara dinamis menjadi satu supergraph yang diekspos ke klien.

Komponen utama Federation:

1. Subgraph Service
   Microservice dengan GraphQL schema dan resolver, seperti User dan Product.

2. Apollo Gateway
   Service yang menggabungkan seluruh subgraph menjadi satu endpoint GraphQL terpadu.

Diagram alur sistem secara sederhana:

flowchart LR
    Client --> Gateway
    Gateway --> UserService
    Gateway --> ProductService

Konsep Inti Federation

Ada tiga konsep kunci:

• @key: Penanda entity identity pada schema, misal id.
• @extends dan @external**: Untuk extend type lintas subgraph.
• Joins: Automatic join antar subgraph oleh gateway.

Contoh pada domain User dan Product:

user-service/schema.graphql

type User @key(fields: "id") {
  id: ID!
  name: String!
  email: String!
}
type Query {
  me: User
}

product-service/schema.graphql

type Product @key(fields: "upc") {
  upc: String!
  name: String!
}

extend type User @key(fields: "id") {
  id: ID! @external
  purchasedProducts: [Product]
}

Pada contoh di atas, schema product-service melakukan extend pada entity User, dan bisa meng-attach field baru bernama purchasedProducts ke User, walau asalnya di service berbeda.

Membuat Gateway

Berikut contoh Apollo Gateway yang menggabungkan dua subgraph:

// index.js
const { ApolloServer } = require('@apollo/server');
const { ApolloGateway } = require('@apollo/gateway');

const gateway = new ApolloGateway({
  serviceList: [
    { name: 'user', url: 'http://localhost:4001/graphql' },
    { name: 'product', url: 'http://localhost:4002/graphql' },
  ],
});

const server = new ApolloServer({
  gateway,
  // Disable subscriptions and introspection for gateway server
  subscriptions: false,
  playground: true,
});

server.listen({ port: 4000 }).then(({ url }) => {
  console.log(`Gateway ready at ${url}`);
});

Dengan konfigurasi di atas, cukup menjalankan 3 service secara paralel:

• user-service di port 4001
• product-service di port 4002
• gateway di port 4000

Semua query ke gateway akan didistribusikan ke service masing-masing secara otomatis oleh federasi.

Simulasi End-to-End Query

Client dapat melakukan query seperti:

query {
  me {
    id
    name
    purchasedProducts {
      upc
      name
    }
  }
}

Gateway akan:

• Meminta data me ke user-service.
• Kemudian dengan id dari user, meminta data purchasedProducts ke product-service.

Ilustrasi alur query via Federation Gateway:

sequenceDiagram
    participant Client
    participant Gateway
    participant UserService
    participant ProductService

    Client->>Gateway: Query { me { id name purchasedProducts { upc name } } }
    Gateway->>UserService: Query { me { id name } }
    UserService-->>Gateway: Response { me: { id, name } }
    Gateway->>ProductService: Query { user(id) { purchasedProducts { ... } } }
    ProductService-->>Gateway: Response { purchasedProducts }
    Gateway-->>Client: Aggregate Response

Perbandingan Dengan Stitched Schema

Sebelum Federation, arsitektur populer lain adalah “schema stitching”, yang menggabungkan schema GraphQL secara manual di middleware. Federation memberikan beberapa keunggulan:

Kelebihan dan Kekurangan

Kelebihan:

• Isolasi schema dan resolver per tim/domain.
• Otomatisasi join serta compose schema.
• Deployment microservice bisa independen.
• Ekosistem tooling (Apollo Studio, gateway, tracing, dsb.).

Kekurangan:

• Learning curve awal cukup tinggi.
• Jika gateway down, semua subgraph terdampak.
• Overhead tracing dan observabilitas lebih kompleks.
• Perlu perhatian khusus untuk security antar service.

Kesimpulan

Federated GraphQL Architecture adalah jawaban atas kebutuhan API modern, modular, dan scalable di era microservices. Dengan membagi schema menjadi subgraph dan satu gateway sebagai distributed entry point, ownership dan deployment setiap domain menjadi lebih jelas, dan pengelolaan API pun lebih fleksibel.

Membiasakan tim dengan Federation memang butuh proses, tapi untuk aplikasi yang domain-nya terus tumbuh dan perlu skalabilitas, arsitektur ini adalah investasi yang pantas.

Referensi Lanjut:

• Apollo Federation Docs
• GraphQL Specification

Segera coba federasi pada layanan-layanan Anda, dan rasakan bedanya!