DE{CODE}: Headless 101 untuk Pengembang WordPress

Pengembangan tanpa kepala bisa lebih kuat dan bahkan lebih menyenangkan daripada pengembangan WordPress tradisional. Namun, dengan begitu banyak pilihan baru dalam kumpulan yang muncul ini, apa cara terbaik untuk memulai? Lokakarya ini akan memandu pembuat melalui penginstalan dan pengoptimalan proyek WordPress tanpa kepala, hingga membuat templat halaman pertama Anda di bagian depan yang dipisahkan.

Slide Sesi

Transkrip Teks Lengkap

GRACE ERIXON : Selamat datang di Headless 101 untuk Pengembang WordPress. Nama saya Grace Erixon, dan saya advokat pengembang rekanan di WP Engine. Bergabung dengan saya adalah Steve dari Haus. Hari ini, kami akan memberi Anda pengantar singkat tentang apa itu WordPress headless, dan bagaimana Anda bisa mulai menggunakannya.

Jadi untuk memahami apa itu arsitektur situs web WordPress headless, penting untuk memastikan bahwa kita semua memiliki pemahaman yang sama tentang seperti apa arsitektur WordPress tradisional itu. Secara tradisional, CMS seperti WordPress akan menangani front end dan back end sebuah situs web.

Dalam arsitektur tradisional, penerbit membuat dan mengelola konten seperti posting blog dan halaman di dalam WordPress. Pengembang menulis kode untuk mengontrol tampilan dan fungsi situs menggunakan PHP dan API tema WordPress. Kemudian WordPress menghasilkan halaman HTML yang dikirim ke pengunjung.

Dalam arsitektur CMS yang digabungkan ini, WordPress menyediakan kemampuan manajemen konten untuk penerbit. Dan itu juga bertanggung jawab untuk menyajikan halaman HTML kepada pengunjung situs web. CMS tanpa kepala menggunakan arsitektur terpisah di mana ujung depan dan ujung belakang dikelola secara terpisah. Dalam arsitektur tanpa kepala, penerbit masih membuat dan mengelola konten di WordPress, sama seperti arsitektur WordPress tradisional.

Pengembang menulis kode untuk mengontrol tampilan dan fungsi situs dalam JavaScript serta menggunakan WPGraphQL atau REST API untuk mengeluarkan data dari WordPress. Framework seperti Faust.js, Next.js, Nuxt.js atau SvelteKit sering digunakan untuk mendukung aplikasi frontend ini. Kemudian aplikasi JavaScript ujung depan menghasilkan dan menyajikan halaman HTML yang dikirim ke pengunjung situs web.

Tidak seperti arsitektur tradisional, WordPress tidak lagi bertanggung jawab untuk membuat halaman HTML. Jadi interaksi untuk bertukar konten antara back end WordPress dan aplikasi JavaScript front end terjadi melalui lapisan API. Dua opsi untuk lapisan API adalah WordPress REST API atau WPGraphQL.

REST API dibundel dengan WordPress. Namun, pola akses data yang diperlukan bisa lambat karena REST mengharuskan setiap sumber daya memiliki titik akhir masing-masing. Misalnya, diperlukan beberapa perjalanan bolak-balik untuk merekonstruksi tiang yang sepenuhnya dimodelkan. Jika Anda ingin mendapatkan konten, penulis, dan kategori postingan, diperlukan tiga panggilan API terpisah.

Sebaliknya, WPGraphQL memungkinkan kita untuk meminta konten, penulis, dan kategori postingan semuanya dalam satu permintaan. Karena itu, WPGraphQL adalah lapisan API pilihan kami. WPGraphQL adalah plugin gratis yang menyediakan skema dan API GraphQL yang dapat diperpanjang untuk situs WordPress Anda. WPGraphQL lebih cepat daripada REST API karena mendapatkan data persis yang diminta, dan menghasilkan lebih sedikit fungsi yang dijalankan melalui pengoptimalan kueri, lebih sedikit pengunduhan data, pemuatan data yang lebih efisien, dan banyak sumber daya disertakan dalam satu permintaan.

