WordPress'te GraphQL Çalışması Yapmak

Başsız WordPress, son birkaç hafta içinde gerçekleşen birçok yeni gelişme ile son zamanlarda moda gibi görünüyor. Faaliyetteki patlamanın nedenlerinden biri, WordPress için bir GraphQL sunucusu olan WPGraphQL'nin 1.0 sürümünün piyasaya sürülmesidir.

WPGraphQL, bir GraphQL API'si sağlar: bir WordPress web sitesinden veri almanın ve bu web sitesine veri göndermenin bir yolu. WordPress aracılığıyla gerçekleştirilen içeriğimizi yönetme deneyimimizi, seçtiğimiz çerçevenin kitaplığını kullanabileceğimiz web sitesini oluşturmaktan ayırmamızı sağlar (React, Vue.js, Gatsby, Next.js veya herhangi bir başka).

Yakın zamana kadar, WPGraphQL, WordPress için tek GraphQL sunucusuydu. Ama şimdi böyle başka bir eklenti mevcut: WordPress için GraphQL API, benim tarafımdan yazılmıştır.

Bu iki eklenti aynı amaca hizmet eder: bir WordPress web sitesine GraphQL API'si sağlamak. Merak ediyor olabilirsiniz: Zaten WPGraphQL varken neden başka bir eklenti? Bu iki eklenti aynı şeyi mi yapıyor? Yoksa farklı durumlar için mi?

Önce şunu söylememe izin verin: WPGraphQL harika çalışıyor. Eklentimi herhangi bir sorun nedeniyle oluşturmadım.

GraphQL için çok uygun olan verileri verimli bir şekilde almak için bir motor üzerinde çalıştığım için WordPress için GraphQL API'yi oluşturdum. Sonra kendi kendime “Neden olmasın?” dedim ve inşa ettim. (Ayrıca birkaç neden daha.)

İki eklentinin farklı mimarileri vardır ve onlara farklı özellikler verir, bu da belirli görevleri bir eklenti veya diğeriyle gerçekleştirmeyi kolaylaştırır.

Bu makalede, WPGraphQL'nin ne zaman gidilecek yol olduğunu ve WordPress için GraphQL API'nin ne zaman daha iyi bir seçim olduğunu kendi bakış açımdan mümkün olduğunca nesnel olarak anlatacağım.

Aşağıdaki durumlarda WPGraphQL kullanın: Gatsby'yi Kullanma

Gatsby kullanarak bir web sitesi oluşturuyorsanız, tek bir seçeneğiniz vardır: WPGraphQL.

Bunun nedeni, yalnızca WPGraphQL'nin WordPress için Gatsby kaynak eklentisine sahip olmasıdır. Ek olarak, WPGraphQL'in yaratıcısı Jason Bahl, yakın zamana kadar Gatsby tarafından istihdam edildi, bu yüzden bu eklentinin Gatsby'nin ihtiyaçlarını karşılayacağına tamamen güvenebiliriz.

Gatsby, WordPress web sitesinden tüm verileri alır ve o andan itibaren, uygulamanın mantığı WordPress'te değil, tamamen Gatsby'nin tarafında olacaktır'. Bu nedenle, WPGraphQL'ye yapılan hiçbir ekleme (örneğin @stream veya @defer yönergelerinin potansiyel eklemeleri gibi) çok fazla bir fark yaratmaz.

WPGraphQL, Gatsby'nin olması gerektiği kadar iyidir.

Aşağıdaki durumlarda WPGraphQL kullanın: Yeni Başsız Çerçevelerden Birini Kullanma

Bahsettiğim gibi, son zamanlarda WordPress başsız alanında, tümü Next.js'ye dayanan birkaç yeni çerçeve ve başlangıç ​​projesiyle ilgili bir hareketlilik oldu:

• Colby Fayock, Next.js WordPress Starter'ı yarattı.
• WebDevStudios, kendi Next.js WordPress Starter'ını başlattı.
• WP Engine, hizmetine başsız WordPress web sitelerini barındırmak ve dağıtmak için güç veren Başsız WordPress Çerçevesini oluşturdu.

