gatsbyjs.com

Apa yang dibahas Gatsby?

Gatsby adalah framework React untuk membangun situs web dari komponen dan konten terstruktur. Gatsby dapat mengumpulkan data dari file, sistem manajemen konten, API, dan layanan lain; menata data tersebut melalui lapisan GraphQL; serta menggunakannya untuk membuat halaman dengan rendering statis, tertunda, sisi server, atau sisi klien.

Gatsby adalah framework-nya. gatsbyjs.com adalah situs web resmi dan pusat dokumentasinya. Perbedaan ini penting karena arsitektur, paket, dan repositori framework tersebut merupakan pokok bahasan panduan ini, sedangkan domain tersebut adalah tempat proyek menerbitkan dokumentasinya.

Sebuah proyek Gatsby biasanya menyatukan beberapa aspek dalam satu alur kerja:

• Komponen React menentukan antarmuka dan elemen halaman yang dapat digunakan kembali.
• Plugin sumber mengimpor konten dan data dari sistem lokal atau jarak jauh.
• Gatsby menormalisasi catatan yang bersumber tersebut menjadi node di lapisan datanya.
• Kueri GraphQL memilih bidang yang dibutuhkan oleh halaman dan komponen.
• API halaman dan templat mengubah data menjadi rute.
• Pengaturan rendering menentukan kapan setiap halaman dibuat.

Hubungan Gatsby dengan React

React menyediakan model komponen Gatsby. Pengembang menyusun tata letak, navigasi, templat, dan fitur interaktif dari komponen React, sementara Gatsby menyediakan framework di sekelilingnya untuk perutean, pengambilan data, pembuatan halaman, pemrosesan aset, dan keluaran produksi.

Karena itu, Gatsby bukan pengganti React dan bukan sekadar pustaka komponen. Gatsby adalah framework situs web dengan pendekatan tertentu yang dibangun di sekeliling React. Tim dapat menerapkan JSX, komposisi komponen, props, state, dan interaksi sisi browser yang sudah dikenal sambil menggunakan API khusus Gatsby untuk data dan rendering.

Hal yang ditambahkan Gatsby di sekeliling React

Aspek	Yang disediakan React	Yang ditambahkan Gatsby
Antarmuka	Komponen dan state	Konvensi halaman, tata letak, dan integrasi build
Data	Pilihan pengambilan data pada tingkat aplikasi	Lapisan data yang dinormalisasi dan alur kerja kueri GraphQL
Rute	Komponen dasar untuk sebuah aplikasi	Halaman berbasis file, pembuatan halaman secara terprogram, dan rute khusus klien
Keluaran	Antarmuka yang dirender di browser	Rendering halaman statis, tertunda, dan saat permintaan
Integrasi	Ekosistem JavaScript umum	Plugin, tema, starter, dan API siklus hidup framework Gatsby

Struktur ini dapat sesuai untuk tim React yang membangun situs web publik dengan banyak konten. Struktur ini mungkin tidak diperlukan ketika proyek kecil memiliki sedikit integrasi konten atau ketika kebutuhannya terutama berupa aplikasi yang dirender di sisi klien.

Lapisan data dan GraphQL

Lapisan data Gatsby dirancang untuk memberikan antarmuka kueri yang sama kepada berbagai sumber konten. Plugin sumber mengambil catatan dan membuat node Gatsby. Gatsby kemudian menyediakan node tersebut melalui skema GraphQL yang dapat dikueri oleh halaman dan komponen.

Sebuah situs dapat menggabungkan file Markdown, gambar, sistem konten headless, dan data layanan tertentu. Alih-alih mengharuskan setiap halaman memahami format respons asli dari setiap sumber, Gatsby dapat menyajikan catatan yang relevan melalui satu graf bersama.

Alur konten yang umum terlihat seperti ini:

1. File, layanan, atau platform konten menyimpan materi asli.
2. Plugin sumber mengimpor materi tersebut selama proses pengambilan data Gatsby.
3. Gatsby merepresentasikan catatan yang diimpor sebagai node dan membangun sebuah skema.
4. Kueri GraphQL meminta bidang yang diperlukan oleh halaman atau komponen.
5. Templat menggunakan hasil kueri untuk membuat halaman.
6. Gatsby merender halaman sesuai dengan mode rendering yang dipilih.

GraphQL merupakan bagian utama dari alur kerja data bersumber Gatsby, tetapi tidak menggantikan setiap nilai React biasa. Props komponen, state lokal, peristiwa browser, dan permintaan sisi klien tetap dapat berada di luar graf saat build. Pertanyaan yang berguna adalah apakah skema bersama Gatsby menyederhanakan konten yang harus disusun menjadi halaman.

