Membuat GraphQL Bekerja Di WordPress

Headless WordPress tampaknya sedang populer akhir-akhir ini, dengan banyak perkembangan baru yang terjadi hanya dalam beberapa minggu terakhir. Salah satu alasan ledakan aktivitas adalah rilis WPGraphQL versi 1.0, server GraphQL untuk WordPress.

WPGraphQL menyediakan API GraphQL: cara untuk mengambil data dari, dan mengirim data ke, situs WordPress. Ini memungkinkan kami untuk memisahkan pengalaman mengelola konten kami, yang dilakukan melalui WordPress, dari merender situs web, di mana kami dapat menggunakan pustaka kerangka kerja pilihan kami ( React , Vue.js , Gatsby , Next.js , atau ada yang lain).

Sampai saat ini, WPGraphQL adalah satu-satunya server GraphQL untuk WordPress. Tetapi sekarang plugin lain yang serupa tersedia: API GraphQL untuk WordPress , dibuat oleh saya.

Kedua plugin ini memiliki tujuan yang sama: menyediakan API GraphQL ke situs WordPress. Anda mungkin bertanya-tanya: Mengapa ada plugin lain ketika sudah ada WPGraphQL? Apakah kedua plugin ini melakukan hal yang sama? Atau apakah mereka untuk situasi yang berbeda?

Izinkan saya mengatakan ini dulu: WPGraphQL berfungsi dengan baik. Saya tidak membuat plugin saya karena ada masalah dengannya.

Saya membangun GraphQL API untuk WordPress karena saya telah mengerjakan mesin untuk mengambil data secara efisien , yang kebetulan sangat cocok untuk GraphQL. Jadi, kemudian saya berkata pada diri saya sendiri, "Mengapa tidak?", Dan saya membangunnya. (Dan juga beberapa alasan lainnya .)

Kedua plugin memiliki arsitektur yang berbeda, memberikan karakteristik yang berbeda, yang membuat tugas tertentu lebih mudah dicapai dengan satu plugin atau lainnya.

Dalam artikel ini, saya akan menjelaskan, dari sudut pandang saya sendiri tetapi seobyektif mungkin, kapan WPGraphQL adalah cara yang tepat dan kapan API GraphQL untuk WordPress adalah pilihan yang lebih baik.

Gunakan WPGraphQL Jika: Menggunakan Gatsby

Jika Anda membangun situs web menggunakan Gatsby , maka hanya ada satu pilihan: WPGraphQL.

Alasannya adalah hanya WPGraphQL yang memiliki plugin sumber Gatsby untuk WordPress . Selain itu, pembuat WPGraphQL, Jason Bahl, sampai saat ini dipekerjakan oleh Gatsby, sehingga kami dapat sepenuhnya percaya bahwa plugin ini akan sesuai dengan kebutuhan Gatsby.

Gatsby menerima semua data dari situs WordPress, dan sejak saat itu, logika aplikasinya akan sepenuhnya berada di pihak Gatsby, bukan di WordPress '. Oleh karena itu, tidak ada penambahan WPGraphQL (seperti penambahan potensi @stream atau @defer arahan) akan membuat banyak perbedaan.

WPGraphQL sudah sebagus yang dibutuhkan Gatsby.

Gunakan WPGraphQL Jika: Menggunakan Salah Satu Kerangka Kerja Tanpa Kepala Baru

Seperti yang saya sebutkan, akhir-akhir ini ada kesibukan di WordPress headless space mengenai beberapa kerangka kerja baru dan proyek pemula, semuanya berdasarkan Next.js :

Jika Anda perlu menggunakan salah satu kerangka kerja tanpa kepala baru ini, Anda harus menggunakan WPGraphQL, karena semuanya dibuat di atas plugin ini.

Itu agak disayangkan: Saya sangat ingin GraphQL API untuk WordPress dapat memberdayakannya juga. Tetapi agar itu terjadi, kerangka kerja ini perlu beroperasi dengan GraphQL melalui antarmuka , sehingga kami dapat menukar server GraphQL.

Saya agak berharap bahwa kerangka kerja ini akan menempatkan antarmuka seperti itu pada tempatnya. Saya bertanya tentang hal itu di papan diskusi Headless WordPress Framework dan diberi tahu bahwa itu mungkin dipertimbangkan. Saya juga bertanya di papan diskusi Pemula WordPress WebDevStudios 'Next.js, tetapi sayangnya, pertanyaan saya segera dihapus, tanpa jawaban. (Tidak menyemangati, bukan?)