Bu yeni başsız çerçevelerden herhangi birini kullanmanız gerekiyorsa, o zaman WPGraphQL kullanmanız gerekecektir, çünkü hepsi bu eklentinin üzerine inşa edilmiştir.

Bu biraz talihsizlik: WordPress için GraphQL API'sinin onlara da güç verebilmesini gerçekten çok isterim. Ancak bunun olması için, bu çerçevelerin GraphQL sunucularını değiştirebilmemiz için bir arabirim aracılığıyla GraphQL ile çalışması gerekir.

Bu çerçevelerden herhangi birinin böyle bir arayüzü yerine koyacağından biraz umutluyum. Bunu Headless WordPress Framework tartışma panosunda sordum ve değerlendirilebileceği söylendi. Ayrıca WebDevStudios' Next.js WordPress Starter tartışma panosunda da sordum, ancak ne yazık ki sorum yanıtsız hemen silindi. (Cesaret verici değil mi?)

Yani WPGraphQL o zaman, şu anda ve öngörülebilir gelecek için.

İkisinden birini (veya hiçbirini) kullanın Şu durumlarda: Frontity'yi Kullanma

Frontity, WordPress için bir React çerçevesidir. WordPress aracılığıyla arka uçta yönetilen React tabanlı bir uygulama oluşturmanıza olanak tanır. WordPress düzenleyicisini kullanarak blog gönderileri oluşturmak bile kutudan desteklenir.

Frontity, verilerin nasıl elde edildiğini sızdırmadan uygulamanın durumunu yönetir. Varsayılan olarak REST'e dayalı olsa da, ilgili kaynak eklentiyi uygulayarak GraphQL aracılığıyla da güçlendirebilirsiniz.

Frontity işte böyle akıllıdır: Kaynak eklenti, veri sağlayıcı ile iletişim kurmak için bir arayüzdür. Şu anda, mevcut tek kaynak eklenti, WordPress REST API için olanıdır. Ancak herkes, WordPress için WPGraphQL veya GraphQL API için bir kaynak eklenti uygulayabilir. (Next.js tabanlı çerçevelerin çoğaltılmasını istediğim yaklaşım budur.)

Sonuç : Ne WPGraphQL ne de GraphQL API, Frontity ile çalışmak için diğerine herhangi bir avantaj sağlamaz ve her ikisi de, bunları takmak için biraz çaba gerektirir.

Aşağıdaki durumlarda WPGraphQL kullanın: Statik Site Oluşturma

İlk iki bölümde sonuç aynıydı: WPGraphQL kullanın. Ancak bu sonuca yanıtım farklıydı: Gatsby ile hiçbir pişmanlık duymazken, Next.js ile bu konuda bir şeyler yapmaya mecbur hissettim.

Nedenmiş?

Aradaki fark, Gatsby tamamen statik bir site oluşturucu iken, Next.js'nin hem statik hem de canlı web sitelerine güç sağlayabilmesidir.

WPGraphQL'nin Gatsby için zaten yeterince iyi olduğundan bahsetmiştim. Bu ifade aslında genişletilebilir: WPGraphQL, herhangi bir statik site oluşturucu için zaten yeterince iyidir . Statik site oluşturucu verileri WordPress web sitesinden aldığında, WordPress ile hemen hemen çözülür.

WordPress için GraphQL API ek özellikler sunsa bile, büyük olasılıkla statik site oluşturucu için bir fark yaratmayacaktır.

Bu nedenle, WPGraphQL zaten yeterince iyi olduğundan ve GraphQL şemasını tamamen eşlediğinden (ki bu, WordPress için GraphQL API için halen devam eden bir çalışmadır), bu durumda WPGraphQL, şimdi ve öngörülebilir gelecek için en uygun seçenektir.

Aşağıdaki durumlarda GraphQL API'sini kullanın: GraphQL'yi Canlı (yani Statik Olmayan) Bir Web Sitesinde Kullanma