Lapisan data juga menambah pekerjaan. Tim perlu memahami perilaku sumber, hubungan antarnode, perubahan skema, dan dependensi kueri. Graf yang menyatukan beberapa sistem dapat bernilai, tetapi biaya build dan beban pemeliharaannya harus diuji menggunakan konten yang representatif, bukan disimpulkan dari situs starter.

Plugin sumber dan model ekstensi yang lebih luas

Plugin sumber menghubungkan Gatsby dengan data. Plugin tersebut dapat membaca file lokal atau mengintegrasikan sistem dan layanan konten, lalu membuat node yang berpartisipasi dalam lapisan GraphQL. Hal ini membedakannya dari plugin yang menambahkan pemrosesan, analitik, penataan gaya, dukungan gambar, atau perilaku siklus hidup lainnya.

Gatsby mengemas pekerjaan yang dapat digunakan kembali dalam tiga bentuk yang saling berkaitan:

• Plugin menambahkan sumber, transformasi, integrasi, atau kemampuan framework.
• Tema mengemas konfigurasi dan fungsionalitas Gatsby yang dapat digunakan kembali serta diperluas oleh situs.
• Starter menyediakan proyek awal yang dapat disalin dan disesuaikan oleh pengembang.

Starter dapat mempersingkat penyiapan, tetapi dependensi dan konvensinya menjadi tanggung jawab tim yang menggunakannya. Tema dapat menjaga konsistensi fungsionalitas di berbagai situs, tetapi tim harus memahami apa saja yang dikendalikannya. Plugin dapat menghindarkan tim dari kode integrasi khusus, meskipun kompatibilitas dan pemeliharaannya harus dievaluasi satu per satu.

Keberadaan kategori plugin yang besar tidak membuktikan bahwa paket tertentu mendukung versi Gatsby, sumber data, atau model deployment suatu tim. Penilaian praktis harus mengidentifikasi paket persis yang diperlukan, memeriksa dokumentasi dan aktivitas repositorinya, serta mengujinya di dalam arsitektur yang diusulkan.

Opsi rendering di Gatsby

Gatsby pada awalnya sangat erat dikaitkan dengan pembuatan situs statis, tetapi dokumentasinya kini menjelaskan beberapa pilihan rendering. Pilihan ini dapat ditentukan per halaman sehingga artikel publik, arsip besar, rute yang bergantung pada permintaan, dan area aplikasi dapat menggunakan model produksi yang berbeda.

Opsi rendering	Waktu halaman dibuat	Pertanyaan yang sesuai untuk diajukan
Static Site Generation (SSG)	Selama build	Apakah konten yang diperlukan halaman tersedia sebelum deployment?
Deferred Static Generation (DSG)	Saat halaman tertunda pertama kali diminta	Dapatkah halaman ini dikecualikan dari build awal, dan apakah host mendukung DSG Gatsby?
Server-Side Rendering (SSR)	Saat permintaan, menggunakan getServerData	Apakah respons memerlukan data atau konteks saat permintaan?
Rute sisi klien	Di browser untuk jalur aplikasi	Apakah bagian ini sengaja dirancang seperti aplikasi, dan apa yang tersedia sebelum JavaScript selesai berjalan?

Halaman statis dan tertunda

SSG menghasilkan HTML dan aset terkait selama build. Ini merupakan pilihan yang wajar untuk konten yang masukannya telah diketahui sebelumnya. File yang dihasilkan dapat mudah didistribusikan, tetapi jumlah halaman yang besar, kueri yang mahal, banyak sumber konten, atau pemrosesan gambar yang berat dapat meningkatkan kebutuhan build.

DSG menunda halaman tertentu hingga permintaan pertamanya. Hal ini dapat mengurangi jumlah halaman yang dibuat selama build awal, terutama ketika situs memiliki banyak konten yang jarang diminta. DSG juga memerlukan lingkungan deployment yang menerapkan perilaku pembuatan tertunda Gatsby; ini tidak sama dengan sekadar mengunggah file statis ke sembarang host.

Rendering saat permintaan dan di browser

SSR menghasilkan respons saat permintaan melalui API getServerData Gatsby. SSR dapat menyajikan halaman yang keluarannya bergantung pada informasi terkini saat permintaan, tetapi memperkenalkan eksekusi server, keputusan caching, penanganan kegagalan, dan kebutuhan infrastruktur yang tidak dimiliki halaman statis sepenuhnya.