Jadi WPGraphQL saat itu, saat ini dan di masa mendatang.

Gunakan Salah Satu (Atau Tidak Keduanya) Jika: Menggunakan Frontitas

Frontity adalah kerangka kerja React untuk WordPress. Ini memungkinkan Anda untuk membangun aplikasi berbasis React yang dikelola di bagian belakang melalui WordPress. Bahkan membuat posting blog menggunakan editor WordPress didukung di luar kotak.

Frontity mengelola status aplikasi, tanpa membocorkan bagaimana data diperoleh. Meskipun secara default didasarkan pada REST, Anda juga dapat menjalankannya melalui GraphQL dengan mengimplementasikan plugin sumber yang sesuai .

Beginilah cara Frontity pintar: Plugin sumber adalah antarmuka untuk berkomunikasi dengan penyedia data. Saat ini, satu-satunya plugin sumber yang tersedia adalah plugin untuk REST API WordPress . Tetapi siapa pun dapat menerapkan plugin sumber untuk WPGraphQL atau API GraphQL untuk WordPress. (Ini adalah pendekatan yang saya ingin framework berbasis Next.js direplikasi.)

Kesimpulan : Baik WPGraphQL maupun GraphQL API menawarkan keuntungan apa pun dibandingkan yang lain untuk bekerja dengan Frontity, dan keduanya memerlukan upaya awal untuk memasangnya.

Gunakan WPGraphQL Jika: Membuat Situs Statis

Pada dua bagian pertama, kesimpulannya sama: Gunakan WPGraphQL. Tetapi tanggapan saya terhadap kesimpulan ini berbeda: Meskipun dengan Gatsby saya tidak menyesal, dengan Next.js saya merasa terdorong untuk melakukan sesuatu.

Mengapa demikian?

Perbedaannya adalah, meskipun Gatsby murni generator situs statis, Next.js dapat memberi daya pada situs web statis dan langsung.

Saya sebutkan bahwa WPGraphQL sudah cukup bagus untuk Gatsby. Pernyataan ini sebenarnya dapat diperluas: WPGraphQL sudah cukup baik untuk generator situs statis apa pun . Setelah generator situs statis mendapatkan data dari situs WordPress, itu cukup banyak diselesaikan dengan WordPress.

Meskipun GraphQL API untuk WordPress menawarkan fitur tambahan, kemungkinan besar tidak akan membuat perbedaan pada generator situs statis.

Oleh karena itu, karena WPGraphQL sudah cukup baik, dan telah sepenuhnya memetakan skema GraphQL (yang masih dalam proses untuk API GraphQL untuk WordPress), maka WPGraphQL adalah opsi yang paling sesuai, sekarang dan di masa mendatang.

Gunakan API GraphQL Jika: Menggunakan GraphQL di Situs Web Langsung (yaitu Non-Statis)

Sekarang, situasi di atas berubah jika kita ingin GraphQL mengambil data dari situs web langsung, seperti saat menjalankan aplikasi seluler atau merencanakan data waktu nyata di situs web (misalnya, untuk menampilkan analitik) atau menggabungkan pendekatan statis dan langsung. di situs web yang sama.

Misalnya, kita telah membangun blog statis sederhana menggunakan salah satu kerangka kerja Next.js, dan kita ingin mengizinkan pengguna untuk menambahkan komentar ke posting blog. Bagaimana seharusnya tugas ini ditangani?

Kami memiliki dua opsi: statis dan langsung (atau dinamis). Jika kita memilih statis, maka komentar akan diberikan bersama-sama dengan seluruh situs web. Kemudian, setiap kali komentar ditambahkan, kita harus memicu webhook untuk membuat ulang dan menerapkan ulang situs web tersebut.

Pendekatan ini memiliki beberapa ketidaknyamanan. Proses regenerasi dan penerapan ulang bisa memakan waktu beberapa menit, selama itu komentar baru tidak akan tersedia. Selain itu, jika situs web menerima banyak komentar dalam sehari, pendekatan statis akan membutuhkan lebih banyak waktu pemrosesan server, yang dapat menjadi mahal (beberapa perusahaan hosting mengenakan biaya berdasarkan waktu server).

Dalam situasi ini, masuk akal untuk merender situs web secara statis tanpa komentar, dan kemudian mengambil komentar dari situs langsung dan merendernya secara dinamis di klien.