Şimdi, örneğin bir mobil uygulamayı çalıştırırken veya bir web sitesinde gerçek zamanlı verileri çizerken (örneğin, analitiği görüntülemek için) veya hem statik hem de canlı yaklaşımları birleştirirken olduğu gibi, GraphQL'nin canlı bir web sitesinden veri getirmesini istiyorsak yukarıdaki durum değişir. aynı web sitesinde.

Örneğin, Next.js çerçevelerinden birini kullanarak basit bir statik blog oluşturduğumuzu ve kullanıcıların blog gönderilerine yorum eklemesine izin vermek istediğimizi varsayalım. Bu görev nasıl ele alınmalıdır?

İki seçeneğimiz var: statik ve canlı (veya dinamik). Statik seçersek, yorumlar web sitesinin geri kalanıyla birlikte işlenecektir. Ardından, bir yorum eklendiğinde, web sitesini yeniden oluşturmak ve yeniden dağıtmak için bir web kancasını tetiklemeliyiz.

Bu yaklaşımın birkaç sakıncası vardır. Yeniden oluşturma ve yeniden yerleştirme süreci birkaç dakika sürebilir ve bu sırada yeni yorum kullanılamaz. Ayrıca, web sitesi günde çok sayıda yorum alırsa, statik yaklaşım daha fazla sunucu işleme süresi gerektirecektir ve bu da maliyetli hale gelebilir (bazı barındırma şirketleri sunucu süresine göre ücret alır).

Bu durumda, web sitesini statik olarak yorumsuz hale getirmek ve ardından canlı bir siteden yorumları alıp istemcide dinamik olarak oluşturmak mantıklı olacaktır.

Bunun için Gatsby yerine Next.js önerilir. Farklı yeteneklere sahip kullanıcılar için farklı çıktıları desteklemek de dahil olmak üzere statik ve canlı yaklaşımları daha iyi idare edebilir.

GraphQL tartışmasına geri dönelim: Canlı verilerle uğraşırken neden WordPress için GraphQL API'sini öneriyorum? Bunu yapıyorum çünkü GraphQL sunucusunun uygulama üzerinde, özellikle hız ve güvenlik açısından doğrudan bir etkisi olabilir.

Tamamen statik bir web sitesi için, WordPress web sitesi gizli tutulabilir (geliştiricinin dizüstü bilgisayarında bile yayınlanabilir), bu nedenle güvenlidir. Ve kullanıcı sunucudan bir yanıt beklemeyecektir, bu nedenle hız mutlaka kritik öneme sahip değildir.

Ancak canlı bir site için GraphQL API herkese açık hale getirilecek ve bu nedenle veri güvenliği bir sorun haline gelecek. Kötü niyetli aktörlerin ona erişemeyeceğinden emin olmalıyız. Ek olarak, kullanıcı bir yanıt bekleyecektir, bu nedenle hız kritik bir husus haline gelir.

Bu açıdan, WordPress için GraphQL API'sinin WPGraphQL'ye göre birkaç avantajı vardır .

WPGraphQL, varsayılan olarak iç gözlemi devre dışı bırakmak gibi güvenlik önlemleri uygular. Ancak WordPress için GraphQL API, varsayılan olarak tek uç noktayı devre dışı bırakarak (birkaç başka önlemle birlikte) daha da ileri gider. Bu mümkündür, çünkü WordPress için GraphQL API, yerel olarak kalıcı sorgular sunar.

Hız açısından, kalıcı sorgular ayrıca API'yi daha hızlı hale getirir, çünkü yanıt daha sonra istemci, içerik dağıtım ağı ve sunucu dahil olmak üzere çeşitli katmanlarda HTTP önbelleğe alma yoluyla önbelleğe alınabilir.

Bu nedenler, WordPress için GraphQL API'yi canlı web sitelerini yönetmede daha uygun hale getirir.

Aşağıdaki durumlarda GraphQL API'sini kullanın: Farklı Kullanıcılar veya Uygulamalar için Farklı Verilerin Açığa Çıkması

WordPress, birden fazla uygulama için içeriği yönetebilen ve farklı kullanıcı türleri tarafından erişilebilen çok yönlü bir içerik yönetim sistemidir.