Rute sisi klien mendukung bagian aplikasi yang ditangani di browser. Rute ini dapat berdampingan dengan halaman publik yang dihasilkan, tetapi tim harus memeriksa status pemuatan, navigasi, aksesibilitas, dan konten yang tersedia sebelum kode sisi klien berjalan. Kemudahan ditemukan secara publik tidak boleh diasumsikan hanya karena suatu rute browser pada akhirnya menampilkan informasi yang benar.

Tidak ada label rendering yang menjamin kecepatan atau visibilitas pencarian. Hasil bergantung pada desain halaman, JavaScript, aset, sumber data, caching, hosting, dan kualitas implementasi. Gatsby memberi tim beberapa pilihan arsitektur; Gatsby tidak menghilangkan kebutuhan untuk mengukurnya.

Gambar dan produksi konten

Gambar sering berada di dalam pipeline konten yang sama dengan teks dan catatan terstruktur. Plugin Gatsby dapat mengambil file gambar, mentransformasikannya, dan menghubungkan aset yang telah diproses dengan kueri halaman. Komponen kemudian dapat merender data gambar yang dipilih sebagai bagian dari templat halaman.

Alur kerja editorial yang berguna memisahkan tanggung jawab:

• Editor mengelola judul, isi konten, metadata, dan referensi gambar di sumber yang dipilih.
• Plugin sumber mengimpor catatan tersebut dan aset yang dirujuk.
• Lapisan data Gatsby menghubungkan node konten dengan data gambar yang diperlukan.
• Kueri hanya meminta bidang dan varian gambar yang dibutuhkan oleh templat.
• Komponen menyediakan keterangan, teks alternatif, dimensi, dan perilaku tata letak.
• Build produksi memverifikasi bahwa catatan, aset, dan rute dapat diselesaikan bersama-sama.

Pemrosesan gambar dapat meningkatkan konsistensi, tetapi tetap merupakan pekerjaan build. Tim harus menguji jumlah dan ukuran aset yang sebenarnya, memastikan bagaimana perubahan memengaruhi build ulang, dan mempertahankan teks alternatif yang bermakna dari sumber editorial. Plugin tidak dapat menentukan apakah suatu gambar bersifat informatif, dekoratif, atau telah dideskripsikan dengan tepat.

Situasi yang sesuai untuk Gatsby

Gatsby sangat relevan ketika sebuah proyek telah menggunakan React dan perlu menyusun konten dari beberapa sistem. Graf datanya dapat menyediakan lapisan yang konsisten antara sumber-sumber tersebut dan templat halaman yang menggunakannya.

Situasi umum yang layak dievaluasi meliputi:

• Situs dokumentasi atau editorial yang menggabungkan file, gambar, dan platform konten.
• Situs pemasaran dengan komponen React yang dapat digunakan kembali dan catatan halaman terstruktur.
• Proyek penerbitan multisumber yang mendapat manfaat dari satu antarmuka kueri.
• Situs Gatsby yang sudah ada dan dibangun di sekitar API halaman, GraphQL, serta plugin yang telah mapan.
• Koleksi konten besar yang halaman-halaman tertentunya dapat menjadi kandidat untuk DSG.
• Situs yang menggabungkan halaman publik yang dihasilkan dengan bagian saat permintaan atau sisi klien.

Gatsby mungkin kurang cocok secara langsung ketika suatu proyek memiliki satu sumber konten sederhana, tidak memperoleh manfaat dari graf yang dinormalisasi, atau memerlukan arsitektur aplikasi yang terutama berpusat pada operasi saat permintaan dan sisi klien. Itu adalah penilaian arsitektur, bukan putusan atas kualitas framework.

Pertimbangan build dan deployment

Pembuatan statis memindahkan pekerjaan ke sebelum deployment. Gatsby mungkin perlu mengambil data sumber, menyusun skemanya, menjalankan kueri, membuat halaman, memproses gambar, membundel kode, dan menulis keluaran. Durasi serta kebutuhan sumber dayanya bergantung pada proyek yang sebenarnya.

Evaluasi yang representatif harus mencatat:

Area pengujian	Hal yang perlu diverifikasi
Skala konten	Jumlah halaman, jumlah node, hubungan, dan ukuran catatan yang realistis
Keandalan sumber	Autentikasi, batas laju, kegagalan, dan pengambilan berulang yang konsisten
Kueri	Stabilitas skema, biaya kueri, dan kesalahan setelah perubahan konten
Gambar	Volume pemrosesan, penggunaan memori, ukuran keluaran, dan metadata editorial
Rendering	Keluaran SSG, permintaan pertama DSG, respons SSR, dan pemuatan rute klien
Deployment	Dukungan untuk setiap mode yang dipilih, perilaku caching, dan pemulihan kegagalan