Untuk ini, Next.js direkomendasikan daripada Gatsby . Ini dapat menangani pendekatan statis dan langsung dengan lebih baik, termasuk mendukung keluaran yang berbeda untuk pengguna dengan kemampuan berbeda.

Kembali ke diskusi GraphQL: Mengapa saya merekomendasikan API GraphQL untuk WordPress saat menangani data langsung? Saya lakukan karena server GraphQL dapat berdampak langsung pada aplikasi, terutama dalam hal kecepatan dan keamanan .

Untuk situs web yang murni statis, situs web WordPress dapat dirahasiakan (bahkan mungkin tinggal di laptop pengembang), jadi aman. Dan pengguna tidak akan menunggu respon dari server, jadi kecepatan tidak selalu penting.

Untuk situs langsung, API GraphQL akan dipublikasikan, sehingga keamanan data menjadi masalah. Kita harus memastikan bahwa tidak ada pelaku jahat yang dapat mengaksesnya. Selain itu, pengguna akan menunggu jawaban, jadi kecepatan menjadi pertimbangan penting.

Dalam hal ini, GraphQL API untuk WordPress memiliki beberapa keunggulan dibandingkan WPGraphQL .

WPGraphQL menerapkan langkah-langkah keamanan, seperti menonaktifkan introspeksi secara default . Tetapi GraphQL API untuk WordPress melangkah lebih jauh, dengan menonaktifkan satu titik akhir secara default (bersama dengan beberapa ukuran lainnya ). Ini dimungkinkan karena GraphQL API untuk WordPress menawarkan kueri tetap secara native.

Untuk kecepatan, persisted queries juga membuat API lebih cepat, karena responnya kemudian bisa di- cache melalui cache HTTP di beberapa lapisan, termasuk klien, jaringan pengiriman konten, dan server.

Alasan ini membuat API GraphQL untuk WordPress lebih cocok dalam menangani situs web langsung.

Gunakan API GraphQL Jika: Mengekspos Data Berbeda untuk Pengguna atau Aplikasi Berbeda

WordPress adalah sistem manajemen konten serbaguna, mampu mengelola konten untuk banyak aplikasi dan dapat diakses oleh berbagai jenis pengguna.

Bergantung pada konteksnya, kami mungkin memerlukan API GraphQL kami untuk mengekspos data yang berbeda, seperti:

  • mengekspos data tertentu kepada pengguna berbayar tetapi tidak untuk pengguna yang tidak dibayar,
  • mengekspos data tertentu ke aplikasi seluler tetapi tidak ke situs web.

Untuk mengekspos data yang berbeda, kami perlu menyediakan versi skema GraphQL yang berbeda .

WPGraphQL memungkinkan kita untuk memodifikasi skema (misalnya, kita dapat menghapus field terdaftar ). Tetapi prosesnya tidak langsung: Modifikasi skema harus diberi kode, dan tidak mudah untuk memahami siapa yang mengakses apa dan di mana (misalnya, semua skema akan tetap tersedia di bawah titik akhir tunggal, /graphql ).

Sebaliknya, GraphQL API untuk WordPress secara native mendukung kasus penggunaan ini: Ini menawarkan titik akhir khusus , yang dapat mengekspos data berbeda untuk konteks yang berbeda, seperti:

  • /graphql/mobile-app dan /graphql/website ,
  • /graphql/pro-users dan /graphql/regular-users .

Setiap titik akhir khusus dikonfigurasi melalui daftar kontrol akses , untuk menyediakan bidang akses pengguna terperinci demi bidang, serta mode API publik dan pribadi untuk menentukan apakah data meta skema tersedia untuk semua orang atau hanya untuk pengguna yang berwenang.

Fitur-fitur ini langsung terintegrasi dengan editor WordPress (yaitu Gutenberg). Jadi, membuat skema yang berbeda dilakukan secara visual, mirip dengan membuat postingan blog. Ini berarti bahwa setiap orang dapat menghasilkan skema GraphQL kustom , tidak hanya pengembang.

API GraphQL untuk WordPress memberikan, saya yakin, solusi alami untuk kasus penggunaan ini.

Gunakan API GraphQL Jika: Berinteraksi dengan Layanan Eksternal

GraphQL bukan hanya API untuk mengambil dan memposting data. Sebagai penting (meskipun sering diabaikan), itu juga dapat memproses dan mengubah data – misalnya, dengan memasukkannya ke beberapa layanan eksternal, seperti mengirim teks ke API pihak ketiga untuk memperbaiki kesalahan tata bahasa atau mengunggah gambar ke pengiriman konten jaringan.