Arsitektur tanpa kepala memberi pengembang kebebasan untuk memilih dari tumpukan teknologi ujung depan mana pun dengan kerangka kerja JavaScript yang paling populer. Beberapa framework JavaScript ujung depan paling populer termasuk React, Vue.js, dan Svelte. Kerangka kerja baru dirilis setiap saat, jadi daftar ini tidak lengkap.

Banyak dari framework JavaScript ini digunakan bersamaan dengan framework meta yang menambahkan solusi untuk hal-hal seperti perutean, rendering sisi server, dan lainnya. React digunakan bersamaan dengan Next.js, Vue.js digunakan bersamaan dengan Nuxt.js, dan Svelte digunakan bersamaan dengan SvelteKit. Gatsby adalah kerangka kerja meta populer lainnya.

WP Engine telah mengembangkan Faust.js, framework JavaScript yang dibangun di atas React dan Next.js. Faust dibuat khusus untuk mendukung aplikasi web WordPress tanpa kepala. Ini mendukung otentikasi dan memposting pratinjau di luar kotak, menyediakan kait React bawaan yang nyaman untuk mengakses data WordPress, dan banyak lagi.

Jadi kita telah berbicara tentang apa arti arsitektur WordPress tanpa kepala dan jenis teknologi yang akan Anda gunakan. Tapi mari kita sentuh dengan cepat mengapa Anda bahkan memilih tanpa kepala. WordPress sendiri adalah CMS yang berat, dan menggunakan PHP, yang bukan bahasa cepat. WordPress tanpa kepala menggunakan bahasa asuh melalui JavaScript dan hanya memuat file yang diperlukan melalui panggilan API. Ini jauh lebih ringan, jadi situs Anda akan memuat lebih cepat.

WordPress tanpa kepala juga meminimalkan risiko pada konten Anda karena data Anda terpisah dari pengiriman ujung depan Anda. Itu kurang terkena serangan web. Dan manfaat utamanya adalah arsitektur WordPress headless memungkinkan penerbit untuk terus mendapatkan keuntungan dari pengalaman penerbitan hebat yang disediakan WordPress sementara juga memungkinkan pengembang dan pengunjung situs web memanfaatkan kemampuan teknis yang dihadirkan oleh aplikasi JavaScript modern.

Sekarang, mari kita gali kode situs tanpa kepala yang sebenarnya. Saya telah merekam sebelumnya langkah-langkah dari situs WordPress tanpa kepala Atlas Blueprints yang baru. Fitur Blueprints baru di Atlas menyediakan cara yang sangat mudah untuk menjalankan dan menjalankan situs WordPress headless yang lengkap. Mereka datang dengan kode awal, plugin, model konten, dan struktur halaman untuk meluncurkan aplikasi Anda lebih cepat.

Jadi mari buat situs Blueprint baru agar kita bisa menyelami kodenya. Dari dalam dasbor WP Engine, kita akan menuju ke Atlas. Klik Buat Aplikasi. Pilih Mulai dengan Cetak Biru. Dan kemudian kita akan memilih cetak biru mana yang ingin kita gunakan. Saya akan memilih cetak biru portofolio.

Kemudian Anda akan menghubungkan akun WP Engine Anda ke akun GitHub Anda, dan mengkloning cetak biru itu ke dalam repositori baru. Ini akan memakan waktu beberapa detik untuk membangun. Terakhir, Anda cukup memilih nama repositori yang baru saja Anda buat, wilayah yang paling dekat dengan Anda, lalu klik Buat Aplikasi.

Sekarang, jika Anda mengklik URL Atlas, kita dapat melihat seperti apa situs WordPress headless kita. Kami secara khusus tertarik pada halaman Posting. Seperti yang Anda lihat, situs menarik semua posting terbaru ke halaman Blog Kami ini. Dan setiap posting juga memiliki halaman tampilan masing-masing. Tapi dari mana semua data ini berasal?

Jika kita kembali ke dashboard WP Engine, kita akan melihat tombol untuk WP Admin. Ada bagian belakang untuk situs WordPress tanpa kepala kami. Jika saya mengklik Posting, Anda akan melihat daftar yang sama dengan aplikasi web yang ditarik. Sekarang, kita dapat membuka repositori GitHub tempat Blueprint kita dikloning. Dan mari kita tiru repo itu ke lingkungan lokal kita.