Demonstrasi kecil tidak dapat memastikan perilaku katalog penuh. Tim harus menguji build bersih, perubahan inkremental jika didukung, gangguan sumber konten, serta halaman di bagian umum maupun ekstrem dari kumpulan data.

DSG dapat memindahkan pekerjaan dari build awal, sementara SSR memindahkan pekerjaan ke permintaan. Itu adalah perubahan dalam waktu pelaksanaan dan tanggung jawab operasional, bukan peningkatan performa tanpa biaya. Host yang dipilih harus mendukung perilaku Gatsby yang diperlukan, dan tim harus memahami apa yang terjadi selama permintaan dingin atau kegagalan layanan hulu.

Gatsby, Astro, dan alternatif lainnya

Gatsby dan Astro dapat sama-sama muncul dalam evaluasi untuk situs web berbasis konten, tetapi keduanya menata proyek secara berbeda. Gatsby menjadikan React, lapisan data GraphQL, plugin sumber, dan API pembuatan halamannya sebagai bagian utama. Astro harus dinilai berdasarkan arsitektur terdokumentasinya sendiri, bukan dianggap sebagai jawaban yang lebih cepat atau lebih baru secara otomatis.

Gatsby layak dipertimbangkan lebih lanjut ketika tim menginginkan React di seluruh antarmuka, perlu mengueri beberapa sumber konten yang dinormalisasi, bergantung pada integrasi Gatsby, atau memelihara basis kode Gatsby yang telah mapan. Framework lain mungkin lebih sederhana ketika graf dan siklus hidup plugin tersebut akan menambah struktur tanpa menyelesaikan masalah konten yang nyata.

Perbandingan yang berguna membangun bagian representatif yang sama pada setiap kandidat: satu sumber konten, satu halaman kompleks, satu daftar, penanganan gambar, navigasi, dan mode deployment yang dimaksudkan. Bandingkan pemahaman pengembang, perilaku build, keluaran browser, aksesibilitas, kebutuhan hosting, dan kepemilikan pemeliharaan. Hindari menetapkan pemenang universal berdasarkan templat bawaan.

Pendiri dan sumber daya komunitas resmi

Dalam tanya jawab komunitas resmi Gatsby yang diterbitkan pada 2 April 2020, Kyle Mathews disebut sebagai “Pendiri @ GatsbyJS.” Atribusi bertanggal tersebut menggambarkan peran historisnya dalam sumber itu; atribusi tersebut tidak boleh dibaca sebagai klaim mengenai kepemimpinan Gatsby saat ini.

Dokumentasi Gatsby mengarahkan pengembang ke kanal komunitas resmi untuk kebutuhan yang berbeda:

• Discord dicantumkan sebagai tempat untuk meminta bantuan pengembangan kepada komunitas.
• GitHub Discussions mendukung diskusi proyek dan fitur.
• Dokumentasi kontribusi menjelaskan berbagai cara untuk berpartisipasi dalam proyek.
• Repositori gatsbyjs/gatsby yang dipelihara berisi sumber framework, paket, isu, dan riwayat kontribusi.

Sumber daya ini membantu pembaca memverifikasi dokumentasi, mengajukan pertanyaan implementasi, dan memeriksa pekerjaan proyek yang tersedia untuk publik. Keberadaannya tidak boleh diubah menjadi klaim tanpa dukungan mengenai waktu respons, umur paket, atau rencana masa depan.

Hal yang harus diputuskan tim sebelum menggunakan Gatsby

1. Petakan konten. Identifikasi setiap sumber, hubungan antarpencatatan, frekuensi pembaruan, dan halaman yang menggunakan setiap bidang. Hal ini menunjukkan apakah lapisan GraphQL Gatsby yang dinormalisasi menyelesaikan masalah koordinasi yang bermakna.

2. Tetapkan mode rendering untuk halaman yang representatif. Pastikan halaman mana yang dapat dibuat statis, mana yang mungkin ditunda, mana yang memerlukan getServerData, dan mana yang sengaja dibuat di sisi klien. Verifikasi bahwa target deployment mendukung kombinasi yang dihasilkan.

3. Audit kumpulan dependensi yang konkret. Periksa plugin sumber, plugin transformasi, tema, starter, dan alat gambar yang diperlukan terhadap versi Gatsby proyek. Buat prototipe integrasi yang belum pasti sebelum menjadikannya dependensi arsitektur.

4. Uji beban kerja yang menyerupai produksi. Gatsby menawarkan framework React dan konten yang koheren, tetapi kesesuaiannya berasal dari keselarasan dengan data, halaman, integrasi, dan model hosting tim, bukan dari janji umum mengenai kecepatan, peringkat pencarian, atau penskalaan tanpa upaya.