Sekarang, apa cara terbaik bagi GraphQL untuk berkomunikasi dengan layanan eksternal? Menurut pendapat saya, ini paling baik dilakukan melalui arahan , diterapkan saat membuat atau mengambil data (tidak seperti cara filter WordPress beroperasi).

Saya tidak tahu seberapa baik WPGraphQL berinteraksi dengan layanan eksternal, karena dokumentasinya tidak menyebutkannya, dan basis kode tidak menawarkan contoh arahan atau dokumen apa pun cara membuatnya.

Sebaliknya, GraphQL API untuk WordPress memiliki dukungan yang kuat untuk arahan . Setiap direktif dalam kueri dieksekusi hanya sekali secara total (sebagai lawan sekali per bidang dan / atau objek). Kemampuan ini memungkinkan komunikasi yang sangat efisien dengan API eksternal, dan mengintegrasikan API GraphQL dalam layanan cloud.

Misalnya, kueri ini % 0A% 20% 20% 20% 20 kutipan% 20% 40 diterjemahkan (dari% 3A% 22en% 22% 2Cto% 3A% 22es% 22)% 0A% 20% 20% 7D% 0A% 7D) menunjukkan panggilan ke Google Translate API melalui @translate , untuk menerjemahkan judul dan kutipan dari banyak posting dari bahasa Inggris ke bahasa Spanyol. Semua bidang untuk semua posting diterjemahkan bersama, dalam satu panggilan.

GraphQL API untuk WordPress adalah pilihan yang wajar untuk kasus penggunaan ini.

Catatan : Faktanya, mesin yang menjadi dasar GraphQL API untuk WordPress, GraphQL by PoP, secara khusus dirancang untuk menyediakan kemampuan manipulasi data tingkat lanjut. Itulah salah satu ciri khasnya. Untuk contoh ekstrem tentang apa yang dapat dicapai, lihat panduan tentang " Mengirim Buletin yang Dilokalkan, Pengguna demi Pengguna ".

Gunakan WPGraphQL Jika: Anda Ingin Komunitas Dukungan

Jason Bahl telah melakukan pekerjaan luar biasa dalam mengumpulkan komunitas di sekitar WPGraphQL. Akibatnya, jika Anda perlu memecahkan masalah API GraphQL Anda, kemungkinan besar Anda akan menemukan seseorang yang dapat membantu Anda.

Dalam kasus saya, saya masih berusaha untuk membuat komunitas pengguna di sekitar API GraphQL untuk WordPress, dan itu pasti jauh dari WPGraphQL.

Gunakan API GraphQL Jika: Anda Suka Inovasi

Saya menyebut API GraphQL untuk WordPress sebagai server GraphQL yang "berwawasan ke depan". Alasannya adalah saya sering menelusuri daftar permintaan untuk spesifikasi GraphQL dan mengimplementasikan beberapa di antaranya jauh-jauh hari (terutama yang saya rasa memiliki ketertarikan atau yang dapat saya dukung dengan sedikit usaha).

Saat ini, GraphQL API untuk WordPress mendukung beberapa fitur inovatif (seperti beberapa eksekusi kueri dan skema namespacing ), ditawarkan sebagai opt-in, dan ada rencana untuk beberapa lagi .

Gunakan WPGraphQL Jika: Anda Membutuhkan Skema Lengkap

WPGraphQL telah sepenuhnya memetakan model data WordPress , termasuk:

  • posting dan halaman,
  • jenis posting kustom,
  • kategori dan tag,
  • taksonomi khusus,
  • media,
  • menu,
  • pengaturan,
  • pengguna,
  • komentar,
  • plugin,
  • tema,
  • widget.

API GraphQL untuk WordPress secara progresif memetakan model data dengan setiap rilis baru. Sampai hari ini, daftarnya termasuk:

  • posting dan halaman,
  • jenis posting kustom,
  • kategori dan tag,
  • taksonomi khusus,
  • media,
  • menu,
  • pengaturan,
  • pengguna,
  • komentar.

Jadi, jika Anda perlu mengambil data dari plugin, tema, atau widget, saat ini hanya WPGraphQL yang berfungsi.

Gunakan WPGraphQL Jika: Anda Membutuhkan Ekstensi

WPGraphQL menawarkan ekstensi untuk banyak plugin , termasuk Advanced Custom Fields, WooCommerce, Yoast, Gravity Forms.