Lalu saya akan membuka repo ini di Visual Studio Code, editor kode favorit saya. Mengebor ke direktori proyek, file untuk halaman blog dapat ditemukan di SRC, halaman, posting, Index.js. Proyek ini dibangun menggunakan React, Next.js, Faust.js, dan WPGraphQL. Jika Anda tidak terbiasa dengan React atau bahkan JavaScript, ini mungkin terlihat membingungkan pada awalnya.

Di bagian pertama, file tersebut hanya mengimpor hal-hal yang diperlukan dari sumber internal dan eksternal. Bagian kedua yang mendefinisikan bidang prepass simpul pos adalah tempat setiap bagian data yang kita perlukan dicantumkan. Menjalankan ini melalui prepass memastikan bahwa data ada saat kita membutuhkannya dan tidak ada permintaan kaskade yang terjadi.

Kemudian kita memiliki fungsi halaman. Awalnya hanya mengumpulkan data yang kita butuhkan ke dalam beberapa variabel yang berbeda, yaitu, pengaturan umum dan daftar postingan bernomor halaman. Tag di dalam pernyataan pengembalian adalah kode yang akan ditampilkan secara visual di halaman web. Pertama, kita memiliki komponen untuk header. Kemudian, di dalam komponen utama ini, kami memiliki komponen header entri, dan itulah yang menampilkan judul besar bertuliskan Tulisan Terbaru di bagian atas halaman.

Terakhir, kita masuk ke komponen post, yang menerima daftar postingan yang diberi halaman sebagai parameter. Mari kita lihat apa yang dilakukan komponen post dengan informasi ini. Ini dia mengulang setiap posting yang terdapat dalam daftar posting yang diterimanya. Untuk setiap posting, ini menampilkan tampilan seperti kartu di halaman posting terbaru. Yang pertama terdiri dari komponen gambar unggulan yang dibungkus dengan tautan ke halaman posting blog individu, tajuk judul posting, dan komponen info posting yang terdiri dari tanggal dan penulis posting.

Kembali ke file Index.js yang menampilkan semua posting, kami menyelesaikannya dengan menampilkan komponen Load More di bagian bawah halaman untuk mengambil lebih banyak posting jika diminta dan footer. Fungsi terakhir, getStaticProps, adalah fungsi pembuatan situs statis Next.js yang memerintahkannya untuk melakukan pra-render halaman ini pada waktu pembuatan menggunakan alat peraga yang dikembalikan oleh fungsi. Dan itu saja.

Terima kasih kepada Blueprints karena telah menangani penyiapan Headless untuk kami. Sangat mudah untuk memecah apa yang masuk ke halaman posting untuk mendapatkan data dari backend WordPress menggunakan WPGraphQL dan menampilkan posting menggunakan komponen React. Terima kasih telah menyimak. Anda dapat menemukan saya di Twitter @graceerixon.

Lihat developers.wpengine.com untuk konten lainnya seputar Headless WordPress. Kami memiliki tutorial tentang cara membangun situs WordPress Headless pertama Anda dari awal menggunakan Faust.js, dan kami sedang mengerjakan serangkaian konten Headless 101 sekarang. Anda bisa mendapatkan semua alat yang ditawarkan Atlas jika Anda mendaftar akun Sandbox gratis. Sekarang saya akan memberikannya kepada Steve untuk berbicara lebih banyak tentang mengapa Haus memilih WordPress Tanpa Kepala untuk proyek leoburnett.com mereka.

STEVE SCAVO: Terima kasih, Grace. Hai, saya Steve Scavo, CTO di Haus. Kami adalah studio dan agensi teknologi kreatif dari Los Angeles, California. Pembicaraan ini berjudul Headless 101 untuk Pengembang WordPress. Dan berterus terang, saya bukan pengembang WordPress karena perdagangan, tapi saya pikir itu bagian dari keindahan arsitektur tanpa kepala.

Jadi kita bisa dengan mudah menyebut Headless 101 ini untuk pengembang non-WordPress yang perlu memanfaatkan WordPress. Itu mungkin judul yang tepat. Itulah yang indah tentang tanpa kepala. Ini adalah win-win-win dari semua sisi, seperti yang akan Anda lihat.