Bağlama bağlı olarak, aşağıdakiler gibi farklı verileri ortaya çıkarmak için GraphQL API'lerimize ihtiyacımız olabilir:

• belirli verileri ücretli kullanıcılara açıklayın, ancak ücretsiz kullanıcılara değil,
• belirli verileri web sitesine değil, mobil uygulamaya gösterin.

Farklı verileri ortaya çıkarmak için GraphQL şemasının farklı sürümlerini sağlamamız gerekiyor.

WPGraphQL şemayı değiştirmemize izin verir (örneğin, kayıtlı bir alanı kaldırabiliriz). Ancak süreç basit değildir: Şema değişiklikleri kodlanmalıdır ve kimin neye ve nereye eriştiğini anlamak kolay değildir (örneğin, tüm şemalar tek bir uç nokta altında mevcut olacaktır, /graphql ).

Buna karşılık, WordPress için GraphQL API, bu kullanım durumunu yerel olarak destekler: Farklı bağlamlar için farklı verileri ortaya çıkarabilen özel uç noktalar sunar, örneğin:

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

Her özel uç nokta, alana göre ayrıntılı kullanıcı erişimi sağlamak ve şemanın meta verilerinin herkes tarafından mı yoksa yalnızca yetkili kullanıcılar tarafından mı kullanılabileceğini belirlemek için genel ve özel bir API modu sağlamak için erişim kontrol listeleri aracılığıyla yapılandırılır.

Bu özellikler doğrudan WordPress editörüyle (yani Gutenberg) entegre olur. Bu nedenle, farklı şemalar oluşturmak, bir blog yazısı oluşturmaya benzer şekilde görsel olarak yapılır. Bu, yalnızca geliştiricilerin değil, herkesin özel GraphQL şemaları üretebileceği anlamına gelir.

WordPress için GraphQL API, bu kullanım durumu için doğal bir çözüm sağladığına inanıyorum.

Aşağıdaki durumlarda GraphQL API'sini kullanın: Harici Hizmetlerle Etkileşim

GraphQL, yalnızca veri almak ve göndermek için bir API değildir. Önemli (çoğunlukla ihmal edilse de) aynı zamanda verileri işleyebilir ve değiştirebilir - örneğin, dil bilgisi hatalarını düzeltmek için üçüncü taraf bir API'ye metin göndermek veya bir içerik dağıtımına bir görüntü yüklemek gibi bazı harici hizmetlere besleyerek ağ.

Şimdi, GraphQL'nin harici servislerle iletişim kurmasının en iyi yolu nedir? Benim düşünceme göre, bu en iyi, verileri oluştururken veya alırken uygulanan yönergeler aracılığıyla gerçekleştirilir (WordPress filtrelerinin nasıl çalıştığından farklı olarak).

WPGraphQL'nin harici hizmetlerle ne kadar iyi etkileşime girdiğini bilmiyorum, çünkü belgelerinde bundan bahsedilmiyor ve kod tabanı herhangi bir yönerge veya nasıl oluşturulacağına ilişkin bir belge örneği sunmuyor.

Buna karşılık, WordPress için GraphQL API, yönergeler için güçlü bir desteğe sahiptir. Bir sorgudaki her yönerge toplamda yalnızca bir kez yürütülür (alan ve/veya nesne başına bir kez yerine). Bu yetenek, harici API'ler ile çok verimli iletişim sağlar ve GraphQL API'sini bir hizmet bulutu içinde bütünleştirir.

Örneğin, bu sorgu, birçok yayının başlıklarını ve alıntılarını İngilizce'den İspanyolca'ya çevirmek için bir @translate yönergesi aracılığıyla Google Translate API'sine yapılan bir çağrıyı gösterir. Tüm gönderiler için tüm alanlar tek bir aramada birlikte çevrilir.

WordPress için GraphQL API, bu kullanım durumu için doğal bir seçimdir.

