🛠 WordPress'in core'unda bir GraphQL API olmalı mı?

WordPress 5.7 yakında çıkıyor. Pek çok sürümde olduğu gibi, WP REST API da birçok yeni özellikle birlikte gelecek.

Yeni özellikler arasında dikkatimi çeken biri oldu: "Image Editor Accepts a List of Modifiers" (Görüntü Düzenleyici, Değiştirici Listesi Kabul Ediyor).

WordPress 5.5'te tanıtılan /wp/v2/media/<id>/edit uç noktası, üst düzey döndürme ve kırpma bildirimlerini kabul eden sınırlı bir API ile geliyordu. 50124 numaralı değişiklikle bu API, yeni modifiers istek parametresi aracılığıyla bir değişiklikler dizisi kabul edecek şekilde daha güçlü ve esnek hale getirildi.

import apiFetch from '@wordpress/api-fetch';
 
const data = {
  modifiers: [
    {
      type: 'crop',
      args: {
        left  : 0,
        top   : 0,
        width : 80,
        height: 80
      }
    },
    {
      type: 'rotate',
      args: {
        angle: 90
      }
    }
  ]
};
apiFetch( { data, method: 'POST', path: '/wp/v2/media/5/edit' } );Copy

Bu gelişme bir süredir üzerinde çalışılıyordu.

İlk olarak, WordPress 5.5'te görüntü düzenleme uç noktası tanıtıldı.

Bu uç nokta başlangıçta biraz katıydı; görüntüye uygulanacak tüm işlemlere ilişkin verilerin birlikte iletilmesini gerektiriyordu. Örneğin, görüntüyü döndürmek ve boyutunu değiştirmek için şu verileri iletirdik:

{
  "x": 0,
  "y": 0,
  "width": 80,
  "height": 80,
  "rotate": 90
}Copy

Ardından WordPress 5.6'da, WP REST API'ye toplu işlemler eklendi.

Son olarak, yaklaşan WordPress 5.7'de görüntüye uygulanacak işlemler ayrıştırıldı; böylece "crop" ve "rotate" işlemlerine sahip olduk. Bu işlemler ayrı ayrı çalıştırılabildiği gibi, toplu işlem yoluyla aynı istekte birlikte de kullanılabilir.

Daha önce görüldüğü gibi, uç noktaya veri iletmek artık çok daha zarif görünüyor:

{
  "modifiers": [
    {
      "type": "crop",
      "args": {
        "left"  : 0,
        "top"   : 0,
        "width" : 80,
        "height": 80
      }
    },
    {
      "type": "rotate",
      "args": {
        "angle": 90
      }
    }
  ]
}Copy

​

Zaten var olanı yeniden mi yapıyoruz?

WP REST API, WordPress için tek API değildir. (En az) iki alternatif vardır:

• GraphQL, WPGraphQL aracılığıyla
• GraphQL + persisted queries, Gato GraphQL aracılığıyla
  (☝🏽 Bu blog yazısının ev sahibi benim ☝🏽)

GraphQL, toplu işlemlerde üstün olan görece yeni bir API türüdür. GraphQL kullanıldığında, REST'te olduğu gibi bunlar için özel bir çözüm geliştirmek için zaman ve enerji harcamaya gerek yoktur.

Gerçekten de REST, bu özelliği GraphQL'den "kopyalıyor" gibi görünebilir.

WP REST API'de toplu işlemlerin desteklenmesi en az 2, muhtemelen 3 sürüm döngüsü aldı. Bu küçümsenemeyecek bir zaman dilimi ve birçok kişinin katkısını gerektirdi.

Eğer WordPress GraphQL'i de kullanabilseydi ve görüntü düzenleme uç noktası REST yerine GraphQL üzerine kurulu olsaydı, bu katkıda bulunanlar başka geliştirmeler üzerinde çalışabilirdi.

WordPress, her uygun olduğunda her API'nin en iyi özelliklerini kullanabilseydi, daha iyi durumda olmaz ve çok daha hızlı geliştirilmez miydi?

Cevap size ait...

​

GraphQL'de Toplu İşlemler

Size Gato GraphQL'in toplu işlemleri desteklediği tek değil, birden fazla yolu göstereceğim.

Birincisi en basit olanı: queries'in köküne birden fazla alan eklemek. Örneğin, bu query kullanıcıyı giriş yaptırır ve ardından bir yorum ekler:

mutation LogUserInAndAddCommentToPost {
  loginUser(
    by: { credentials: { usernameOrEmail: "test", password: "pass" } }
  ) {
    id
    name
  }
  addCommentToCustomPost(
    input: {
      customPostID: 1459
      commentAs: { html: "Adding a comment: bla bla bla" }
    }
  ) {
    id
    content
    date
  }
}Copy

(Bu arada, bu GraphiQL istemcisidir. Kullanımıyla ilgili bir tutorial burada.)

Bu iki işlem farklı nesnelere uygulandı, ancak aynı nesneye birkaç işlem uygulamak istiyoruz.

Bunu şimdi yapalım: bu query aynı gönderiye iki yorum ekler.

