Tekan Ini: WPGraphQL dan Faust.js
Diterbitkan: 2023-01-13Selamat datang di Press This, podcast komunitas WordPress dari WMR. Setiap episode menampilkan tamu dari seluruh komunitas dan diskusi tentang masalah terbesar yang dihadapi pengembang WordPress. Berikut transkrip rekaman aslinya.
Didukung oleh RedCircle
Doc Pop : Anda sedang mendengarkan Press This, Podcast Komunitas WordPress di WMR. Setiap minggu kami menyoroti anggota komunitas WordPress. Saya tuan rumah Anda, Doc Pop. Saya mendukung komunitas WordPress melalui peran saya di WP Engine, dan kontribusi saya di TorqueMag.Io di mana saya dapat membuat podcast dan menggambar kartun serta video tutorial. Lihat itu.
Anda dapat berlangganan Press This di Red Circle, iTunes, Spotify, atau Anda dapat mengunduh episode langsung di wmr.fm.
Pada episode Press This kali ini, kita membahas tentang Headless WordPress, GraphQL, dan Faust.js. Bagaimana alat-alat ini dapat digunakan bersama dan jenis biaya apa yang dapat dikaitkan dengan WordPress Tanpa Kepala. Kami akan mencoba menyelam lebih dalam dengan ini, dan saya memiliki dua tamu hebat yang bergabung dengan saya hari ini, saya memiliki Jason Bahl, seorang insinyur perangkat lunak utama di WP Engine yang berbasis di Denver, Colorado, tempat dia mengelola WPGraphQL . Dan kami memiliki Chris Weigman, seorang manajer teknik yang bekerja di Faust.js. Saya biasanya suka memulai acara ini dengan bertanya kepada tamu tentang cerita asal WordPress mereka, tetapi saya pikir saya akan sedikit mengubah keadaan di sini.
Jason, dapatkah Anda memberi tahu kami apa itu WPgraphQL dan apa kisah WordPress Origin-nya.
Jason Bahl: Oh ya, WPGraphQL adalah plugin WordPress sumber terbuka gratis yang menghadirkan API GraphQL ke situs WordPress Anda dan GraphQL adalah bahasa kueri grafik. Sehingga memungkinkan pengembang untuk mendapatkan konten masuk dan keluar dari WordPress menggunakan bahasa kueri grafik.
Dan pluginnya berasal, saya bekerja di sebuah surat kabar beberapa tahun yang lalu dan kami melakukan banyak sindikasi konten. Kami memiliki jaringan sekitar 54 situs dan di seluruh AS dan kami perlu memindahkan konten dari satu sisi ke sisi lain. Anda tahu, ketika sebuah berita diterbitkan, surat kabar yang berbeda dapat berlangganan konten dari surat kabar lain.
Jadi ketika berbagai peristiwa terjadi, kami perlu memindahkan data di sekitar jaringan ini dan kami menggunakan WordPress REST API untuk melakukan banyak pemindahan data tersebut. Dan kami mengalami beberapa masalah dengan itu secara teknis dan seperti kinerja sebenarnya secara teknis, tetapi juga pengalaman pengembang. Saya mengetahui tentang GraphQL, bahasa kueri grafik yang sebenarnya, yang bersumber terbuka dari Facebook pada tahun 2015.
Jadi saya menemukan teknologi ini, melakukan beberapa pembuatan prototipe, menawarkannya kepada kolega saya, lalu kami memigrasikan sindikasi kontak kami dari REST ke GraphQL. Dan kemudian saya terus mengerjakan proyek sebagai proyek komunitas mengetahui bahwa kerangka kerja JavaScript menjadi hal yang populer dan itu mungkin akan menjadi kasus penggunaan utama penggunaan GraphQL, seperti komunikasi server ke server bukanlah kasus penggunaan utama. Itu memecahkan kebutuhan kami, tetapi saya melihat visi yang lebih besar untuk itu, jadi saya terus mengerjakannya sebagai proyek sumber terbuka untuk komunitas.
DP: Nah, keren. Chris, dapatkah Anda menceritakan kisah serupa tentang apa itu Faust dan bagaimana hal itu terjadi?
Chris Weigman: Sure Faust, baru-baru ini pada minggu ini, secara resmi dirilis ke publik, dirilis ulang ke kerangka kerja publik untuk membangun situs WordPress Tanpa Kepala menggunakan GraphQL. Pengembangan yang baik dimulai pada tahun 2020, dan itu adalah semacam proyek tidak resmi dari WP Engine, dan ini adalah poros utama ketiga.
Mereka telah memulainya sebagai perpanjangan dari DevRel, mulai membuatnya sedikit lebih resmi dengan dan berputar ke sesuatu yang disebut GQty dan sangat JavaScript, mentalitas pengembang pertama. Dan kemudian ketika saya mengambil alih tim pada 1 Desember tahun lalu, kami menyadari bahwa itu bukanlah target pasar kami.
Kami seharusnya mengembangkan untuk pengembang WordPress. Jadi kami mulai membangunnya kembali, dan akhirnya bisa dirilis ulang baru-baru ini.
DP: Jason baru-baru ini Anda tweet bahwa Anda telah meluncurkan wpgraphql.com baru di Faust.js. Situs sebelumnya, saya percaya adalah WordPress tanpa kepala. Bisakah Anda memberi tahu kami tentang perubahan yang Anda lakukan ini dan Anda tahu, peningkatan apa yang Anda katakan?
JB: Ya. Jadi wpgraphql.com, ini adalah situs tanpa kepala selama bertahun-tahun. Jadi saya menggunakan beberapa sumber data. Jadi saya punya banyak konten di WordPress, seperti posting blog semuanya di WordPress.
Beberapa dokumentasi juga ada di WordPress. Dan kemudian beberapa dokumentasi ada di file penurunan harga di repo GitHub. Untuk waktu yang lama saya menggunakan Gatsby, mungkin selama tiga tahun, saya menggunakan Gatsby, yang merupakan kerangka kerja JavaScript yang pada intinya memiliki lapisan data tempat Anda dapat menarik data dari berbagai sumber.
Jadi saya menggunakan itu, itu akan menarik data dari GitHub, menarik data dari WordPress menggunakan WPGraphQL juga dan memungkinkan saya menggunakan data itu untuk membuat template saya. Jadi saya menggunakannya selama beberapa tahun. Ada banyak masalah dengan lapisan data yang ingin saya hilangkan.
Jadi saya ingin menggunakan Next yang dibangun di atas Faust. Ini adalah kerangka kerja JavaScript lainnya, tetapi saya kira ada banyak bagian yang hilang. Selanjutnya, dan banyak kerangka kerja JavaScript ini memiliki gagasan bahwa kerangka kerja ujung depan Anda harus menentukan semua perutean, bukan? Namun jika Anda menggunakan CMS, CMS Anda menentukan perutean.
Jadi ada banyak masalah teknis untuk membuat hal-hal itu berjalan dengan baik, di mana ujung depan Anda memiliki pendapat tentang sesuatu dan ujung belakang Anda memiliki pendapat yang berbeda. Jadi seperti salah satu masalah yang saya coba selesaikan adalah membuat ujung depan saya mengenali bahwa URL tertentu adalah jenis hal tertentu, dan kemudian merender template yang mewakili hal itu.
Seperti posting blog memiliki template yang berbeda dari dokumen atau arsip pengguna atau apa pun. Jadi saya ingin ujung depan saya memiliki kemampuan untuk mengirim URL ke CMS, mendapatkan kembali datanya, tetapi memahami template apa yang harus dikembalikan. Di WordPress disebut hierarki template. Jadi ketika tim Faust bisa menyelesaikan masalah itu, saya seperti, ya, saya pindah ke Faust.
Jadi, ya, saya dapat mengambil beberapa konsep yang ada di inti WordPress, seperti tema PHP dan menggunakannya secara headless sehingga saya dapat menggunakan manfaat React dan JavaScript apa pun yang ingin saya gunakan di front end untuk membuat template saya situs, tetapi konsep masih akrab dari dunia WordPress.
DP: Chris, Anda menyebutkan bahwa Faust mengalami beberapa perubahan. Apa saja perubahan itu? Anda tahu, Jason menyebutkan mereka. Apa saja perubahan yang memungkinkan peningkatan ini?
CW: Itu selalu fokus pada WPGraphQL. Itu adalah hal lain yang benar-benar menjadi masalah. Misalnya, versi utama Faust terakhir menggunakan pustaka di bawahnya untuk berinteraksi dengan GraphQL yang disebut GQty, yang di atas kertas terdengar sangat keren. Gagasan dari tim Faust pada saat itu, mari kita abstrak saja, orang tidak perlu tahu cara membuat kueri yang rumit ini.
Kerangka kerja ini harus mengabstraksikannya untuk Anda. Di atas kertas itu terlihat sangat bagus, dalam praktiknya karena semua kerumitan data WordPress. Bahkan satu jenis posting dapat memiliki begitu banyak variasi. Mungkin Anda mencampurnya dengan kategori, mungkin semua hal yang berbeda. GQty tidak bisa menyalakannya.
Selain itu, saat dibuat dengan versi GQty, benar-benar tidak ada perhatian yang diberikan pada masalah perutean yang dibicarakan Jason. Siapa yang menangani perutean? WordPress ingin menangani perutean berdasarkan kontennya, ini adalah sistem manajemen konten, jadi semua perutean dan WordPress sebagian besar berbasis konten.
Next.js adalah kerangka kerja frontend, jadi semua perutean didasarkan pada, itu adalah paradigma yang sama sekali berbeda untuk dasar perutean. Apa yang bisa menjadi /Blog di Next mungkin tidak ada hubungannya dengan konten untuk blog. Ini akan menjadi satu set template. Ini akan menjadi bagian dari aplikasi yang dapat membangun sebuah blog.
Sedangkan / Blog di WordPress bisa sangat berarti, ini semua adalah posting blog. Dan paradigma itu saat membangun, jika Anda ingin menjadikan WordPress frontend yang sangat solid atau CMS berkemampuan headless, kami harus berurusan dengan perutean itu. Pergeseran lain ketika kami membuat ini, seperti yang saya katakan dengan versi GQty, tujuan kami adalah pengembang JavaScript yang harus menggunakan WordPress, yang tampaknya mulia sampai Anda menyadari bahwa ini adalah WP Engine.
Kami berurusan dengan agensi yang telah membangun di WordPress selama bertahun-tahun, yang sekarang karena berbagai alasan yang dapat kami bahas nanti, beralih ke hal yang tidak penting. Mereka tahu bagaimana melakukan pengembangan WordPress. Mereka mengerti bagaimana perutean template WordPress bekerja dan template bekerja, hal-hal seperti itu.
Kami perlu mengedepankan fitur-fitur tersebut, sehingga GraphQL dapat lebih mudah digunakan oleh pengembang WordPress. Dan itulah tujuan Faust di sini. Hirarki template, cukup membangun kembali apa yang dilakukan WordPress. Sekarang jika Anda ingin menggunakan perutean Berikutnya, ada cara untuk menimpanya di aplikasi sehingga Anda tidak kehilangan apa pun.
Tetapi bagi orang-orang yang menggunakan WordPress sebagai sistem manajemen konten sejati, yang mampu merutekan konten dengan manajemen konten, maka Faust akan menanganinya dengan lebih baik untuk Anda? Apakah itu masuk akal?
DP : Ya. Sangat. Anda tahu, saya pikir itu tempat yang bagus untuk istirahat sejenak di sini. Anda sedang mendengarkan Press This, podcast Komunitas WordPress bersama Chris Weigman dan Jason Bahl. Kami akan kembali berbicara tentang WordPress dan headless. Tetap disini.
DP: Kami kembali dengan Press This. Dan Anda tahu, Chris, tepat sebelum jeda itu Anda menyebutkan sesuatu, Anda menyebutkan semakin banyak perusahaan yang menjadi tanpa kepala, dan saya tahu bahwa WP Engine telah melakukan banyak penelitian untuk menunjukkan bahwa itulah masalahnya. Saya agak bertanya-tanya, tanpa kepala pasti memiliki reputasi sebagai sesuatu, saya pikir perusahaan, ketika saya berpikir tanpa kepala apakah saya berpikir dengan benar. Apakah itu yang tanpa kepala? Apakah ini hanya alat untuk perusahaan atau ini alat yang akan digunakan lebih banyak situs?
CW: Ya dan tidak. Sebagian besar tanpa kepala, terutama dengan WordPress saat ini, kerumitan yang terlibat di dalamnya berarti Anda mungkin memiliki tim lengkap yang membangun apa yang Anda butuhkan.
Ini bukan seseorang yang hanya menggunakan WordPress di luar kotak, bahwa Anda hanya menginginkan blog pribadi Anda. Itu bisa melakukan itu, tapi sejauh ini lift yang jauh lebih berat untuk bisa melakukan itu. Sama dengan Konten, sama dengan semua CMS lainnya. Jika Anda hanya menginginkan sesuatu yang sederhana, sesuatu yang, Anda tahu, jenis konten yang telah ada di web selama bertahun-tahun, headless mungkin lebih merepotkan daripada yang ingin Anda tangani sejauh ini.
Apakah ini benar-benar perusahaan? Lihat, tidak. Gatsby telah menangani masalah ini selama bertahun-tahun. Anda punya podcast lain nanti, Doc dengan Mastodon. Ini adalah komunitas yang telah saya ikuti selama beberapa tahun. Kebanyakan orang yang menggunakan variasi CMS tanpa kepala, terutama Gatsby, tapi ada Hugo. Ada berbagai jenis teknologi yang berbeda pada tingkat akar rumput.
Jadi Anda berakhir dengan pengguna akar rumput dan Anda berakhir dengan pengguna perusahaan untuk situs berat, sedangkan WordPress secara tradisional tampaknya jatuh dengan orang lain di antaranya. Itu adalah orang yang tidak ingin berurusan dengan file dan kode penurunan harga seperti yang mungkin dilakukan oleh pengguna Gatsby, atau Anda tahu, tetap saja Gatsby out of the box.
Tapi itu juga bukan seseorang yang memiliki seluruh tim yang terdiri dari 10 orang untuk membangun personal branding atau blog pribadi mereka. Ini mengeluarkan WordPress dari tengah itu dan memperluasnya ke kedua ujungnya dengan sangat mudah. Sekarang Anda dapat dengan mudah membangun di antara GraphQL, Anda memiliki semua data dan Anda memiliki serangkaian cara yang terus berkembang untuk menangani data tersebut.
Dan Faust membuatnya lebih mudah untuk memanfaatkannya dan sesuatu yang dapat Anda buat dalam sehari, bukan sebulan.
DP: Jason, Chris menyebutkan sesuatu yang ingin saya dengar pendapat Anda, saya mendengar bahwa ini mungkin tidak bagus untuk tim kecil, blogger kecil seperti saya, yang jelas masuk akal, saya tidak memerlukan WordPress tanpa kepala, tapi seperti , Saya kira yang saya ingin tahu adalah, apakah WordPress tanpa kepala akan lebih mahal karena saya harus memiliki iOS dev dan WordPress dev? Apakah lebih mahal atau entah bagaimana lebih hemat biaya?
JB: Mungkin tergantung pada apa yang Anda hasilkan, saya kira. Jika Anda melakukannya, seperti yang Anda sebutkan iOS, jika Anda melakukan aplikasi seluler asli, maksud saya jelas ada biaya yang terkait dengan itu, dan sebenarnya tidak ada cara yang baik untuk melakukannya jika Anda menggunakan data dari WordPress, lainnya daripada melakukannya tanpa kepala, karena Anda tahu, aplikasi asli tidak merender php, jadi Anda harus melakukannya tanpa kepala.
Namun jika Anda membangun untuk web sekarang di WordPress tradisional, Anda dapat mencari tema, Anda tahu tema gratis atau menemukan tema di pasar, mengunduhnya, memasangnya, dan Anda berangkat ke balapan. Kebanyakan orang akan menyesuaikannya dengan cara tertentu.
Jadi biasanya Anda akan dikenakan biaya pengembang, apakah Anda melakukannya sendiri atau orang lain. Salah satu hal dengan WordPress headless yang berbeda dari tema PHP tradisional, Apakah itu misalnya ketika saya meluncurkan wpgraphql.com baru, saya dapat menggunakan contoh WordPress yang sama yang menjalankan situs Gatsby saya.
Saya mendapatkan datanya, datanya keluar dan masuk ke situs Gatsby, saya dapat terus menerbitkan konten di CMS sambil mengembangkan frontend saya berikutnya untuk itu pada saat yang bersamaan. Dalam pengembangan WordPress tradisional, Anda biasanya harus memigrasikan situs Anda ke dalam lingkungan pementasan.
Aktifkan tema baru di lingkungan itu, bangun tema Anda di sana, tangani semacam periode pembekuan konten di mana Anda memberi tahu pembuat konten Anda, “Hei, hari ini Anda tidak dapat menerbitkan konten karena kami akan bermigrasi dan kemudian kami' kami akan menyetel instans WordPress baru, instans langsung.” Dan kemudian Anda harus masuk ke sana dan mulai membuat konten Anda dengan benar.
WordPress Tanpa Kepala, saya dapat membangun kembali situs saya di tumpukan frontend yang sama sekali berbeda tanpa mengganggu apa pun dalam contoh WordPress saya yang sebenarnya, ini adalah pemisahan data dan presentasi, bukan? Jadi saya bisa pergi, jika saya ingin menjelajahi teknologi panas berikutnya besok, seperti saya bisa mengarahkan pandangan saya ke Svelte daripada Next, dan saya tidak perlu mengubah apa pun di WordPress.
Jadi dalam beberapa kasus sebenarnya bisa lebih murah karena seluruh proses memutar server lain, membuat tim Anda berhenti menulis konten dan kemudian pindah ke contoh WordPress yang berbeda, dan kemudian mulai menerbitkan di sana, melakukan migrasi Delta, hal-hal seperti itu, itu ada biayanya juga.
Hal lain yang menarik juga adalah ekosistem JavaScript benar-benar terkirim. Penggerak umum, menurut pendapat saya, salah satu motivator umum untuk bergerak tanpa kepala adalah arsitektur berbasis komponen. Dan ada, semua jenis pustaka komponen dalam ekosistem React dan VUE, yang memungkinkan Anda untuk menggunakan kembali komponen di seluruh proyek.
Jadi agensi dapat membangun komponen umum yang mereka gunakan dalam proyek dan mereka dapat memperbaruinya di tempat terpusat, tetapi kemudian menginstalnya di beberapa proyek. Dengan WordPress, itu tidak semudah itu karena bagian template PHP Anda dan WordPress biasanya sangat erat digabungkan dengan proyek miliknya.
Di mana dengan headless Anda dapat memiliki paket MPM yang memiliki komponen tersebut dan beberapa proyek dapat memperbarui paket itu dan mendapatkan keuntungan sekaligus dengan sedikit usaha. Jadi saya pikir saat ini, saya akan mengatakan mungkin lebih mahal dan lebih banyak pekerjaan, tetapi menurut saya alat seperti Faust, yang tidak ada sampai saat ini, menurunkan upaya keseluruhan yang diperlukan untuk membangun tanpa kepala.
Dan saya pikir dalam waktu yang tidak lama lagi, mungkin lebih murah untuk membangun tanpa kepala daripada tidak tanpa kepala.
DP: Chris, apakah Anda memiliki sesuatu yang ingin Anda tambahkan ke agensi mana yang mungkin perlu dipikirkan terkait biaya WordPress headless?
CW: Saya pikir Jason benar-benar berhasil.
Dan satu hal yang saya suka tentang WPGraphQL adalah tim saya bekerja selanjutnya untuk memperluas WordPress ke arah itu dengan apa yang kami sebut, judul kerja kami adalah React Gutenberg Bridge, tetapi ini juga menjadi masalah di WordPress. Bagaimana Anda menggunakan kembali komponen ini? Saya tidak ingin menggunakan kata hanya komponen, karena itu tidak berlaku di sisi WordPress dengan cara yang sama seperti yang berlaku di sisi JavaScript, bukan?
Tapi bagaimana kita menggunakan kembali kode di seluruh proyek, tanpa kepala atau lainnya dengan WordPress dan tanpa kepala memungkinkan itu. Tapi saya pikir aman untuk mengatakan bahwa rata-rata blogger hanya mencoba untuk mengeluarkan blog foodie mereka, mungkin tidak berurusan dengan itu sendiri. Itu sangat banyak masalah agensi. Apakah itu lebih mahal?
Mungkin, mungkin tidak, tapi di situlah menjadi rumit ketika kita berbicara tentang di mana biayanya? Karena itu berbeda jenis bagaimana Anda ingin menggunakan data.
DP: Ya, tentu saja. Anda tahu, berasal dari latar belakang surat kabar, mengerjakan Weeklys di Twin Cities dan di Nashville, Jason, saya bisa membayangkan bagaimana rasanya memberi tahu 56 surat kabar Anda untuk tidak menerbitkan selama sehari.
Tidak ada berita hari ini, karena kami memperbarui situs.
JB: Ya. Dan maksud saya, kita memang melewati masa-masa itu, bukan? Seperti ketika saya dipekerjakan di sana, mereka tidak menggunakan WordPress dan sebagian dari pekerjaan saya adalah memindahkan mereka dari sistem lain ke WordPress. Jadi pasti ada hari-hari ketika itu seperti, baiklah, itu ditayangkan pada hari WordPress. Hentikan apa yang Anda lakukan. Benar.
Jadi pasti ada periode seperti itu atau kami juga harus berurusan dengan masalah seperti, oke, mereka menerbitkan di sistem lama sampai tengah malam tadi malam, tapi kami sudah menyiapkan WordPress dua hari sebelumnya. Jadi sekarang kita harus melakukan migrasi Delta dan memastikan semua data masih disinkronkan sehingga, Anda tahu, pasti ada biaya teknis dan manusia untuk proses tersebut.
DP: Ya. Dan menurut saya banyak juga, saat Anda masih menggunakan WordPress, Anda masih mendapatkan ekosistem yang bisa menghemat biaya ini. Anda tidak perlu membangun alat SEO.
Anda dapat menggunakan plugin Yoast SEO atau apapun. Meskipun Anda adalah situs Tanpa Kepala, saya berasumsi, sebagian besar plugin akan tetap berfungsi selama tidak menghadap ke depan.
JB: Ya. Itu sebenarnya hal yang menarik. Jadi Faust baru dibangun dengan arsitektur plugin itu sendiri. Jadi seperti di luar kotak, itu akan datang dengan klien, itu menggunakan klien Apollo sehingga Anda dapat mengambil data dari WPGraphQL, Anda bisa mendapatkan data WordPress Anda, tetapi Anda dapat membuat plugin sehingga, katakanlah Anda melakukannya, seperti Anda disebutkan, instal Yoast SEO di situs WordPress Anda.
Anda dapat menambahkan Plugin Yoast. Belum ada, tapi bisa segera. Anda dapat menambahkan plugin Yoast untuk Faust di frontend yang mengetahui apa yang harus dilakukan dengan data tersebut, bukan? Jadi akan ada kemampuan untuk orang-orang, beberapa mungkin kami produksi dan dukung, tetapi beberapa, komunitas dapat memproduksi dan mendukung plugin untuk sisi Faust juga, sehingga Anda hanya dengan satu baris kode, tambahkan plugin ini dapat dapatkan fungsionalitas seperti Yoast untuk ujung depan tanpa kepala Anda.
Itu adalah sesuatu yang menurut saya tidak ada konsep frontend tanpa kepala lainnya yang benar-benar memiliki konsep dengan cara yang sama seperti pendekatan Faust. Jadi menurut saya plugin, menurut saya itu adalah hal lain yang familiar bagi pengembang WordPress. Ini membawa konsep yang sudah dikenal dari WordPress, tetapi menjembataninya dengan tumpukan frontend JavaScript modern.
DP: itu a, itu tempat yang bagus untuk satu jeda terakhir di sini di Press This, dan saat kami kembali, kami akan mengakhiri percakapan kami dengan Chris Weigman dan Jason Bahl. Tetap disini.
DP: Anda sedang mendengarkan Press This, podcast Komunitas WordPress. Saya tuan rumah Anda, Doc Pop. Hari ini kita berbicara tentang WPGraphQL, Faust, dan bagaimana Anda dapat memberdayakan situs WordPress headless Anda. Tepat sebelum istirahat, kami berbicara tentang Faust dan plugin dan saya hanya akan mengajukan beberapa pertanyaan acak kepada Anda semua dan hanya ingin melihat apakah ada jawaban bagus yang muncul di sini.
Tapi Chris, saya agak bertanya-tanya, dengan Faust, apakah ada potensi, saya tahu ini adalah platform tanpa kepala, tetapi apakah ada potensi seperti tema WordPress Faust yang setidaknya membuat Anda siap dengan seperti, inilah plugin yang Anda butuhkan dan inilah semua yang ada di luar kotak.
CW: Tentu saja. Faktanya, kita sudah memilikinya. Kami menyebutnya sebagai Cetak Biru karena sangat cocok dengan Lokal. Kebanyakan orang akan melakukan semacam penyesuaian pada hal ini sebelum meluncurkannya di platform seperti WP Engine. Jadi kami meminjam nama Blueprints Lokal.
Untuk Faust baru kami memiliki satu yang disebut Portofolio, yang pada dasarnya adalah tema portofolio lengkap dan kami sedang mengerjakan scaffold kosong yang dapat digunakan agensi. Setelah Anda memahami berbagai hal, Anda mungkin ingin menyesuaikan semuanya sendiri. Jadi perancah akan menjadi praktik terbaik proyek, putar itu, dan kemudian Anda dapat melakukan semua hal Anda sendiri dengannya.
Jangka panjang kami telah berbicara banyak tentang toko tema tanpa kepala, ala Blueprints. Kami tidak memiliki tenaga kerja jadi itu agak jauh, tapi itu benar-benar sesuatu yang sedang kami pertimbangkan dan kami ingin melihatnya terjadi.
DP: Ya, itu keren untuk dipikirkan. Itu adalah jenis ekosistem yang sangat berbeda untuk dimasuki.
Dan tahukah Anda, Jason, saya telah mewawancarai Anda sebelumnya, dan saya yakin pertanyaan ini muncul setiap saat, tetapi setiap kali saya mendengar tentang WPGraphQL, saya pikir itu terdengar sangat mirip dengan apa yang dilakukan REST API. Sebenarnya, kedengarannya jauh lebih kuat daripada yang dilakukan REST API dan REST API adalah bagian dari inti dan saya hanya bertanya-tanya, apakah menurut Anda WPGraphQL harus menjadi bagian dari WordPress Core?
JB: Mungkin suatu hari nanti. Saya rasa kita belum sampai. Ketika banyak hal digabungkan di WordPress Core, mungkin dengan pengecualian Gutenberg, inovasi terhenti. REST API, misalnya, masih ada bug yang saya tunjukkan kepada orang-orang yang menurut saya masih ada sejak 2016. Jadi maksud saya, saat semuanya masuk ke inti, Anda menambahkan set fitur ke 40 persen web dan jadi membuat perubahan harus dilakukan dengan kecepatan yang jauh lebih lambat, di mana jika itu adalah sebuah plugin, Anda dapat membiarkan orang memilih versi yang mereka inginkan dan Anda dapat mengulang lebih cepat karena mereka dapat memilih versi mana yang terbaik untuk proyek mereka.
Di mana intinya, jika Anda memperbarui inti dan itu termasuk perubahan yang merusak, Anda mungkin baru saja merusak 40 persen web. Jadi GraphQL adalah spesifikasi, tidak ada hubungannya dengan WordPress juga.
Benar. Dan spesifikasi GraphQL masih terus berkembang. Dan karena itu terus berkembang, kami ingin mengikuti spesifikasi GraphQL terbaru dan terhebat. Jika kita menggabungkan, katakanlah, WPGraphQL menjadi Core hari ini, dan GraphQL terus berkembang, WordPress akan terjebak di GraphQL edisi 2022 di mana seluruh dunia menggunakan versi 2030 atau apa pun. Bagi saya, saya pikir mungkin masuk akal pada titik tertentu untuk membuatnya dikenali seperti WPCLI sebagai cara resmi untuk melakukan hal X.
Seperti Anda dapat membangun klien CLI Anda sendiri untuk WordPress, tetapi komunitas tersebut mengakui bahwa WPCLI adalah hal yang resmi. Itu bukan bagian dari WordPress Core tetapi diakui oleh WordPress Foundation dan sebagian besar komunitas WordPress sebagai hal resmi. Jadi mungkin bagus di beberapa titik untuk WPGraphQL dikenali seperti itu, seperti jika Anda akan menggunakan WordPress tanpa kepala, lakukan dengan cara ini.
Itu masih akan tetap menjadi plugin. Itu pikiran saya. Mungkin ada saatnya GraphQL terasa sempurna dan tidak benar-benar diulang dan mungkin saat itu kami mempertimbangkannya. Tetapi saat ini ada hal-hal yang datang ke spesifikasi GraphQL yang akan menyebabkan API mengalami perubahan yang dapat merusak.
Jadi melakukannya sebagai plugin bagi saya masih masuk akal.
DP: Tepat. Dan ya, Anda telah menyebutkan WPCLI dan saya terus lupa, seperti mereka, mereka merasa itu bagian dari inti. Apa pun rasanya, itu seperti resmi. Jadi ya, ini seperti, oh ya, seperti hal independen ini, seperti WPGraphQL saat ini.
Itu analogi yang bagus. Jadi saya akan, saya akan menyelesaikannya di sini. Sangat menyenangkan mengobrol dengan kalian berdua. Jika pendengar tertarik untuk mengikuti salah satu dari Anda, Anda dapat mengikuti @JasonBahl dan @ChrisWeigman. Kami akan menempatkan pegangan Twitter di deskripsi acara jika kami bisa. Anda telah mendengarkan Press This, podcast Komunitas WordPress di WMR.
Pada episode minggu depan, kita akan memiliki Anne McCarthy, penghubung produk di Otomatis, berbicara tentang perubahan Pengeditan situs dan 6.1 dan apa yang akan terjadi dengan 6.2. Sekali lagi terima kasih telah mendengarkan Press This.
Anda dapat mengikuti petualangan saya dengan majalah Torque di Twitter @thetorquemag atau Anda dapat mengunjungi torquemag.io tempat kami menyumbangkan tutorial dan video serta wawancara seperti ini setiap hari. Jadi periksa torquemag.io atau ikuti kami di Twitter. Anda bisa berlangganan Press This di Red Circle, iTunes, Spotify, atau Anda bisa mengunduhnya langsung di wmr.fm setiap minggunya. Saya tuan rumah Anda Doctor Popular Saya mendukung komunitas WordPress melalui peran saya di WP Engine. Dan saya suka menyoroti anggota komunitas setiap minggu di Press This.