Not : Nitekim, GraphQL API for WordPress'in temel aldığı motor, GraphQL by PoP, gelişmiş veri işleme yetenekleri sağlamak için özel olarak tasarlanmıştır. Bu onun belirgin özelliklerinden biridir. Neler başarabileceğine dair uç bir örnek için, “Yerelleştirilmiş Bülten Gönderme, Kullanıcıya Göre Kullanıcı” başlıklı kılavuza bakın.

Aşağıdaki durumlarda WPGraphQL kullanın: Bir Destek Topluluğu İstiyorsanız

Jason Bahl, bir topluluğu WPGraphQL etrafında toplamak konusunda harika bir iş çıkardı. Sonuç olarak, GraphQL API'nizde sorun gidermeniz gerekiyorsa, muhtemelen size yardımcı olabilecek birini bulacaksınız.

Benim durumumda, hala WordPress için GraphQL API çevresinde bir kullanıcı topluluğu oluşturmaya çalışıyorum ve bu kesinlikle WPGraphQL'nin yakınında değil.

Aşağıdaki durumlarda GraphQL API'sini kullanın: Yeniliği Seviyorsanız

WordPress için GraphQL API'sini “ileriye dönük” bir GraphQL sunucusu olarak adlandırıyorum. Bunun nedeni, genellikle GraphQL belirtimi için istekler listesine göz atmam ve bazılarını vaktinden çok önce uygulamamdır (özellikle biraz yakınlık hissettiğim veya çok az çabayla destekleyebileceğim).

Bugün itibariyle, WordPress için GraphQL API, isteğe bağlı olarak sunulan çeşitli yenilikçi özellikleri (çoklu sorgu yürütme ve şema ad alanı oluşturma gibi) destekler ve birkaç tane daha için planlar vardır.

Aşağıdaki durumlarda WPGraphQL kullanın: Tam Bir Şemaya İhtiyacınız Var

WPGraphQL, aşağıdakiler dahil olmak üzere WordPress veri modelini tamamen eşlemiştir:

• yazılar ve sayfalar,
• özel gönderi türleri,
• kategoriler ve etiketler,
• özel taksonomiler,
• medya,
• menüler,
• ayarlar,
• kullanıcılar,
• yorumlar,
• eklentiler,
• temalar,
• widget'lar.

WordPress için GraphQL API, her yeni sürümle veri modelini aşamalı olarak eşler. Bugün itibariyle liste şunları içeriyor:

• yazılar ve sayfalar,
• özel gönderi türleri,
• kategoriler ve etiketler,
• özel taksonomiler,
• medya,
• menüler,
• ayarlar,
• kullanıcılar,
• yorumlar

Bu nedenle, bir eklentiden, temadan veya widget'tan veri almanız gerekiyorsa, şu anda işi yalnızca WPGraphQL yapar.

Aşağıdaki durumlarda WPGraphQL kullanın: Uzantılara ihtiyacınız varsa

WPGraphQL, Advanced Custom Fields, WooCommerce, Yoast, Gravity Forms dahil olmak üzere birçok eklenti için uzantılar sunar.

WordPress için GraphQL API, Events Manager için bir uzantı sunar ve eklentinin 1.0 sürümünün yayınlanmasından sonra daha fazlasını eklemeye devam edecektir.

Şunlardan Herhangi Birini Kullanın: WordPress Düzenleyici için Bloklar Oluşturma

WordPress için hem WPGraphQL hem de GraphQL API şu anda GraphQL'yi Gutenberg ile entegre etme üzerinde çalışıyor.

Jason Bahl, bu entegrasyonun gerçekleşebileceği üç yaklaşımı tanımladı. Bununla birlikte, hepsinin sorunları olduğu için, GraphQL şeması için farklı Gutenberg bloklarının tanımlanmasını sağlamak için WordPress'e bir sunucu tarafı kayıt defteri eklenmesini savunuyor.

WordPress için GraphQL API ayrıca "bir kez oluştur, her yerde yayınla" stratejisine dayanan Gutenberg ile entegrasyon yaklaşımına sahiptir. Depolanan içerikten blok verilerini çıkarır ve tüm blokları temsil etmek için tek bir Block türü kullanır. Bu yaklaşım, önerilen sunucu tarafı kayıt defterine olan ihtiyacı ortadan kaldırabilir.

