Özel İstek İşleyicilere karşı WordPress REST API

Geçen yıl admin-ajax.php ve WordPress REST API kullanmanın performansını karşılaştıran bir blog yazısı yazdım ve REST API'sinin geleneksel AJAX API'sini kullanmaktan yaklaşık %16 daha hızlı olduğunu gördüm. Bu sağlam bir gelişme olsa da, epeyce geliştirici (kendim dahil), REST API'nin tamamen özel uç noktaları kullanmaya kıyasla nasıl olduğunu merak ediyordu. REST API, WordPress çekirdeğinin çoğunu ve herhangi bir aktif eklentiyi yüklediğinden, oldukça farklı olmalı!

Özel bir uç noktanın daha hızlı olacağına dair çok az şüphe var, ancak ne kadar hızlı olacağını görmek ilginç olmalı. Özel bir uç noktanın geliştirme ve gelecekteki destek perspektifinden anlamlı olup olmadığını görmek için de bir göz atmaya değer.

Özel İstek İşleyicileri Tanımlama

Özel uç noktaları ayarlamanın birkaç farklı yolu vardır. Mümkün olan en hızlı uç nokta muhtemelen WordPress'ten tamamen bağımsız olacaktır ve web sunucusuna yüklenen bağımsız bir PHP dosyası kadar basit olabilir. Hızlı olsa da, muhtemelen o kadar da yardımcı olmaz, çünkü çoğu zaman büyük ölçüde geliştirme süresi kazandıran WordPress temel işlevlerine erişimimiz olmayacaktır.

SHORTINIT ile İşleri Hızlandırma

Bir sonraki en hızlı yaklaşım, temalar ve eklentiler gibi şeyleri yüklemeden temel işlevleri kullanabilmek için yeterince WordPress'i manuel olarak yüklemek olacaktır. AJAX istekleri bu dosyayı özel olarak hedefleyecektir, bu nedenle sunucuda herkesin erişebileceği bir yere yerleştirilmelidir.

Bunu yapmanın birkaç yolu var, ancak gördüğüm en yaygın yaklaşım bu:

 <?php // custom-ajax-endpoint.php define( 'DOING_AJAX', true ); // Tell WordPress to load as little as possible define( 'SHORTINIT', true ); require_once '../../wp-load.php'; wp_send_json( array( 'time' => time() ) );

Yukarıdaki dosya birkaç şey yapar. İlk olarak, WordPress'e bir AJAX isteğinin yapıldığını söylemek için DOING_AJAX sabitini tanımlar. Ardından, WordPress'e temel bilgileri yüklemesini söylemek için SHORTINIT sabitini tanımlar – WordPress çekirdeğinin bir kısmı ve başka bir şey değil. Ardından, isteği düzgün bir şekilde yerine getirmek için gereken bazı diğer dosyaları yükleyen wp-load.php dosyasını (bu dosyanın konumu yüklemeler arasında değişebileceğinden genellikle kötü bir uygulamadır) manuel olarak gerektirir. Son olarak, isteğe JSON kodlu zaman ile yanıt verir.

Buna bakarken meslektaşım Evan, wp-load.php dosyasının konumunu bilmeyi gerektirmeyen başka bir yaklaşım fark etti. Bu, wp-config.php dosyasında özel bir istek tanımlayan bir parametreyi dinleyerek gerçekleştirilebilir:

 /** * Define SHORTINIT and DBI_AJAX constants if this is * a request to our custom request handler */ if ( filter_input( INPUT_GET, 'dbi-ajax' ) ) { define( 'SHORINIT', true ); define( 'DBI_AJAX', true ); } /* That's all, stop editing! Happy blogging. */ /** Absolute path to the WordPress directory. */ if ( !defined('ABSPATH') ) define('ABSPATH', dirname(__FILE__) . '/'); /** Sets up WordPress vars and included files. */ require_once(ABSPATH . 'wp-settings.php'); if ( defined( 'DBI_AJAX' ) ) { wp_send_json( array( 'time' => time() ) ); }

Bu, yukarıdaki ilk yaklaşıma benzer. İstek bir dbi-ajax parametresi içeriyorsa (böylece bunun özel bir istek olduğunu biliyoruz), WordPress'e temel öğeleri yüklemesini söylemek için SHORTINIT sabitini tanımlarız. Ayrıca bir DBI_AJAX sabiti tanımlıyoruz, böylece dbi-ajax parametresini tekrar kontrol etmeden özel bir isteğin yapılıp yapılmadığını kolayca anlayabiliyoruz. Ardından, WordPress yüklendikten sonra ( wp-settings.php dosyası gerekli olduktan sonra), isteği yerine getirebiliriz. Genellikle bu noktada, bu işlevi içeren başka bir dosya eklemenizi tavsiye ederiz, ancak bu karşılaştırmanın amacı için, yukarıdaki ilk örnekte olduğu gibi yalnızca JSON kodlu zamanı döndürüyoruz.