Jadi mengapa tanpa kepala? Ada begitu banyak alasan tingkat tinggi yang dapat kita bicarakan, tetapi menurut saya pembicaraan semacam itu tentang contoh produksi nyata dan contoh dunia nyata saat itu bersinar sangat membantu. Dan saya ingin memamerkan proyek yang kami lakukan untuk Leo Burnett menggunakan tanpa kepala di bawah arsitektur tanpa kepala. Untuk konteksnya, Leo Burnett adalah biro iklan bertingkat di luar Chicago, tetapi mereka memiliki banyak kantor di seluruh dunia dan global. Jadi mereka punya banyak konten, banyak pekerjaan.

Situs lama beroperasi pada satu tema WordPress. Itu benar-benar terfragmentasi, agak lambat, tidak bekerja dengan baik. Itu sulit untuk diperbarui, dan itu tidak cukup menunjukkan cap dan merek yang ingin disampaikan oleh Leo Burnett. Jadi itulah yang kami kerjakan dari perspektif desain. Dan kami memilih tanpa kepala untuk benar-benar memodernisasi tumpukan mereka.

Kami hanya ingin itu terasa hidup dan segar dan memiliki kemampuan semacam itu yang kami butuhkan untuk benar-benar menggabungkan pengalaman pengguna dan UI yang luar biasa. Kami ingin meningkatkan kekuatan penerbitan mereka. Kami ingin meningkatkan irama yang dengannya mereka dapat memublikasikan konten. Kami ingin membangun kembali identitas merek dan memiliki UI dan interaksi, nuansa ke situs web yang benar-benar memancarkan Leo Burnett dan semua sentuhan kecil dan semacam poin editorial dan tipografi serta interaksi yang ingin mereka sampaikan.

Dan kami ingin menyiapkan basis kode dan situs web untuk masa depan. Kami tidak hanya ingin situs tersebut relevan untuk 12 bulan ke depan. Kami ingin itu relevan untuk dekade berikutnya, mungkin. Dan saya pikir arsitektur tanpa kepala ini, tumpukan tanpa kepala ini benar-benar melakukan itu.

Jadi salah satu masalah awal dengan headless adalah selalu ada banyak keputusan seputar hosting dan penerapan serta infrastruktur, dan itu selalu menjadi masalah besar. Jadi keputusan tumpukan ini selalu diserahkan kepada pengembang. Dan Anda mencari-cari dan mencari-cari ide, oke, aplikasi pihak ketiga, mungkin CI/CD apa yang perlu Anda gunakan? Apakah kita akan menyelenggarakan ini di AWS? Bagaimana kita melakukannya? Layanan apa? Dan kemudian Anda mengimplementasikan potensi semacam ini– solusi ad hoc di sekitar aliran itu.

Nah, platform Atlas dan WordPress Engine Atlas benar-benar memecahkan masalah ini. Di sinilah ia berperan. Kami memilih menggunakan Atlas karena semua alasan tersebut, dan mereka memiliki infrastruktur layanan terkelola ini. Mereka membakukan pipa CI/CD. Anda tidak benar-benar harus memikirkannya.

Ada migrasi data antar lingkungan yang pada dasarnya turun ke aliran satu klik. Itu selalu menjadi masalah besar secara historis dengan beralih dari QA ke pementasan ke produksi. Pada dasarnya WordPress Engine dan platform Atlas telah menurunkannya menjadi satu klik.

Dan kemudian ada kelelahan di sekitar layanan mikro dan DevOps. Hanya ada beban kognitif yang berat tentang seberapa banyak Anda harus memikirkan dan mendukung dan menyadarinya sebagai pengembang dan terus menjalankannya. Ini semua adalah hal-hal yang benar-benar diambil oleh platform Atlas dari tangan Anda dan diselesaikan dengan cara yang menguntungkan.

Jadi mari kita bicara tentang beberapa dinamika yang menurut saya benar-benar dipromosikan tanpa kepala dan sangat ditekankan. Pilar pertama di sini– ada tiga. Pilar pertama adalah pengalaman pengembang. Ini memungkinkan kita untuk memilih alat yang tepat untuk pekerjaan itu. Dan ketika saya mengatakan kami, maksud saya pengembang.