WPGraphQL'nin çözümü geçici olarak kabul edilebilir, çünkü bu, topluluğun sunucu tarafı kayıt defteri kullanımını kabul etmesine bağlı olacaktır ve bunun olup olmayacağını veya ne zaman olacağını bilmiyoruz.

WordPress için GraphQL API için çözüm tamamen kendisine bağlı olacaktır ve bu aslında halihazırda devam eden bir çalışmadır.

Yakında çalışan bir çözüm üretme şansı daha yüksek olduğu için, WordPress için GraphQL API'sini önerme eğilimindeyim. Ancak, amaçlandığı gibi çalıştığından emin olmak için çözümün tamamen uygulanmasını (plana göre birkaç hafta içinde) bekleyelim ve ardından tavsiyemi güncelleyeceğim.

Şu durumlarda GraphQL API'sini kullanın: Blokları Eklenti Üzerinden Dağıtma

Şunu anladım: WordPress'te GraphQL kullanan pek çok eklenti (varsa) yok.

Beni yanlış anlamayın: WPGraphQL 10.000 kurulumu aştı. Ancak bunların çoğunlukla Gatsby'yi (Gatsby'yi çalıştırmak için) veya Next.js'yi (başsız çerçevelerden birini çalıştırmak için) güçlendirmek için kurulumlar olduğuna inanıyorum.

Benzer şekilde, WPGraphQL, daha önce açıkladığım gibi birçok uzantıya sahiptir. Ancak bu uzantılar tam da bu: uzantılar. Bunlar bağımsız eklentiler değildir.

Örneğin, WPGraphQL for WooCommerce uzantısı, hem WPGraphQL hem de WooCommerce eklentilerine bağlıdır. Bunlardan biri kurulu değilse, uzantı çalışmaz ve sorun değil. Ancak WooCommerce, çalışmak için WPGraphQL'ye güvenme seçeneğine sahip değildir; bu nedenle, WooCommerce eklentisinde GraphQL olmayacaktır.

Anladığım kadarıyla, WordPress'in işlevselliğini çalıştırmak veya özellikle Gutenberg bloklarını güçlendirmek için GraphQL kullanan hiçbir eklenti yok.

Nedeni basit: WordPress için ne WPGraphQL ne de GraphQL API, WordPress'in çekirdeğinin bir parçası değildir. Bu nedenle, eklentilerin WordPress'in REST API'sine güvenebileceği şekilde GraphQL'ye güvenmek mümkün değildir. Sonuç olarak, Gutenberg bloklarını uygulayan eklentiler, blokları için veri almak için GraphQL'yi değil, yalnızca REST'i kullanabilir.

Görünüşe göre çözüm, WordPress çekirdeğine bir GraphQL çözümünün (büyük olasılıkla WPGraphQL) eklenmesini beklemektir. Ama bunun ne kadar süreceğini kim bilebilir? Altı ay? Bir yıl? İki yıl? Uzun?

Matt Mullenweg ima ettiği için WPGraphQL'nin WordPress'in çekirdeği olarak değerlendirildiğini biliyoruz. Ancak bundan önce pek çok şeyin olması gerekiyor: Minimum PHP sürümünü 7.1'e yükseltmek (hem WPGraphQL hem de WordPress için GraphQL API için gerekli) ve ayrıca GraphQL'nin hangi işlevselliği sağlayacağına ilişkin net bir ayrıştırma, anlayış ve yol haritasına sahip olmak.

(Şu anda geliştirme aşamasında olan tam site düzenlemesi REST'e dayanmaktadır. Gutenberg'in 4. aşamasında ele alınacak bir sonraki ana özellik olan çok dilli bloklar ne olacak? Bu değilse, o zaman hangi özellik olacak?)

Sorunu açıkladıktan sonra, olası bir çözüm düşünelim - beklemeye gerek olmayan bir çözüm!