GraphQL API untuk WordPress menawarkan ekstensi untuk Manajer Acara, dan itu akan terus menambahkan lebih banyak setelah rilis plugin versi 1.0.

Gunakan Either If: Membuat Blok untuk Editor WordPress

Baik WPGraphQL dan GraphQL API untuk WordPress saat ini sedang berupaya mengintegrasikan GraphQL dengan Gutenberg.

Jason Bahl telah menjelaskan tiga pendekatan yang dapat digunakan untuk integrasi ini. Namun, karena semuanya memiliki masalah, dia menganjurkan pengenalan registri sisi server ke WordPress, untuk mengaktifkan identifikasi blok Gutenberg yang berbeda untuk skema GraphQL.

GraphQL API untuk WordPress juga memiliki pendekatan untuk berintegrasi dengan Gutenberg , berdasarkan strategi "buat sekali, terbitkan di mana-mana". Ini mengekstrak data blok dari konten yang disimpan , dan menggunakan satu Block untuk mewakili semua blok. Pendekatan ini dapat menghindari kebutuhan akan registri sisi server yang diusulkan.

Solusi WPGraphQL dapat dianggap tentatif, karena akan bergantung pada komunitas yang menerima penggunaan registri sisi server, dan kami tidak tahu apakah atau kapan itu akan terjadi.

Untuk GraphQL API untuk WordPress, solusinya akan bergantung sepenuhnya pada dirinya sendiri, dan ini memang sedang dalam proses.

Karena memiliki peluang lebih tinggi untuk segera menghasilkan solusi yang berfungsi, saya cenderung merekomendasikan API GraphQL untuk WordPress . Namun, mari kita tunggu hingga solusi diterapkan sepenuhnya (dalam beberapa minggu, sesuai rencana) untuk memastikannya berfungsi sebagaimana mestinya, dan kemudian saya akan memperbarui rekomendasi saya.

Gunakan API GraphQL Jika: Mendistribusikan Blok Melalui Plugin

Saya menyadari: Tidak banyak plugin (jika ada) yang tampaknya menggunakan GraphQL di WordPress.

Jangan salah paham: WPGraphQL telah melampaui 10.000 instalasi. Tapi saya percaya bahwa itu sebagian besar adalah instalasi untuk menyalakan Gatsby (untuk menjalankan Gatsby) atau untuk menyalakan Next.js (untuk menjalankan salah satu kerangka kerja tanpa kepala).

Demikian pula WPGraphQL memiliki banyak ekstensi, seperti yang saya jelaskan sebelumnya. Tetapi ekstensi itu hanya itu: ekstensi. Mereka bukan plugin mandiri.

Misalnya, ekstensi WPGraphQL untuk WooCommerce bergantung pada plugin WPGraphQL dan WooCommerce. Jika salah satu dari mereka tidak diinstal, maka ekstensi tidak akan berfungsi, dan tidak apa-apa. Tetapi WooCommerce tidak memiliki pilihan untuk mengandalkan WPGraphQL untuk bekerja; karenanya, tidak akan ada GraphQL di plugin WooCommerce.

Pemahaman saya adalah bahwa tidak ada plugin yang menggunakan GraphQL untuk menjalankan fungsionalitas untuk WordPress itu sendiri atau, secara khusus, untuk memberi daya pada blok Gutenberg mereka.

Alasannya sederhana: Baik WPGraphQL maupun GraphQL API untuk WordPress adalah bagian dari inti WordPress. Dengan demikian, tidak mungkin untuk mengandalkan GraphQL seperti plugin dapat mengandalkan REST API WordPress. Akibatnya, plugin yang menerapkan blok Gutenberg hanya dapat menggunakan REST untuk mengambil data untuk blok mereka, bukan GraphQL.

Tampaknya, solusinya adalah menunggu solusi GraphQL (kemungkinan besar WPGraphQL) ditambahkan ke inti WordPress. Tapi siapa yang tahu berapa lama waktu yang dibutuhkan? Enam bulan? Tahun? Dua tahun? Lebih lama?

Kami tahu bahwa WPGraphQL sedang dipertimbangkan untuk inti WordPress karena Matt Mullenweg telah mengisyaratkan hal itu. Tetapi begitu banyak hal harus terjadi sebelum itu: mengubah versi PHP minimum menjadi 7.1 (dibutuhkan oleh WPGraphQL dan GraphQL API untuk WordPress), serta memiliki decoupling, pemahaman, dan peta jalan yang jelas untuk fungsionalitas apa yang akan didukung oleh GraphQL.