Itu memungkinkan kita untuk memilih tumpukan yang ingin kita tulis kodenya. Dan itu, bagi kita, itu ada di Haus, itu Next.js dan React. Next.js hanyalah kerangka kerja yang luar biasa di sekitar beberapa konvensi yang sangat bagus untuk perutean dan kinerja serta arsitektur aplikasi. Dan kami juga ingin mengimplementasikan sistem desain, dan bukan hanya sistem desain visual tetapi juga sistem desain terkodifikasi. Ini adalah sesuatu yang membuat aplikasi kita konsisten, teruji, indah.

Interaksinya konsisten. Ini memungkinkan kami untuk membuat halaman dan fitur baru ke dalam ekosistem tersebut ke depannya juga, dan mempertahankannya serta mempertahankan konsistensi tersebut. Itu juga memungkinkan kita untuk menulis kode ekspresif deklaratif dan React mendukungnya sebagai perpustakaan. Tapi kami juga percaya pada gaya penulisan itu sebagai sebuah tim. Itu memungkinkan kita untuk memilih tumpukan itu untuk kita di ujung depan, sedangkan mungkin situs WordPress berbasis tema tradisional, kita tidak benar-benar memiliki kemewahan yang sama.

Kami juga membutuhkan banyak ruang kepala kreatif. Anda dapat melihat ketika Anda mengunjungi leoburnett.com, ada transisi halaman yang indah. Ada– kami tidak terikat pada tumpukan WordPress tradisional tentang bagaimana hal-hal harus dirender. WordPress tidak lagi bertugas merender frontend.

Ruang kepala kami hampir tidak terbatas. Kita dapat memilih perpustakaan animasi kita. Kita dapat memilih cara komponen kita berinteraksi satu sama lain. Ini adalah keuntungan besar di sisi DX.

Pengalaman admin ditingkatkan, dan saya pikir kami telah mengoptimalkannya karena kami tidak pernah menjauh dari keakraban lama mereka. Tidak ada cutover backend. Kami beralih dari WordPress ke WordPress. Kami tidak perlu mengekspor data dan menulis skrip untuk pindah ke sistem berpemilik lain. Jadi keakraban sangat besar. Kami ingin mempertahankan aliran semacam itu untuk admin leoburnett.com saat ini.

Adopsi dan dokumentasi– jika Anda menghabiskan lima menit di web, Anda mungkin telah menyentuh ujung belakang WordPress, dan itu tidak bisa dilebih-lebihkan. Leo Burnett juga memiliki banyak poin konten dan bidang khusus yang sangat spesifik. WordPress menawarkan itu dan memberi Anda kekuatan itu, tetapi kami dapat mengimplementasikan plugin Advanced Custom Fields, yang merupakan konvensi yang sangat bagus untuk menyesuaikan UI admin agar benar-benar ramah dan bermanfaat. Jadi itu adalah kemenangan atas pengalaman admin.

Nah, tentunya pilar ketiga adalah pengalaman pengguna. Itu yang paling penting. Pengguna, menurut saya sangat mirip dengan bagaimana kami percaya aplikasi web di Haus harus terasa seperti aplikasi asli, tidak boleh ada drop-off. Saya pikir pengguna juga sangat menghargai itu.

Mereka mulus. Mereka responsif. Mereka hanya merasa baik. Dan saya pikir kami ingin Leo Burnett dan semua aplikasi kami merasa seperti itu. Mampu memilih tumpukan yang kita inginkan di ujung depan memungkinkan kita melakukan itu.

Aplikasi asli secara inheren dipisahkan dari infrastruktur konten ujung belakangnya, begitu pula aplikasi web kami. Dan inilah yang dipromosikan Atlas. Inilah yang dipromosikan arsitektur tanpa kepala secara umum. Ini juga mempromosikan kinerja. Kita dapat merender UI kita secara universal. Itu berarti beban awal ada di sisi server. Dan setelah itu, klien mengambil alih.

