Belajar Gatsby - Headless CMS & Content Platforms

#Pendahuluan

Headless CMS memisahkan konten dari presentasi: editor mengelola konten di dashboard, sementara Gatsby mengambilnya lewat API dan merendernya saat build. Satu konten bisa dipakai di banyak permukaan tanpa duplikasi.

Episode 21 membahas integrasi banyak sumber konten, best practice untuk headless setup, preview workflows dan pembaruan konten, serta pendekatan mengelola konten sebagai kode.

#Mengintegrasikan Banyak Sumber Konten

#Source Plugin untuk CMS

Setiap CMS menyediakan source plugin yang mengambil data dan memetakannya ke GraphQL. Contoh dengan Contentful:

npm install gatsby-source-contentful

Konfigurasi plugin di gatsby-config dengan akses token dari environment variable:

Konfigurasi gatsby-source-contentful

module.exports = {
  plugins: [
    {
      resolve: "gatsby-source-contentful",
      options: {
        spaceId: process.env.CONTENTFUL_SPACE_ID,
        accessToken: process.env.CONTENTFUL_ACCESS_TOKEN,
      },
    },
  ],
}

process.env.CONTENTFUL_SPACE_ID membaca nilai dari environment variable sehingga token tidak pernah ditulis di kode. Tanpa konvensi ini, setiap anggota tim berisiko menyebarkan secret ke dalam repositori. Pola yang sama berlaku untuk Sanity dan Strapi — hanya nama plugin dan options-nya yang berbeda.

Awalnya plugin membaca seluruh konten pada build pertama. Untuk project besar, periksa options yang tersedia — seperti downloadLocal bila komponen butuh file gambar secara lokal — dan baca dokumentasi plugin sebelum menyesuaikan. Opsi yang dipilih memengaruhi jumlah permintaan API dan ukuran data yang masuk ke build.

#Menyatukan Beberapa Sumber

Gatsby bisa menggabungkan banyak source sekaligus: markdown dari repo, konten dari Contentful, dan produk dari e-commerce API. Gatsby GraphQL menyatukan semuanya dalam satu schema sehingga halaman bisa mengambil data dari beberapa sumber dalam satu query. Model ini disebut unified content graph — salah satu alasan Gatsby cocok untuk arsitektur yang memakai banyak platform konten.

Keuntungan lainnya: relasi antar sumber terbentuk otomatis. Sebuah post bisa memakai gambar dari CMS dan metadata dari repo dalam satu halaman tanpa menyinkronkan data secara manual di antara dua sistem.

Semakin banyak sumber, semakin penting konsistensi. Perhatikan rate limit API masing-masing CMS dan selaraskan waktu fetching antar source. Verifikasi berkala bahwa slug dan field kunci tidak bertabrakan antar sumber, karena duplikasi data tersembunyi sering muncul belakangan.

#Best Practice untuk Headless Setup

#Content Modeling yang Konsisten

Rancang model konten sebelum menulis banyak konten. Definisi field yang jelas membuat editorial konsisten dan membuat query di Gatsby tetap sederhana. Hindari menduplikasi tipe yang sama di banyak CMS kecuali memang dibutuhkan — misalnya satu tipe untuk konten marketing dan satu lagi untuk konten teknis. Libatkan editor sejak tahap perancangan model agar nama field yang dipakai benar-benar masuk akal bagi tim non-teknis.

#Mapping ke GraphQL

Bila nama field default dari CMS tidak sesuai, gunakan gatsby-plugin-graphql-config dan custom resolvers, atau transformasi di gatsby-node dengan onCreateNode untuk menormalkan struktur sebelum halaman dibuat. Normalisasi di satu tempat membuat seluruh komponen membaca bentuk data yang konsisten. Jadikan normalisasi ini terdokumentasi sehingga siapa pun bisa melacak dari mana sebuah field berasal.

Jika beberapa CMS memakai skema serupa, pertimbangkan tipe union atau interface di GraphQL Gatsby. Dengan begitu, komponen merender konten apa pun yang bentuknya sama tanpa peduli asal sumbernya. Pola ini menjaga komponen tetap sederhana saat daftar sumber bertambah.

#Variasi Konten per Environment

Banyak CMS menyediakan environment terpisah untuk development dan production. Gunakan environment development untuk preview lokal dan simpan ID environment di environment variable, sehingga source plugin selalu mengambil data yang sesuai lingkungan. Perlu diingat, environment preview sering memakai data draft — pastikan data itu tidak bocor ke halaman production.

#Preview Workflows dan Pembaruan Konten

#Preview Build

Workflow preview membangun situs dari data draft agar editor bisa melihat hasil sebelum publish. Platform seperti Gatsby Cloud mendukung preview per konten; setiap kali draft diubah, build preview baru dijalankan dan editor melihat URL preview. Alur ini menjembatani jarak antara editor yang menulis konten dan developer yang membangun tampilan. Idealnya, preview memakai data yang belum dipublish sehingga keputusan publish tetap sepenuhnya di tangan editor.

#Webhooks dan Update

Ketika konten dipublish, CMS mengirim webhook yang memicu build produksi. Untuk konten besar, aktifkan incremental builds agar hanya halaman yang berubah yang dibangun ulang, sehingga update tidak perlu build penuh setiap waktu. Pastikan webhook hanya bisa dipanggil oleh CMS — platform hosting biasanya menyediakan token untuk mengamankan endpoint ini. Tambahkan log untuk setiap build yang dipicu agar mudah menelusuri masalah saat konten tidak muncul di produksi.

#Mengelola Konten sebagai Kode

#Markdown dan MDX dalam Git

Alternatif headless CMS adalah menyimpan konten sebagai file Markdown atau MDX di dalam repositori. Konten ikut versioning, direview lewat pull request, dan di-deploy bersama kode. Pendekatan ini disebut content as code.

Frontmatter konten Markdown

---
title: "Contoh Artikel"
published_date: "2026-08-10"
tags: [gatsby, cms]
---
 
Ini adalah isi artikel dalam Markdown.

Dengan content as code, perubahan konten tidak pernah tersebar: semuanya tercatat di git, lengkap dengan review dan tes yang sama seperti perubahan kode. Pilih headless CMS saat tim editor butuh dashboard visual, dan pilih content as code saat tim sudah nyaman dengan git.

#Kapan Memilih Pendekatan

Tidak ada jawaban universal. CMS cocok untuk tim non-teknis dan konten dalam jumlah banyak, sedangkan file Markdown cocok untuk developer dan konten yang jarang berubah. Keduanya bisa dipakai bersamaan dalam satu project Gatsby — misalnya landing page dari Markdown dan artikel panjang dari CMS. Evaluasi ulang pilihan ini seiring bertambahnya anggota tim dan volume konten.

#Penutup

Inti yang harus dibawa pulang:

• Source plugin memetakan konten CMS ke GraphQL.
• Token akses harus lewat environment variable.
• Gatsby menyatukan banyak sumber dalam satu schema.
• Preview build memungkinkan review draft sebelum publish.
• Webhook memicu build saat konten dipublish.
• Konten sebagai kode memanfaatkan versioning git.

Di episode 22 selanjutnya kita akan membahas observability dan monitoring — memantau performa situs dengan analytics, tracking build metrics, error reporting client-side, dan analisis perilaku pengguna.