(Pengeditan situs lengkap, saat ini sedang dalam pengembangan, didasarkan pada REST. Bagaimana dengan fitur utama berikutnya, blok multibahasa, yang akan dibahas dalam fase 4 Gutenberg? Jika bukan itu, fitur apa yang akan digunakan?)

Setelah menjelaskan masalahnya, mari pertimbangkan solusi potensial – solusi yang tidak perlu menunggu!

Beberapa hari yang lalu, saya mendapat kesadaran lain: Dari GraphQL API untuk basis kode WordPress, saya dapat menghasilkan versi yang lebih kecil, hanya berisi mesin GraphQL dan tidak ada yang lain (tidak ada UI, tidak ada titik akhir khusus, tidak ada cache HTTP, tidak ada kontrol akses, tidak ada apa-apa). Dan versi ini dapat didistribusikan sebagai ketergantungan Komposer, sehingga plugin dapat menginstalnya untuk memberi daya pada blok mereka sendiri.

Kunci dari pendekatan ini adalah komponen ini harus digunakan khusus untuk plugin, tidak untuk dibagikan dengan orang lain. Jika tidak, dua plugin yang mereferensikan komponen ini dapat mengubah skema sedemikian rupa sehingga keduanya saling menggantikan.

Untungnya, saya baru-baru ini menyelesaikan Scoping GraphQL API untuk WordPress . Jadi, saya tahu bahwa saya dapat mencakupnya sepenuhnya, menghasilkan versi yang tidak akan bertentangan dengan kode lain di situs web.

Artinya, ini akan berfungsi untuk semua kombinasi peristiwa :

  • Jika plugin yang berisi komponen adalah satu-satunya yang menggunakannya;
  • Jika GraphQL API untuk WordPress juga diinstal di situs web yang sama;
  • Jika plugin lain yang juga menyematkan komponen ini dipasang di situs web;
  • Jika dua plugin yang menyematkan komponen merujuk ke versi komponen yang sama atau versi yang berbeda.

Dalam setiap situasi, plugin akan memiliki mesin GraphQL pribadi mandiri yang dapat diandalkan sepenuhnya untuk memberi daya pada blok Gutenberg (dan kami tidak perlu khawatir akan adanya konflik).

Komponen ini, yang disebut Private GraphQL API , akan siap dalam beberapa minggu. (Saya sudah mulai mengerjakannya .)

Oleh karena itu, rekomendasi saya adalah, jika Anda ingin menggunakan GraphQL untuk memberi daya pada blok Gutenberg di plugin Anda, harap tunggu beberapa minggu, lalu periksa API GraphQL untuk adik WordPress, API GraphQL Pribadi.

Kesimpulan

Meskipun saya memiliki skin dalam game tersebut, saya rasa saya telah berhasil menulis artikel yang sebagian besar bersifat objektif.

Saya telah jujur dalam menyatakan mengapa dan kapan Anda perlu menggunakan WPGraphQL. Demikian pula, saya telah jujur menjelaskan mengapa API GraphQL untuk WordPress tampaknya lebih baik daripada WPGraphQL untuk beberapa kasus penggunaan.

Secara umum, kami dapat meringkas sebagai berikut:

  • Gunakan WPGraphQL statis, atau aktifkan API GraphQL untuk WordPress.
  • Mainkan dengan aman dengan WPGraphQL, atau investasikan (untuk hasil yang berpotensi layak) di API GraphQL untuk WordPress.

Pada catatan terakhir, saya berharap kerangka kerja Next.js dirancang ulang untuk mengikuti pendekatan yang sama yang digunakan oleh Frontity: di mana mereka dapat mengakses antarmuka untuk mengambil data yang mereka butuhkan, daripada menggunakan implementasi langsung dari beberapa solusi tertentu ( yang saat ini adalah WPGraphQL). Jika itu terjadi, pengembang dapat memilih server dasar mana yang akan digunakan (apakah WPGraphQL, API GraphQL untuk WordPress, atau beberapa solusi lain yang diperkenalkan di masa mendatang), berdasarkan kebutuhan mereka – dari proyek ke proyek.

Tautan Berguna

April 20, 2021

codeorayo

Ampuh! Ini rahasia mengembangkan aplikasi secara instan, tinggal download dan kembangkan. Gabung sekarang juga! Premium Membership [PRIVATE] https://premium.codeorayo.com

Leave a Reply

Your email address will not be published. Required fields are marked *