Ada banyak manfaat di sini. Salah satunya adalah membuat mesin pencari senang. Itu adalah konten sisi server. Itu cepat. Ini juga memungkinkan kami untuk melakukan pra-render halaman berikutnya secara instan dan membuat permintaan tersebut berdasarkan apa yang ada di viewport dalam satu waktu.

Untuk Leo Burnett, dalam hal API konten yang kami pilih untuk digunakan, kami menyiapkan titik akhir GraphQL. Itu berarti ada muatan yang lebih ramping yang kembali. Kami secara eksplisit mendefinisikan dengan tepat konten yang kami butuhkan. Ada lebih sedikit hidrasi setelah render sisi server ke render sisi klien.

Itu lebih sedikit kode yang masuk, lebih sedikit respons, waktu respons lebih cepat. Ini benar-benar sebuah kemenangan, dan saya akan menyarankan bahwa jika Anda akan beralih ke alur kerja Atlas atau alur kerja tanpa kepala, Anda harus memperhatikan penggunaan GraphQL API versus mungkin sesuatu seperti REST API.

Dan dari sudut pandang pengguna, mereka melihat konten yang segar dan tepat waktu. Ini adalah alur penerbitan yang dioptimalkan untuk melihat pratinjau konten. Ini dioptimalkan untuk pengambilan konten cepat di sisi pementasan dan pratinjau, lalu mempromosikannya ke dalam produksi. Admin di Leo Burnett sangat senang dengan betapa mudahnya memperbarui konten, dan itu membuat pengguna senang.

Apa hasilnya? Ini hanya untuk menggulung semuanya. Ini menginspirasi developer, admin produktif, dan pengguna yang senang. Ini adalah triad dan harapan yang menurut saya benar-benar diperjuangkan oleh semua tim pengembang web.

Saat pengembang terinspirasi, mereka menggunakan seperangkat alat yang dioptimalkan. Rasanya enak. Mereka bahagia. Mereka menulis kode yang lebih baik.

Admin tahu bahwa mereka menghasilkan konten menjadi ekosistem yang indah. Itu cepat. Itu dikirim dengan cepat. Dan pengguna melihat konten yang diperbarui itu, dan mereka merasakan front end yang modern, indah, berfungsi dengan baik, dan dioptimalkan.

Saya pikir untuk menyelesaikannya– hanya beberapa pemikiran terakhir yang ingin saya ingat untuk Anda ingat. Saya pikir brief, per se, selalu memiliki bahasa yang hilang. Saya pikir terlalu sering kita hanya berbicara tentang, hei, buatkan saya situs web yang indah. Buatkan saya situs web yang luar biasa. Saya ingin tampilan dan nuansanya– dan kami telah menjalankan semua ulasan ini dengan klien.

Dan semua orang bersemangat, lalu V1 hadir, dan diluncurkan. Dan kemudian orang-orang yang perlu mengambil alih situs web itu seperti, Anda membuat saya berantakan. Bagaimana saya mengurus ini? Apakah ini aliran ad hoc yang Anda bayangkan?

Anda tidak ingin membangun situs web yang indah dan menyerahkan beban. Kami sangat bangga di sini di Haus untuk tidak melakukan itu. Dan menurut saya hal yang luar biasa tentang Atlas dan Atlas sebagai platform adalah solusinya.

Ini memberi Anda keyakinan bahwa Anda mengirimkan ekosistem dan sistem penerbitan web yang benar-benar masuk akal dari sudut pandang infrastruktur dan sudut pandang penerapan kode. Ini memberikan bukti terdokumentasi kepada tim TI dan tim teknik atau tim pemasaran bahwa Anda tahu apa yang Anda lakukan dan bahwa mereka berada di tangan yang baik sekarang dengan situs web baru yang Anda buat untuk mereka.

Karena ingat, kami tidak hanya membangun situs web. Kami sedang membangun sistem penerbitan konten, dan itu penting untuk dipahami dan diakui sejak hari pertama. Dan sekali lagi, di sinilah Atlas berperan.

Jadi saya harap berita gembira kecil itu membantu Anda secara strategis menyusun tumpukan tanpa kepala Anda ke depan. Jika itu arah yang ingin Anda ambil, saya sangat menyarankan Anda melihat Atlas. Saya harap Anda menikmati sesi ini, dan terima kasih banyak.