Çok az WordPress yüklemek, benzersiz bir dizi zorlukla birlikte gelir. Tüm WordPress temel işlevleri kullanılamayacak, bu nedenle ihtiyacınız olan bir işlev mevcut değilse, içinde bulunduğu dosyayı bulmanız ve manuel olarak eklemeniz gerekir. İstek işleyicinizin ne yapması gerektiğine bağlı olarak, bu bir yük haline gelebilir. Ayrıca, wp-load.php dosyasını manuel olarak istemek veya wp-config.php dosyasını düzenlemek taşınabilir değildir ve muhtemelen çok sayıda yüklemeye dağıtılacak bir eklenti veya temada yapılmamalıdır.

Daha İyi Bir Alternatif?

Başka bir olası yaklaşım, Must Use eklentisi içinde özel bir istek işleyicisi oluşturmaktır. Bu şekilde, WordPress çekirdek yüklendikten sonra, ancak eklentiler ve temalar yüklenmeden önce herhangi bir özel isteğe yanıt verebilir. Bu, hem performansı iyileştirmeli hem de REST API veya admin-ajax.php kullanan diğer eklentilerden kaynaklanan çakışmaları önlemelidir.

 <?php /** * Plugin Name: DBI AJAX Endpoint * Description: Custom Request endpoint * Author: Delicious Brains Inc * Version: 1.0 * Author URI: https://deliciousbrains.com */ if ( ! filter_input( INPUT_GET, 'dbi-ajax' ) ) { return; } // Define the WordPress "DOING_AJAX" constant. if ( ! defined( 'DOING_AJAX' ) ) { define( 'DOING_AJAX', true ); } wp_send_json( array( 'time' => time() ) );

Yukarıdaki eklenti, dbi-ajax parametresini (herhangi bir isteğe yanıt vermesini önlemek için) içeren istekleri dinler ve ardından önceki örneklerde olduğu gibi isteği tamamlamak için JSON'daki zamanı döndürmek için wp_send_json() işlevini kullanır.

Bazı Karşılaştırmaları Çalıştırmak

Özel bir istek uç noktası için iki olası çözüm mevcutken, bazı karşılaştırmaları çalıştırmanın zamanı geldi. İşleri önceki makaleyle biraz tutarlı tutmak için, uç noktanın ortalama yanıt süresi hakkında bir fikir edinmek amacıyla kısa sürede sunucuya yüzlerce HTTP isteği göndermek için ApacheBench kullanıyorum. Ayrıca aynı eklenti setini etkinleştirdim:

• ACF
• Akismet
• Siyah Stüdyo TinyMCE Widget'ı
• WP Veri Tabanını Taşı
• WP Süper Önbellek
• Yoast SEO

Önce, sağlam bir temelimiz olması için REST API karşılaştırmasına bir kez daha bakalım:

100 istekten sonra, ortalama 264 ms yanıt süresi görünür hale gelir. Bu aslında aynı testi aynı sunucuda (490 ms) yaptığım geçen yıla göre çok daha hızlı, ancak şimdilik özel uç noktaların sonuçlarını değerlendirebileceğimiz bir temel olarak 264 ms ortalama yanıt süresine odaklanalım. .

KISA Kıyaslama

Ardından, SHORTINIT sabitini tanımlayarak minimum minimum dosyaları yükleyen özel uç noktaya bir göz atalım.

Yalnızca 29 ms'lik ortalama yanıt süresiyle (%89 azalma), bu yaklaşımın REST API'yi kullanmaktan gece gündüz daha hızlı olduğu açıktır. Bunun nedeni, yalnızca isteği yerine getirmek için gereken dosyaların yüklenmesidir.

Eklenti Karşılaştırması Kullanılmalı

Son olarak, mu-plugin'de oluşturulan özel uç noktaya bir göz atalım:

Ortalama 144 ms yanıt süresiyle (REST API'sine kıyasla %45 azalma), bu uç noktanın performansı, bağımsız dosya ile REST API arasında bir yerdedir. Bu, wp-load.php dosyasının konumunu bilmeden WordPress temel işlevlerini kullanabilen özel bir istek işleyici için iyi bir çözüm haline getirir.

Sonuçlar

Çok sayıda istek gönderecek bir uygulama geliştirirken tek düşünceniz yanıt süreleri olmamalıdır. Ayrıca, uç noktaları desteklemek için harcayabileceğiniz zamanın yanı sıra önceden geliştirme süresini de dikkate almak akıllıca olacaktır.

Toplu halde çok fazla veri işleyen veya eklenti/tema çakışması potansiyelinin daha yüksek olduğu eklentiler gibi performansın kritik olduğu bazı kullanım durumları için özel bir uç nokta kullanmak mantıklı olabilir. Çoğu zaman, önceden hazırlanmış, resmi olarak desteklenen bir çözüme sahip olmak, kendi uç noktalarınızı yaratmanın potansiyel performans avantajlarından çok daha ağır basacaktır.

Eklentinizde veya temanızda özel uç noktalar mı kullanıyorsunuz? Öyleyse, REST API'ye geçmeyi düşünür müsünüz? Neden veya neden olmasın? Yorumlarda bana bildirin.