mutation AddTwoCommentsToPost {
  firstComment: addCommentToCustomPost(
    input: {
      customPostID: 1459
      commentAs: { html: "This is my first response" }
    }
  ) {
    id
    content
    date
  }
  secondComment: addCommentToCustomPost(
    input: {
      customPostID: 1459
      commentAs: { html: "This is my second response" }
    }
  ) {
    id
    content
    date
  }
}Copy

Bu iki yorum halihazırda var olan bir gönderiye eklendi. Peki ya gönderinin de önce oluşturulması gerekiyorsa?

Bu durumda, basit query artık çalışmayacaktır; çünkü diğer işlemlere argüman olarak gerekli olan henüz oluşturulmamış gönderinin ID'sini bilmiyoruz (alan argümanındaki ?'ye dikkat edin):

mutation CreatePostAndAddTwoCommentsToPost {
  createPost(input: { title: "Some post" }) {
    id  # <= Bu değerin ne olacağını bilmiyorum
  }
  addCommentToCustomPost(input: {
    customPostID: ?,
    commentAs: { html: "Blah blah blah" }
  }) {
    id
    content
    date
  }
}Copy

Ama endişelenmeyin, Gato GraphQL arkanızı kolluyor. Tek değil, iki çözüm sunuyor!

Birincisi, çoklu-query çalıştırma özelliğini kullanmaktır.

Bu query'de, ilk işlemi çalıştırır, sonucunu @export direktifi aracılığıyla dışa aktarır ve ardından bu değeri ikinci query'ye girdi olarak enjekte ederiz:

mutation AddComment {
  addCommentToCustomPost(
    customPostID: 1459
    commentAs: { html: "Some insightful comment" }
  ) {
    id @export(as: "newCommentID")
    content
    date
  }
}
 
mutation AddResponseToComment @depends(on: "AddComment") {
  replyComment(
    parentCommentID: $newCommentID
    commentAs: { html: "Debunking your insightful comment" }
  ) {
    id
    date
    content
    parent {
      id
    }
  }
}Copy

Daha da zarif olan ise iç içe mutations kullanmaktır.

Bu query'de, ilk işlemi çalıştırır ve ikinci işlemi onun içine yerleştiririz; böylece ilk işlem sırasında oluşturulan nesne üzerine uygulanır (ve ardından tekrar, 3. işlemi iç içe geçirerek, vb.):

mutation AddCommentAndResponseAndResponse {
  addCommentToCustomPost(
    input: {
      customPostID: 1459
      commentAs: { html: "Some insightful comment" }
    }
  ) {
    id
    content
    date
    reply(input: { commentAs: { html: "Debunking your insightful comment" } }) {
      id
      date
      content
      parent {
        id
      }
      reply(input: { commentAs: { html: "No, it was right!" } }) {
        id
        date
        content
        parent {
          id
        }
      }
    }
  }
}Copy

Bir bonus olarak, toplu işlemler yalnızca tek bir varlığa değil, aynı istekte aynı anda birçok varlığa uygulanabilir.

Bu query'de, yeni yorumlar ve tüm yanıtları birçok gönderiye ekleniyor:

mutation AddCommentAndResponseToManyPosts {
  posts(ids: [1657, 1153, 1499, 1459]) {
    id
    addComment(input: { commentAs: { html: "Some insightful comment" } }) {
      id
      content
      date
      reply(
        input: { commentAs: { html: "Debunking your insightful comment" } }
      ) {
        id
        date
        content
        parent {
          id
        }
      }
    }
  }
}Copy

Ve eklentinin kolunda bir numara daha var: gömülebilir alanlar özelliğini kullanarak, her alan argümanına iletilen içeriği nesnenin kendi verileriyle özelleştirebiliriz!

Bu query'de, yorumlar üzerinde oluşturuldukları nesneden bilgiler içeriyor:

mutation AddCustomCommentAndResponseToManyPosts {
  posts(ids: [1657, 1153, 1499, 1459]) {
    id
    addComment(
      input: {
        commentAs: { html: "The post has ID {{ id }} and title {{ title }}" }
      }
    ) {
      id
      content
      date
      reply(
        input: {
          commentAs: {
            html: "The parent comment was posted on {{ dateStr(format: \"d/m/Y\") }}. Cool, right?"
          }
        }
      ) {
        id
        date
        content
        parent {
          id
        }
      }
    }
  }
}Copy

​

Her Uygun Olduğunda REST ve GraphQL'den En İyi Şekilde Yararlanmak

Full Site Editing geliştirildikçe ve genişledikçe, WordPress giderek daha fazla API'lerine bağımlı hale gelecek.

Mevcut özellikler açısından bakıldığında, REST API şimdiye kadar çok iyi bir performans sergiledi. Bozulmayan şeyi yeniden inşa etmeye gerek yoktur.

Ancak, henüz geliştirilmemiş yeni özellikler söz konusu olduğunda, WordPress o belirli özellik için hangisi daha uygunsa REST veya GraphQL'i kullanmaktan fayda sağlamaz mıydı?

Cevap size ait...