Birkaç gün önce başka bir şey fark ettim: WordPress'in kod tabanı için GraphQL API'sinden, yalnızca GraphQL motorunu içeren ve başka hiçbir şey içermeyen daha küçük bir sürüm üretebilirim (UI yok, özel uç nokta yok, HTTP önbelleğe alma yok, erişim kontrolü yok, hiçbir şey). Ve bu sürüm bir Besteci bağımlılığı olarak dağıtılabilir, böylece eklentiler onu kendi bloklarına güç sağlamak için yükleyebilir.

Bu yaklaşımın anahtarı, bu bileşenin başka kimseyle paylaşılmaması için eklentiye özel olarak kullanılması gerektiğidir. Aksi takdirde, bu bileşene başvuran iki eklenti, şemayı birbirlerini geçersiz kılacak şekilde değiştirebilir.

Neyse ki, yakın zamanda WordPress için kapsam belirleme GraphQL API'sini çözdüm. Bu yüzden, web sitesindeki diğer kodlarla çakışmayacak bir sürüm üreterek, onu tamamen kapsayabileceğimi biliyorum.

Bu, herhangi bir olay kombinasyonu için çalışacağı anlamına gelir:

• Bileşeni içeren eklenti onu kullanan tek eklentiyse;
• Aynı web sitesinde WordPress için GraphQL API de kuruluysa;
• Web sitesinde bu bileşeni de içeren başka bir eklenti kuruluysa;
• Bileşeni gömen iki eklenti, bileşenin aynı sürümüne veya farklı olanlara atıfta bulunuyorsa.

Her durumda, eklentinin Gutenberg bloklarına güç sağlamak için tamamen güvenebileceği kendi bağımsız, özel GraphQL motoru olacaktır (ve herhangi bir çatışmadan korkmamıza gerek yok).

Private GraphQL API olarak adlandırılacak bu bileşen birkaç hafta içinde hazır olacaktır. (Bunun üzerinde çalışmaya başladım bile.)

Bu nedenle, benim tavsiyem, eklentinizde Gutenberg bloklarını güçlendirmek için GraphQL kullanmak istiyorsanız, lütfen birkaç hafta bekleyin ve ardından WordPress'in küçük kardeşi Özel GraphQL API için GraphQL API'sine göz atın.

Çözüm

Oyunda cildim olmasına rağmen, çoğunlukla objektif olan bir makale yazmayı başardığımı düşünüyorum.

WPGraphQL'yi neden ve ne zaman kullanmanız gerektiğini belirtirken dürüst oldum. Benzer şekilde, çeşitli kullanım durumları için WordPress için GraphQL API'sinin neden WPGraphQL'den daha iyi göründüğünü açıklarken dürüst oldum.

Genel hatlarıyla şöyle özetleyebiliriz:

• WPGraphQL ile statik hale gelin veya WordPress için GraphQL API ile canlı yayına geçin.
• WPGraphQL ile güvenli oynayın veya WordPress için GraphQL API'sine yatırım yapın (potansiyel olarak değerli bir getiri için).

Son bir not olarak, Next.js çerçevelerinin Frontity tarafından kullanılan aynı yaklaşımı takip edecek şekilde yeniden tasarlanmasını diliyorum: burada belirli bir çözümün doğrudan uygulamasını kullanmak yerine ihtiyaç duydukları verileri almak için bir arayüze erişebilirler ( mevcut olan WPGraphQL'dir). Böyle bir durumda geliştiriciler, projeden projeye ihtiyaçlarına göre hangi temel sunucunun kullanılacağını (WPGraphQL, WordPress için GraphQL API'si veya gelecekte tanıtılacak başka bir çözüm) seçebilirler.

kullanışlı bağlantılar

• WPGraphQL: belgeler, indirme sayfası, kod deposu
• WordPress için GraphQL API: belgeler, indirme sayfası, kod deposu
• “Gatsby WordPress Entegrasyon Çalıştayı”
  WPGraphQL demosunu içeren YouTube videosu
• “WordPress için GraphQL API'sine Giriş”
  WordPress için GraphQL API demosunu içeren YouTube videosu