🥊 Gato GraphQL vs WPGraphQL: การต่อสู้!

ท่านสุภาพสตรีีีีีีีีีีและสุภาพบุรุษทั้งหลาย

ยินดีต้อนรับสู่ MGM Grand Garden Arena สำหรับการต่อสู้แห่งศตวรรษ! คืนนี้ เรากำลังสร้างประวัติศาสตร์ นักสู้หนุ่มสองคนจะเผชิญหน้ากันบนเวที แย่งชิงรางวัลที่พวกเขาทำงานหนักมาตลอด:

เพื่อเป็น แชมป์โลก "GraphQL ใน WordPress" 🏆

ทางขวาของเรา คือแชมป์เก่า แม้จะมีอายุเพียง 4 ปี เขามีประสบการณ์มากมาย เพิ่งเข้าสู่เวอร์ชัน 1.0 และได้รับการเผยแพร่ในไดเรกทอรี wp.org และได้รับความนิยมสูงมากในหมู่ผู้ชม

🥁 ขอต้อนรับ 🥁 สู่ 🥁 เวที 🥁 ให้กับ 🥁 ...... WPGraphQL!

ทางซ้ายของเรา คือผู้ท้าชิง เขาเพิ่งออกสู่โลกได้เพียง 1 เดือน แต่เต็มไปด้วยพลังงานและความทะเยอทะยาน แสดงความแข็งแกร่งตั้งแต่วันแรก เขาเป็นคนที่แสวงหาการเผชิญหน้าในวันนี้ คืนนี้คือโอกาสของเขา และโลกกำลังจับตามอง

🥁 ขอต้อนรับ 🥁 สู่ 🥁 เวที 🥁 ให้กับ 🥁 ...... Gato GraphQL!

คืนนี้ คู่ต่อสู้ของเราจะพบกันเป็นครั้งแรก ในการแข่งขัน 12 ยก ขณะที่พวกเขาเข้าประจำตำแหน่งกลางเวที รอสัญญาณระฆังเปิดการแข่งขัน ต่างศึกษาซึ่งกันและกัน พยายามหาจุดอ่อนของอีกฝ่าย อย่างไรก็ตาม พวกเขาต่างแสดงความมั่นใจอย่างเต็มเปี่ยม

ใครจะชนะ? WPGraphQL จะรักษาข้อได้เปรียบโดยอาศัยการสนับสนุนจากผู้ติดตามหรือไม่? หรือผู้มาใหม่อย่าง Gato GraphQL จะสามารถโน้มน้าวชุมชนที่ยังไม่รู้จักถึงพลังของหมัดเขา ทิ้งร่องรอยแห่งความทึ่งและดึงผู้คนมาอยู่ฝ่ายเขา?

คืนนี้ ท่านสุภาพสตรีและสุภาพบุรุษทั้งหลาย เราจะได้รู้คำตอบ

วางเดิมพันของคุณ และเพลิดเพลินกับการแข่งขัน!

🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣

เมื่อไม่นานมานี้ ฉันถูกขอให้อธิบายความแตกต่างระหว่างปลั๊กอินของฉัน Gato GraphQL และ WPGraphQL

ทั้งสองปลั๊กอินเป็น GraphQL server สำหรับ WordPress ดังนั้นจึงทำหน้าที่เดียวกัน อย่างไรก็ตาม ภายใต้โครงสร้างนั้น พวกมันมีลักษณะที่แตกต่างกัน ซึ่งอาจทำให้อันหนึ่งดีกว่าอีกอันในการตอบสนองพฤติกรรมที่ต้องการ

แม้ว่าฉันจะลำเอียงต่อปลั๊กอินของตัวเอง แต่ฉันได้พยายามวาดการเปรียบเทียบที่เป็นธรรม โดยอิงจากหัวข้อที่ฉันคิดว่าสำคัญสำหรับทั้ง GraphQL และ WordPress (หากผู้อ่านต้องการการเปรียบเทียบในหัวข้ออื่น ฉันยินดีตอบสนอง)

การเปรียบเทียบนี้ไม่ครอบคลุมทุกด้าน ตัวอย่างเช่น ฉันอยากทำการ benchmarking ด้วย วัดความเร็วในการประมวลผล GraphQL query เดียวกันกับทั้งสองเซิร์ฟเวอร์ (หากผู้อ่านสนใจข้อเสนอนี้ ฉันสามารถทำในบทความถัดไปได้)

ฉันแบ่งการเปรียบเทียบออกเป็น 4 ด้านหลัก: ความนิยม, สไตล์โค้ดและมาตรฐาน, ประเด็นเร่งด่วน, และการขยายขอบเขต โดยแต่ละด้านมี 3 หัวข้อ รวมทั้งหมด 12 "ยก" ท้ายที่สุด กรรมการจะตัดสินเพื่อประกาศแชมป์

คลิกด้านล่างเพื่อข้ามไปยังหัวข้อที่ต้องการ:

• ความนิยม
  • ยกที่ 1: ใครใช้มัน และมันสมบูรณ์แค่ไหน
  • ยกที่ 2: ความพร้อมของส่วนขยาย
  • ยกที่ 3: กลุ่มเป้าหมาย
• สไตล์โค้ดและมาตรฐาน
  • ยกที่ 4: ข้อกำหนด PHP
  • ยกที่ 5: แนวทางการเขียนโค้ด
  • ยกที่ 6: การขยาย schema
• พักครึ่ง
• ประเด็นเร่งด่วน
  • ยกที่ 7: Persisted queries
  • ยกที่ 8: การแคช
  • ยกที่ 9: การผสานรวมกับ Gutenberg
• การขยายขอบเขต
  • ยกที่ 10: รองรับ directive แบบกำหนดเอง
  • ยกที่ 11: รองรับ REST
  • ยกที่ 12: รองรับฟีเจอร์ใหม่
• คำตัดสิน!

🔔 ดิ้ง 🔔 ดิ้ง 🔔 ดิ้ง...

ระฆังเปิดการแข่งขันดังขึ้นแล้ว...

การแข่งขันเริ่มต้นแล้ว!

​

ความนิยม

ซอฟต์แวร์ใดก็ตาม (หรือเทคโนโลยีในแง่นั้น) ต้องได้รับการใช้งานจากผู้คน มิฉะนั้นการที่มันดีกว่าทางเลือกอื่นก็จะเป็นเพียงเรื่องเล่าขานเท่านั้น

ตัวอย่างเช่น แม้จะมีทางเลือกที่ช่วยให้พิมพ์ได้เร็วกว่า แต่เรายังคงใช้แป้นพิมพ์ QWERTY เป็นหลัก

ทั้งสองปลั๊กอินได้รับความนิยมมากแค่ไหน?

​

ยกที่ 1: ใครใช้มัน และมันสมบูรณ์แค่ไหน

WPGraphQL เป็นมาตลอดและเป็นคำพ้องความหมายกับ GraphQL ใน WordPress ตลอดระยะเวลากว่า 4 ปีที่ผ่านมาที่พัฒนา (เริ่มในเดือนพฤศจิกายน 2016) มันสะสม ดาวมากกว่า 2.8k ใน repo, ชุมชน กว่า 4600 ผู้ติดตาม และ เกือบ 100 ผู้มีส่วนร่วมในโครงการ

มันไปถึงเวอร์ชัน 1.0 และ อัปโหลดไปยังไดเรกทอรีปลั๊กอินใน wp.org ในเดือนพฤศจิกายน 2020 นับตั้งแต่นั้น มันสะสมการติดตั้งที่ใช้งานอยู่กว่า 8000 รายการ ปัจจุบันเป็นทางออกเดียวสำหรับ การดึงเนื้อหา WordPress มาใช้กับ Gatsby และล่าสุด หลายโครงการได้เพิ่มมันลงในสแตกของพวกเขา รวมถึง Headless framework ของ WPEngine และ Next.js WordPress starter ของ WebDevStudios

กล่าวโดยสรุป WPGraphQL ได้รับความนิยมสูง

การพัฒนา Gato GraphQL เริ่มต้นอย่างจริงจังเมื่อประมาณ 1.5 ปีที่แล้ว (เป็นส่วนหนึ่งของโครงการที่ใหญ่กว่า) และมัน "พอใช้ได้" เมื่อ 6 เดือนที่แล้ว ได้รับ 150 ดาวใน repo นับตั้งแต่นั้น ปลั๊กอินปัจจุบัน อยู่ที่เวอร์ชัน 0.7 และยังอีกหลายเดือนกว่าจะถึง 1.0 (ตัวอย่างเช่น ยังไม่มี categories ใน schema)

เดือนที่แล้ว ฉันได้เปิดตัวไซต์ปัจจุบัน gatographql.com และตั้งแต่นั้น ฉันได้โปรโมตปลั๊กอินผ่าน บล็อก (เช่นบทความที่คุณกำลังอ่านอยู่นี้) และยังได้เผยแพร่ บทความแนะนำบน CSS-Tricks ความพยายามเหล่านี้นำผู้คนมายังไซต์หลายร้อยคน และมีผู้เข้าชมกว่า 100 คนดาวน์โหลดปลั๊กอิน

กล่าวโดยสรุป Gato GraphQL ค่อยๆ แต่着実に ได้รับความนิยม และยังอยู่ระหว่างการพัฒนา

ผู้ชนะในยกนี้: WPGraphQL

​

ยกที่ 2: ความพร้อมของส่วนขยาย

ส่วนขยายช่วยให้สามารถโต้ตอบกับปลั๊กอินอื่นผ่าน Gato GraphQL ได้

WPGraphQL มีส่วนขยายสำหรับ ACF, WooCommerce, Yoast และอีกสองสามตัว

Gato GraphQL ยังไม่มีส่วนขยาย และฉันไม่คาดว่าจะมีมากก่อนที่จะปล่อยเวอร์ชัน 1.0

อย่างไรก็ตาม Gato GraphQL ให้ความสำคัญอย่างมากกับส่วนขยายในสถาปัตยกรรม ช่วยให้ผู้ใช้สามารถจัดการได้ (เปิดใช้งาน, ปิดใช้งาน, กำหนดค่า, และอ่านเอกสารประกอบ) จากที่เดียว คือหน้า "Modules":

กล่าวโดยสรุป ในขณะที่ WPGraphQL มีส่วนขยายอยู่แล้ว Gato GraphQL กำลังเตรียมพื้นที่สำหรับพวกมัน

ผู้ชนะในยกนี้: WPGraphQL

​

ยกที่ 3: กลุ่มเป้าหมาย

WPGraphQL มุ่งเป้าไปที่นักพัฒนา: หากคุณต้องการดึงข้อมูลจากไซต์ WordPress ของคุณ คุณต้องเก็บ GraphQL query ไว้ที่ไหนสักแห่งในโค้ด (น่าจะอยู่ในฟังก์ชัน JavaScript บางตัว) จากนั้น เพื่อให้ใช้งานได้ คุณต้องเก่งเรื่องการเขียนโปรแกรมพอสมควร

Gato GraphQL ในทางกลับกัน ยึดตามปรัชญา WordPress ที่ว่าทุกคนควรใช้มันได้ รวมถึงผู้ที่ไม่ใช่นักเทคนิค เพื่อบรรลุเป้าหมายนี้ มันช่วยให้สร้างและจัดการ GraphQL query ผ่าน WordPress editor ได้ ทำให้การทำให้ข้อมูลของไซต์ WordPress เข้าถึงได้ผ่าน API ง่ายพอๆ กับการสร้างบล็อกโพสต์

นอกจากนี้ Gato GraphQL ให้ความสำคัญมากขึ้นกับการนำเสนอ client เพื่อโต้ตอบกับบริการ GraphQL ในลักษณะภาพ ในขณะที่ทั้งสองปลั๊กอินมี GraphiQL client สำหรับรัน query เฉพาะ Gato GraphQL เท่านั้นที่มี Voyager client สำหรับสำรวจ schema แบบโต้ตอบ:

ผู้ชนะในยกนี้: Gato GraphQL

​

สไตล์โค้ดและมาตรฐาน

มาพูดถึงโค้ดกัน!

หากคุณใช้ GraphQL มีโอกาสสูงที่คุณกำลังทำ headless WordPress และเรนเดอร์เว็บไซต์โดยใช้ JavaScript framework บางตัว ซึ่งเป็นรูปแบบสมัยใหม่ ยิ่งกว่านั้น WordPress อาจเป็น CMS เก่า แต่ GraphQL เป็น interface สมัยใหม่ในการเข้าถึงข้อมูลจากไซต์ ดังนั้น ฉันสามารถสันนิษฐานได้อย่างปลอดภัยว่าคุณเป็นนักพัฒนาที่ฉลาด ชอบเขียนโค้ดที่สวยงาม และไม่ยอมรับการใช้ทางออกที่ด้อยกว่า

โค้ด (จาก codebase ของพวกเขาเอง และที่คาดหวังจาก implementation แบบกำหนดเองของเรา) จากทั้งสองปลั๊กอินนี้สวยงามแค่ไหน?

​

ยกที่ 4: ข้อกำหนด PHP

ทั้ง WPGraphQL และ Gato GraphQL ต้องการ PHP 7.1+

อย่างไรก็ตาม มีความแตกต่าง: Gato GraphQL ถูก เขียนด้วย PHP 7.4 จริงๆ แล้ว transpile มาเป็น PHP 7.1 สำหรับ production

ดังนั้น การเขียนโค้ดสำหรับ Gato GraphQL จึงน่าพึงพอใจมากกว่า: คุณสามารถใช้ฟีเจอร์ PHP ใหม่ๆ ได้ รวมถึง object type, typed properties และ arrow functions และเมื่อเพิ่มรองรับ PHP 8.0 (ซึ่งจะเกิดขึ้นเมื่อปล่อยเวอร์ชันใหม่ของ Lando) คุณจะสามารถใช้ union types, match expression และอื่นๆ ได้ด้วย

ผู้ชนะในยกนี้: Gato GraphQL

​

ยกที่ 5: แนวทางการเขียนโค้ด

มาเริ่มกันที่ WPGraphQL ก่อน มุ่งไปที่ repo wp-graphql/wp-graphql มีบางอย่างที่โดดเด่นสำหรับฉัน:

ซูมเข้าไป:

ขอโทษ แต่มีวิธีเดียวที่ฉันจะตอบสนองต่อเรื่องนี้ได้:

การ commit โฟลเดอร์ vendor ของ Composer ลงใน repo เป็นแนวทางที่ไม่ดี และ Composer ก็ไม่แนะนำอย่างชัดเจน

การแก้ไขปัญหานี้ไม่ยาก (ฉันแม้แต่ อธิบายวิธีที่อิงกับ GitHub actions) ดังนั้นฉันสงสัยว่าทำไมมันถึงยังอยู่ที่นั่น

ฉันจะบอกว่าในยกนี้ WPGraphQL กำลังชกตัวเอง!

มาต่อกันเลย การพัฒนาสำหรับ WPGraphQL ต้องรู้จัก hook (actions และ filters) จำนวนมากมาย ไปที่ Developer reference ของ WPGraphQL เราสามารถประเมินขอบเขตของสิ่งนี้ได้

เพื่อถ่ายภาพ รายการ actions ฉันต้องซูมเบราว์เซอร์ออกไปที่ 50%:

สำหรับ รายการ filters ฉันซูมออกไปที่ 30% (ต่ำสุดที่ Firefox รองรับ) และแม้แต่นั้นก็ไม่สามารถจับภาพรายการทั้งหมดได้:

มาเปลี่ยนมาที่ repo GatoGraphQL/GatoGraphQL ซึ่งเป็น monorepo ที่มี Gato GraphQL (รวมถึงโครงการอื่นๆ)

ต่อไปนี้คือลักษณะบางอย่างของโค้ด:

✅ สอดคล้องกับมาตรฐาน PSR-1, PSR-4 และ PSR-12

✅ โค้ดทั้งหมดแบ่งออกเป็นแพ็กเกจย่อยหลายตัว และทั้งหมด (กว่า 100 สำหรับปลั๊กอิน กว่า 200 สำหรับโครงการทั้งหมด) โฮสต์อยู่ใน monorepo เดียวกัน

✅ ใช้ Composer เพื่อจัดการ dependencies ทั้งหมด

✅ ใช้ Symfony Dependency Injection เพื่อจัดการ services ทั้งหมดในแอปพลิเคชัน เพื่อลงทะเบียน type resolver, field resolver หรือ directive resolver ใหม่ เราเพียงแค่ต้องลงทะเบียน service ใหม่ใน container

✅ ทุก class เป็น service และ Symfony Dependency Injection ดูแลการ autowire แอปพลิเคชันทั้งหมดเข้าด้วยกัน

✅ GraphQL server พื้นฐาน ไม่ขึ้นอยู่กับ CMS Gato GraphQL ปรับใช้ contracts สำหรับ WordPress และเพิ่ม logic แบบกำหนดเองเล็กน้อย (เช่น เพื่อให้มี client)

โค้ดเฉพาะ WordPress มีเพียงประมาณ 10% ของโค้ดทั้งหมด การทำซ้ำ 10% นี้สำหรับ framework หรือ CMS อื่น (Laravel/Drupal/etc) สามารถให้ implementation ของ GraphQL server สำหรับพวกมันได้เช่นกัน

✅ เป็นผลมาจากการไม่ขึ้นอยู่กับ CMS การเขียน resolver หมายถึงการเขียน business logic ทั่วไป ที่ขับเคลื่อนด้วย services ที่นำกลับมาใช้ใหม่ได้ เราไม่เคยคิดในแง่ของโค้ด WordPress และแทบไม่ต้องจัดการกับหนี้ทางเทคนิคของมัน

✅ ในทำนองเดียวกัน GraphQL schema ไม่ใช่สำเนา 1:1 ของ WordPress data model หลีกเลี่ยงหนี้ทางเทคนิคที่สะสมโดย WordPress ในชั้นข้อมูล และให้ interface ที่สะอาด

✅ ปัญหา N+1 ของ GraphQL ไม่สามารถเกิดขึ้นได้ โดยการออกแบบสถาปัตยกรรม และโดยไม่รบกวนนักพัฒนาเลย

✅ เซิร์ฟเวอร์ไม่ใช่แค่ GraphQL server: มันคือ API server จริงๆ ที่ response สามารถส่งออกในรูปแบบหรือ specification อื่นได้ (เช่น REST) จาก single source of truth (รายละเอียดเพิ่มเติมในยกที่ 11)

✅ ไม่มีการ commit ไดเรกทอรี vendor แต่ source code ถูกแปลงเป็น distribution code (กล่าวคือ ปลั๊กอินสุดท้ายที่ติดตั้งบนไซต์ WordPress) ผ่าน GitHub actions และ deploy ไปยัง repo dist ซึ่งมีโฟลเดอร์ vendor อยู่

✅ เมื่อสร้างโค้ดสำหรับการแจกจ่าย มัน ถูก scope ด้วย PHP-Scoper และ source code ที่มีโค้ด PHP 7.4 ถูก transpile มาเป็น PHP 7.1

✅ เนื่องจากได้แก้ปัญหา scoping ปลั๊กอินจึงสามารถพึ่งพา dependencies ของ third-party ใดก็ได้ ปัจจุบันใช้ Symfony's DependencyInjection, Cache และ Dotenv, Guzzle (สำหรับโต้ตอบกับ external APIs), League's Pipeline และอื่นๆ อีกหลายตัว

สิ่งนี้สำคัญไม่ใช่แค่ในปัจจุบัน แต่ยังสำหรับอนาคตด้วย: ฉันมั่นใจได้ว่าสามารถใช้ dependency ใดก็ได้จาก repository Packagist ดังนั้นฉันไม่จำเป็นต้องประดิษฐ์ล้อใหม่

✅ Fields ถูก subscribe ไปยัง types ทำให้ขยาย GraphQL schema ได้ง่าย

ผู้ชนะในยกนี้: Gato GraphQL (ด้วยส่วนต่างที่มาก ฉันกล้าพูดได้ ถ้าคุณไม่ว่าอะไร)

​

ยกที่ 6: การขยาย schema

มาเพิ่ม field ลงใน GraphQL schema กัน

เรา ทำตาม tutorial สำหรับ WPGraphQL โค้ดที่แนะนำคือโค้ดด้านล่าง มันประกาศ action hook เพื่อรันฟังก์ชันที่ประกาศ array ทั้งคำอธิบายของ fields และการประมวลผลของมันถูกระบุภายใน array:

add_action( 'graphql_register_types', function() {
 
	register_graphql_field( 'RootQuery', 'myNewField', [
		'type' => 'String',
		'args' => [
			'myArg' => [
				'type' => 'String',
        'description' => __( 'Description for how the argument will impact the field resolver', 'your-textdomain' ),
			],
		],
		'resolve' => function( $source, $args, $context, $info ) {
			if ( isset( $args['myArg'] ) ) {
				return 'The value of myArg is: ' . $args['myArg'];
			}
			return 'test';
		},
	]);
 
});Copy

ตัวอย่างนี้เรียบง่ายที่สุดเท่าที่จะเป็นได้: resolver แทบจะไม่ทำอะไรเลย แต่ฉันก็ยังมีปัญหาในการมองโค้ดแล้วเข้าใจทันทีว่ามันทำอะไร ไม่ใช่ฉันกำลังเย้ยหยัน: สีทั้งหมดจากโค้ดนั้นในเอดิเตอร์ของฉันต่างแย่งความสนใจ นอกจากนี้ยังไม่มีการแยกความรับผิดชอบ และโค้ดดูเหมือนจะไม่สามารถนำมาใช้ซ้ำได้มากนัก

ดังนั้น มันจึงขึ้นอยู่กับนักพัฒนา (กล่าวคือคุณ) ที่จะทำให้โค้ดอ่านง่าย นำมาใช้ซ้ำได้ ปราศจากบั๊ก และอื่นๆ อีกมากมาย ขณะพัฒนาแอปพลิเคชัน; library เองดูเหมือนจะไม่ช่วยมากในเรื่องนี้

ฉันเรียกสไตล์นี้ว่า "ADD": Array-Driven Development ฉันไม่อาจบอกได้ว่าฉันชอบมัน

(เพื่อความยุติธรรมต่อ WPGraphQL นี่เป็นแนวทางการเขียนโค้ดมาตรฐาน และยังเป็นแนวทางที่ engine พื้นฐาน webonyx/graphql-php ใช้ด้วย)

ใน Gato GraphQL โค้ดทั้งหมด เป็นแบบ SOLID เพื่อลงทะเบียน field ใน GraphQL schema เราสร้าง class ที่ implement interface FieldResolverInterface (จริงๆ แล้ว ขยายจาก AbstractSchemaFieldResolver ซึ่งมี methods ที่ implement ไว้แล้วหลายตัว) และเรา ลงทะเบียนมันใน container

ตัวอย่างเช่น โค้ดนี้ ให้ fields username, email และ url แก่ User type:

class UserFieldResolver extends AbstractSchemaFieldResolver
{
  public static function getClassesToAttachTo(): array
  {
    return [
      UserTypeResolver::class,
    ];
  }
 
  public static function getFieldNamesToResolve(): array
  {
    return [
      'username',
      'email',
      'url',
    ];
  }
 
  public function getSchemaFieldDescription(TypeResolverInterface $typeResolver, string $fieldName): ?string
  {
    $descriptions = [
      'username' => $this->translationAPI->__("User's username handle", "users"),
      'email' => $this->translationAPI->__("User's email", "users"),
      'url' => $this->translationAPI->__("URL of the user's profile in the website", "users"),
    ];
    return $descriptions[$fieldName];
  }
 
  public function getSchemaFieldType(TypeResolverInterface $typeResolver, string $fieldName): ?string
  {
    $types = [
      'username' => SchemaDefinition::TYPE_STRING,
      'email' => SchemaDefinition::TYPE_EMAIL,
      'url' => SchemaDefinition::TYPE_URL,
    ];
    return $types[$fieldName];
  }
 
  public function resolveValue(TypeResolverInterface $typeResolver, object $user, string $fieldName, array $fieldArgs = [])
  {
    switch ($fieldName) {
      case 'username':
        return $this->usersAPI->getUserLogin($user);
 
      case 'email':
        return $this->usersAPI->getUserEmail($user);
 
      case 'url':
        return $this->usersAPI->getUserURL($user);
    }
 
    return null;
  }
}Copy

ฉันเชื่อว่าทางออกของฉันสวยงามกว่าของ WPGraphQL อย่างไรก็ตาม นั่นเป็นเรื่องของรสนิยม ฉันรู้ว่านักพัฒนาหลายคนไม่ได้รังเกียจ Array-Driven Development และจริงๆ แล้วชอบมันมากกว่า เนื่องจากในก้อนโค้ดที่กระชับ พวกเขาสามารถ implement logic ทั้งหมดได้

ผู้ชนะในยกนี้: เสมอกัน

​

พักครึ่งเวลา

คืนนี้มันช่างยอดเยี่ยมเหลือเกิน ท่านสุภาพบุรุษและสุภาพสตรีทั้งหลาย

เราเดินทางมาถึงครึ่งทางของการต่อสู้แล้ว นี่จึงเป็นเวลาที่ดีสำหรับการพักผ่อน และพูดคุยถึงสิ่งที่เราได้สัมผัสมาจนถึงตอนนี้

(ระหว่างนี้ ผมควรแสดงโฆษณาจาก ผู้สนับสนุนของผม น่าเสียดายที่ยังไม่มีเลย หากคุณต้องการให้บริษัทของคุณสนับสนุนการพัฒนา Gato GraphQL และได้รับการประชาสัมพันธ์ในสื่อชั้นนำอย่างงานนี้ ส่งข้อความมาหาผม)

การแข่งขันนี้ช่างน่าตื่นเต้น! WPGraphQL เริ่มต้นมาด้วยไฟและความดุดันอย่างมาก! เขาเปิดการแข่งขันในสภาพที่ยอดเยี่ยม ส่งหมัดที่ทรงพลังอย่างน่ากลัวไปยัง Gato GraphQL ซึ่งแทบจะยืนด้วยสองเท้าของตัวเองไม่ไหว หมัดแล้วหมัดเล่าแล้วหมัดเล่า ผมไม่อยากจะอยู่ในสถานการณ์ของ Gato GraphQL เลย

ผมต้องยอมรับว่า หลังจาก 2 ยกแรก ผมคิดว่าการแข่งขันจะสิ้นสุดในไม่ช้า ผมคาดหวังว่าจะมีการน็อกดาวน์ในทุกขณะ จะเห็นผ้าเช็ดหน้าโบกสะบัดขอความเมตตา แต่ Gato GraphQL ก็ยืนหยัด เราต้องยอมรับในความเด็ดเดี่ยวของเขา นั่นเป็นสิ่งที่น่าทึ่งอย่างแท้จริง!

แล้วการเปลี่ยนแปลงก็เกิดขึ้น ไม่ว่าจะเป็นตั้งแต่ยกที่ 3 เป็นต้นไป Gato GraphQL ดูเหมือนจะได้พลังงานมาจากที่ไหนสักแห่ง และเริ่มไม่เพียงแต่ป้องกันตัวเอง แต่ยังโต้กลับด้วยหมัดหลายครั้ง ซึ่งหลายหมัดลงไปที่หน้าของ WPGraphQL ผมเห็น WPGraphQL สั่นสะท้าน! เราไม่เคยเห็นสิ่งเช่นนี้จากแชมป์โลกคนปัจจุบันของเรามาก่อน นี่เป็นการเปลี่ยนแปลงที่น่าทึ่งอย่างแท้จริงที่เราเพิ่งได้สัมผัส!

แล้วเมื่อความมั่นใจของคู่ต่อสู้สั่นคลอน ตั้งแต่ยกที่ 4 Gato GraphQL ก็ตัดสินใจส่งหมัดชุดร้ายแรงออกไป นั่นช่างน่าตกใจ! โชคดีที่เผชิญหน้ากับเขาคือแชมป์โลกของเรา WPGraphQL ซึ่งสามารถทนต่อหมัดเหล่านั้นได้ ด้วยการเชียร์และความเห็นอกเห็นใจจากฝูงชน เขาเป็นวีรบุรุษตัวจริง! ใครก็ตามคงล้มลงในทันที แต่ไม่ใช่เขา เขายืนหยัดต่อหมัดเหล่านั้นในฐานะแชมป์ที่เขาเป็น

แต่เขาจะเป็นแชมป์ไปอีกนานแค่ไหน? ยังไม่มีใครน็อกดาวน์ ยังไม่มีใครโยนผ้า การต่อสู้อาจพลิกผันได้ทุกขณะ นักสู้ทั้งสองรู้ว่าตัวเองต้องการอะไร และผมแน่ใจว่าพวกเขาจะกลับออกมาอีกครั้งด้วยพลังทั้งหมดและความมุ่งมั่นทั้งหมด เพื่อโจมตีคู่ต่อสู้และเอาชนะ

การแข่งขันนี้ช่างยอดเยี่ยม!

และตอนนี้ ท่านสุภาพบุรุษและสุภาพสตรีทั้งหลาย นักสู้ทั้งสองกำลังกลับเข้าสู่เวที

ดำเนินการต่อสู้ต่อไป!

​

ประเด็นที่ต้องใส่ใจ

เซิร์ฟเวอร์ GraphQL จำเป็นต้องใส่ใจในหลายสิ่งหลายอย่าง เพียงเพื่อตอบสนองข้อเสนอที่ว่า "ดึงข้อมูลที่คุณต้องการ ไม่มากไม่น้อยไปกว่านั้น"

ตัวอย่างเช่น:

• มีความปลอดภัยแค่ไหน? เราจะมั่นใจได้อย่างไรว่าเราไม่ได้เปิดเผยข้อมูลส่วนตัวบน endpoint สาธารณะ?
• มีประสิทธิภาพแค่ไหน? เราจะลดภาระของเซิร์ฟเวอร์ได้อย่างไรเมื่อส่ง queries เดิมซ้ำแล้วซ้ำเล่า พร้อมกับทำให้มันเร็วที่สุดเท่าที่เป็นไปได้?
• ใช้งานง่ายแค่ไหน? มีการผสมผสานกับ WordPress ได้ดีแค่ไหน เพื่อใช้ประโยชน์จากฟีเจอร์ที่ CMS มอบให้?

และคำถามอีกมากมาย นี่เป็นเพียงตัวอย่างเล็กน้อยที่ผมเลือกมา ซึ่งผมจะจัดการใน 3 ยกต่อไปนี้

​

ยกที่ 7: Persisted queries

Persisted queries รวมเอาสิ่งที่ดีที่สุดของทั้ง GraphQL และ REST เข้าด้วยกัน: ถูกสร้างขึ้นโดยใช้ GraphQL ดังนั้นจึงไม่มีการดึงข้อมูลมากหรือน้อยเกินไป แต่ถูกเผยแพร่บนเซิร์ฟเวอร์เป็น endpoint พร้อม URL ของตัวเอง

Persisted queries มอบประโยชน์เหล่านี้:

✅ ปลอดภัย: แทนที่จะให้สิทธิ์การเข้าถึงข้อมูลใดๆ ผ่าน endpoint เดียว เราสามารถกำหนดล่วงหน้าว่าจะเปิดเผยข้อมูลอะไร

✅ รวดเร็ว: เนื่องจากเข้าถึงผ่าน URL ของตัวเอง จึงสามารถแคชได้ในทุกชั้นระหว่างไคลเอนต์และ back-end (ในเซิร์ฟเวอร์ CDN เบราว์เซอร์) โดยใช้มาตรฐาน HTTP caching

WPGraphQL รองรับ persisted queries ผ่านส่วนขยายทั้งสองนี้:

• WPGraphQL Lock
• WPGraphQL Persisted Queries

นอกจากนี้ Jason Bahl (ผู้สร้าง WPGraphQL) ประกาศเมื่อเร็วๆ นี้ว่าในอนาคตอันใกล้ เขาจะเพิ่มการรองรับ persisted queries ใน WPGraphQL

ผมสงสัยว่าเขามีแนวคิดอะไรอยู่ เนื่องจากมีส่วนขยาย 2 ตัวอยู่แล้ว จะแตกต่างจากสิ่งเหล่านั้นอย่างไร? บางทีเขาต้องการทำให้เป็นส่วนหนึ่งของ core ของปลั๊กอิน เพื่อเสริมสร้างมาตรการความปลอดภัยโดยรวมของปลั๊กอินโดยไม่ต้องพึ่งพาบุคคลที่สาม?

หรือบางทีเขาเห็นการใช้งานจาก Gato GraphQL และต้องการมอบประสบการณ์ที่คล้ายคลึงกัน โดยใช้งานผ่าน visual editor แทนโค้ดล้วนๆ?

ซึ่งนำเราไปสู่ Gato GraphQL มันไม่เพียงแต่ มี persisted queries แต่ยังพยายามทำให้มันเป็นส่วนสำคัญของการนำเสนอ:

✅ ปลั๊กอินเปิดใช้งาน การปิดการใช้งาน single endpoint และผู้ใช้ได้รับการส่งเสริมให้เปิดเผยข้อมูลผ่าน persisted queries เท่านั้น

(ในทางกลับกัน WPGraphQL เพียง ปิดใช้งาน introspection โดยค่าเริ่มต้น ไม่ใช่ endpoint จริงๆ กล่าวอีกนัยหนึ่ง ผู้โจมตียังคงสามารถเข้าถึงข้อมูลส่วนตัวได้ พวกเขาเพียงแค่ถูกทำให้งานของพวกเขายากขึ้น เนื่องจากพวกเขาจะไม่รู้ล่วงหน้าว่ามีข้อมูลส่วนตัวอะไรบ้าง)

✅ ผสมผสานอย่างลึกซึ้งกับ WordPress editor ดังนั้นการสร้าง persisted query จึงใช้ความพยายามเท่ากับการสร้างบล็อกโพสต์ และทุกคนสามารถทำได้ ไม่ใช่แค่โปรแกรมเมอร์

✅ Persisted queries ไม่ใช่แบบ static: สามารถใช้ GraphQL variables ได้ ซึ่งค่าของมันสามารถระบุผ่าน URL params เมื่อรันกับ endpoint

ดูประสบการณ์การ สร้าง และรัน persisted query ในปลั๊กอินของผม:

ผู้ชนะในยกนี้: Gato GraphQL

​

ยกที่ 8: การแคช

GraphQL มีจุดอ่อนที่ใหญ่: มันไม่สามารถแคชได้ง่าย เหตุผลคือมันต้องการส่งการดำเนินการ POST ไปยัง endpoint เดียว เนื่องจาก endpoint เดียวจะให้ผลลัพธ์ที่แตกต่างกัน และเนื่องจาก queries ถูกส่งใน body ของ request แทนที่จะเป็น URL parameters จึงไม่สามารถแคช single endpoint ได้

โซลูชันมาตรฐานที่เสนอโดยเซิร์ฟเวอร์ GraphQL หลายตัวคือการย้ายการแคชไปที่ไคลเอนต์ และพึ่งพา ID ของออบเจ็กต์เป็นตัวระบุของเอนทิตีที่จะแคชแทน URL ของ endpoint ไลบรารีที่ได้รับความนิยมมากที่สุดที่มอบฟังก์ชันการทำงานนี้คือ Apollo client

มี การอภิปรายใน WPGraphQL repo เกี่ยวกับตัวเลือกทั้งหมดที่มีสำหรับการแคชใน WPGraphQL น่าสนใจที่ส่วนใหญ่เป็นเครื่องมือภายนอก (เช่น Apollo client หรือ WordPress Object Cache) ซึ่งหมายความว่าต้องเพิ่มชั้นพิเศษให้กับแอปพลิเคชัน เพิ่มความซับซ้อน และยังอาจทำให้ช้าลงด้วย

(เหตุผลเหล่านี้อาจเป็นส่วนหนึ่งของการตัดสินใจนำ persisted queries มาใช้งานแบบ native ใน WPGraphQL)

ตัวอย่างเช่น Apollo client ทำงานบนไคลเอนต์ หากเข้าถึงเว็บไซต์จากโทรศัพท์มือถือรุ่นราคาถูกที่ไม่มีพลังงานมาก JavaScript โค้ดพิเศษนั้นจะส่งผลกระทบต่อประสิทธิภาพของแอปพลิเคชัน

เช่นเดียวกัน นักพัฒนาที่ทำงานกับ WordPress อาจมีความเชี่ยวชาญด้าน PHP แต่ไม่มากนักด้าน JavaScript ตอนนี้การแคช API ของพวกเขาจะหมายความว่าพวกเขาต้องกังวลเกี่ยวกับชั้น JavaScript ด้วย

Gato GraphQL ฉลาดกว่าในเรื่องนี้ เนื่องจากมี persisted queries หมายความว่า queries จะถูกรันบน endpoint ของตัวเอง จึงสามารถ แคช URL ของ endpoint เหล่านี้ผ่าน HTTP caching

HTTP caching header มีค่า max-age ที่คำนวณโดยอัตโนมัติจากค่า max-age ทั้งหมดสำหรับทุก field ใน queries และข้อมูลนี้ ได้รับการกำหนดค่าโดยใช้ WordPress editor บนพื้นฐาน field ต่อ field

ด้วยเหตุนี้ API จึงสามารถแคชได้ในหลายชั้น (ในไคลเอนต์ CDN และเซิร์ฟเวอร์) และจัดการได้แบบ native ภายในปลั๊กอิน โดยไม่จำเป็นต้องเพิ่มชั้นอื่น

ดูวิดีโอนี้ที่แสดงวิธีการแคช API endpoint:

ผู้ชนะในยกนี้: Gato GraphQL

​

ยกที่ 9: การผสมผสานกับ Gutenberg

เคยมีช่วงเวลาที่ Gutenberg จะเป็นอนาคตของ WordPress แต่ไม่ใช่อีกต่อไปแล้ว: Gutenberg ตอนนี้คือปัจจุบันของ WordPress (ดังนั้นเราจึงสามารถเรียกมันว่า WordPress editor) และ Full Site Editing ได้กลายเป็นอนาคตใหม่

ไม่ต้องพูดถึงว่า API ของเราจำเป็นต้องมีการผสมผสานที่ดีกับ WordPress editor ซึ่งหมายถึงไม่เพียงแต่การดึงและโพสต์ข้อมูลสำหรับบล็อก แต่ยังรวมถึงการขับเคลื่อนฟีเจอร์ใน WordPress editor เองด้วย

ตัวอย่างเช่น เนื่องจาก GraphQL subscriptions สามารถให้เซิร์ฟเวอร์ push ข้อมูลไปยังไคลเอนต์แบบ real time จึงเหมาะสำหรับการขับเคลื่อนฟีเจอร์ collaborative editing และ notifications

WPGraphQL สามารถ query ข้อมูลบล็อกได้ผ่านส่วนขยาย WPGraphQL Gutenberg ส่วนขยายนี้สร้าง type ใหม่เพื่อ map ทุกบล็อก ดังนั้นเราจึงมี CoreParagraphBlock, CoreQuoteBlock เป็นต้น

Gato GraphQL จะสามารถ query ข้อมูลบล็อกได้ในไม่ช้า (อยู่ระหว่างการพัฒนา) อย่างไรก็ตาม แทนที่จะสร้าง type ใหม่ต่อบล็อก มันจะมี Block type เดียวเพื่อแทนบล็อกทั้งหมด และเราสามารถแยก metadata เฉพาะของบล็อกบางอันตามชื่อของมันได้

ตัวอย่างเช่น ดูวิธีการแปลเนื้อหาภายใน paragraph block (โดยใช้ directive @strTranslate ซึ่งเชื่อมต่อกับ Google Translate API):

query TranslateStringsInBlocks {
  post(by: { id: 1657 }) {
    title
    paragraphBlocks: blockDataItems(
      filterBy: { include: "core/paragraph" }
    )
    translatedParagraphBlocks: blockDataItems(
      filterBy: { include: "core/paragraph" }
    )
      @underJSONObjectProperty(by: { path: "attributes.content" })
        @underEachArrayItem
          @strTranslate(from: "en", to: "fr")
  }
}Copy

ผู้ชนะในยกนี้: เสมอกัน

​

ขยายขอบเขต

"ฉันมีความฝัน"

บล็อก Gutenberg ถูกออกแบบมาเพื่อมอบ interface เดียวสำหรับการสร้างเนื้อหาใน WordPress ซึ่งลดความซับซ้อนในการพัฒนาโค้ดสำหรับ CMS และการเรียนรู้ที่ต้องการจากผู้ใช้อย่างมาก

แม้ว่าจะถูกนำมาใช้สำหรับการสร้างเนื้อหา แต่บล็อกกำลังค่อยๆ เข้ายึดครองพื้นที่อื่นๆ ทั้งหมดของ CMS รวมถึง widgets เมนู และเร็วๆ นี้คือธีมผ่าน Full Site Editing และในอนาคต มันจะรองรับความสามารถหลายภาษาและ collaborative editing (ฟีเจอร์ที่เราอาจคิดไม่ถึงเมื่อนึกถึงบล็อก) และใครจะรู้อีกว่าจะมีอะไรอื่นอีก

เราสามารถคิดถึง GraphQL ในแง่เดียวกัน: เป็น interface เดียวสำหรับการโต้ตอบกับข้อมูล หมายความว่าไม่เพียงแต่การดึงและโพสต์ข้อมูล แต่รวมถึงการโต้ตอบใดๆ ที่เกี่ยวข้องกับข้อมูล รวมถึงการแก้ไข

WordPress มีโอกาสพิเศษที่จะกลายเป็น OS ของเว็บอย่างแท้จริง: ระบบที่ขับเคลื่อนโดย Gutenberg ที่ให้ผู้ใช้ป้อนเนื้อหาประเภทใดก็ได้ (ข้อความ รูปภาพ วิดีโอ เสียง ฯลฯ) ประมวลผลผ่านเครื่องมือของตัวเองหรือบริการ cloud บางอย่าง และเผยแพร่ไปยังปลายทางสุดท้าย ไม่ว่าจะเป็นเว็บไซต์ WordPress หรือที่อื่น

แต่เบื้องหลังความฝันอันทรงพลังนี้ ต้องมี API ที่ทรงพลังอย่างแท้จริง เพื่อส่งมอบสิ่งที่เราต้องการ API ที่อาจอิงจาก GraphQL แต่ออกแบบมาเพื่อก้าวข้ามข้อจำกัดของมันด้วย

​

ยกที่ 10: รองรับ custom directives

WPGraphQL ไม่ได้มาพร้อมกับ directive แม้แต่ตัวเดียว ผมไม่ได้บอกว่ามันไม่รองรับ (engine webonyx/graphql-php รองรับ) แต่ว่ามันไม่มีการใช้งาน custom directive ใดๆ

"แล้วยังไง?" คุณอาจคิด "เราต้องการ directives ไปทำไม? ถ้าใครต้องการแก้ไขผลลัพธ์ของ queries พวกเขาสามารถทำได้บนไคลเอนต์ของตัวเอง!"

นี่เป็นเรื่องของความคิดเห็น และไม่มีถูกหรือผิด แต่ขอบอกสิ่งหนึ่ง: directives เป็นฟีเจอร์ที่มีประโยชน์อย่างเหลือเชื่อ ซึ่งช่วยให้ GraphQL แตกต่างจาก REST หากคุณไม่ได้ใช้มัน คุณมักจะไม่ได้ใช้ประโยชน์จาก API ของคุณอย่างเต็มที่

Directives ไม่ได้ถูกควบคุมโดย spec ดังนั้นเซิร์ฟเวอร์ GraphQL จึงสามารถใช้งานได้ตามต้องการ ทำให้มันทรงพลังเท่าที่ต้องการ นั่นคือเหตุผลที่ฟังก์ชันการทำงานใหม่จำนวนมากใน GraphQL ถูกนำมาใช้ครั้งแรกผ่าน directives เช่น @stream และ @defer

Gato GraphQL ปฏิบัติต่อ directives ด้วยความเคารพ พวกมัน ถูกรันเพียงครั้งเดียว พร้อมข้อมูลจากทุกเอนทิตี สำหรับทุก field ที่ถูกนำไปใช้ (ซึ่งอธิบายว่าทำไม directive @strTranslate จึงสามารถดึงผลลัพธ์จาก Google Translate API ได้เร็วมาก) และ GraphQL engine เองก็อิงจาก directive pipeline

อาหา แต่คุณกลัวที่จะทำให้ผู้ใช้สามารถเข้าถึงพลังงานทั้งหมดนี้ใช่ไหม? นั่นเป็นข้อกังวลที่ถูกต้อง แต่คุณก็สามารถปิดการเข้าถึง single endpoint ได้ และให้สิทธิ์เข้าถึงข้อมูลผ่าน persisted queries เท่านั้น ซึ่งคุณ (ผู้ดูแลระบบ) เป็นคนเดียวที่มีสิทธิ์เข้าถึง directives

ดังนั้นคุณได้รับประโยชน์ หรือไม่มีอะไรเกิดขึ้น

ถ้าคุณชอบ directives ยินดีด้วย คุณจะชอบ Gato GraphQL! ❤️

แต่ในทางกลับกัน ถ้าคุณไม่ชอบมัน ก็ไม่มีอะไรเกิดขึ้น

ผู้ชนะในยกนี้: Gato GraphQL

(หากคุณเชื่อว่า "เราไม่ต้องการ directives เหม็นๆ" โปรดอย่าโกรธผม... ผมแค่ทำงานของผม)

​

ยกที่ 11: รองรับ REST

"อาหาา? REST? REST อะไร? เราไม่ได้พูดถึง GraphQL ที่นี่หรือ? ทำไมคุณถึงพูดถึง REST? ทำไมคุณถึงอยากทำให้ชีวิตผมซับซ้อน?"

ใช่ เมื่อมองแรกหัวข้อนี้ดูไม่เข้าพวก แต่ผมได้เพิ่มมันในการเปรียบเทียบนี้ด้วยเหตุผลง่ายๆ: Matt Mullenweg กล่าวว่า เขากำลังพิจารณา GraphQL เพื่อรวมไว้ใน WordPress core ที่มีศักยภาพ และสิ่งที่ผู้มีส่วนร่วมจะกังวลคือการต้องดูแล codebase สองชุด

ซึ่งนำไปสู่คำถามที่ชัดเจน: เซิร์ฟเวอร์ GraphQL สามารถจัดการ REST ได้ด้วยหรือไม่?

คำตอบคือ "ได้บางส่วน" สำหรับ WPGraphQL และ "ได้ทั้งหมด" สำหรับ Gato GraphQL

เกี่ยวกับ WPGraphQL มันเป็นไปได้ที่จะกำหนด REST endpoint ซึ่งเมื่อถูก resolve จะรัน GraphQL queries ที่มี field ที่จำเป็น ไม่ว่าจะเป็นการเรียกภายในไปยัง GraphQL engine หรือการดำเนินการ POST ภายนอกที่รันกับ webserver เดียวกัน

แต่นั่นยังไม่เพียงพอที่จะตอบสนอง WP REST API เพราะมันยัง มี JSON schema และเราไม่สามารถทำโดยไม่มีมันได้

เกี่ยวกับ Gato GraphQL ผมต้องยอมรับว่าผมโชคดี เพราะงานบน underlying engine (server-side component model ที่เรียกว่า PoP) เริ่มต้นเมื่อประมาณปี 2013 นั่นคือหลายปีก่อนที่ผมจะรู้จักสิ่งที่เรียกว่า GraphQL และโปรเจ็กต์นี้พัฒนาขึ้นพร้อมกับแนวคิดของตัวเอง (ซึ่งผมได้บันทึกไว้ใน บทความคลาสสิกของผม)

จากนั้น เมื่อผมเริ่มเขียนโค้ด CMS-agnostic GraphQL server (ซึ่ง Gato GraphQL อยู่บนนั้น) เมื่อประมาณ 1.5 ปีก่อน ผมได้ผสมผสานแนวคิดที่พัฒนาสำหรับ PoP เข้ากับรากฐานที่ GraphQL สร้างขึ้น สร้างระบบที่รองรับ GraphQL spec ในทุกส่วน พร้อมกับสามารถเพิ่มชุดฟีเจอร์ที่แตกต่างออกไป

ในเรื่องนี้ schema ที่ PoP ใช้เป็น API-agnostic และเป็น superset ของ GraphQL schema PoP schema อยู่ที่ /api/graphql/?query=fullSchema

จากนั้น ชั้น GraphQL server จะจัดรูปแบบ PoP schema ตาม GraphQL specification ซึ่งให้ GraphQL schema และในทำนองเดียวกัน เราสามารถสร้าง JSON schema ที่จำเป็นสำหรับ WP REST API ได้

การสร้าง JSON schema นี้ยังไม่ได้ทำ แต่ทำได้

ตอนนี้ สิ่งที่ทำไปแล้วคือการสร้างการตอบสนองของ queries ในหลายรูปแบบ ตัวอย่างเช่น GraphQL queries นี้:

{
  posts {
    id
    title
    date
    author {
      name
    }
  }
}Copy

มันถูก resolve ผ่าน REST endpoint นี้ด้วย: /posts/api/rest/?query=id|title|date|author.name

และเราไม่จำเป็นต้องหยุดแค่นั้น คุณต้องการสร้างผลลัพธ์โดยใช้รูปแบบที่แตกต่างออกไปอีก เช่น XML หรือไม่? ไม่มีปัญหา: /api/?query=posts.id|title|date|author.name&datastructure=xml

(สิ่งนี้อาจช่วยในการใช้งาน ข้อเสนอสำหรับเครื่องมือ import/export ใหม่สำหรับ WordPress ที่อิงจาก schema นอกจากนี้ยังทำให้เห็นชัดขึ้นเล็กน้อยถึงสิ่งที่ผมพูดก่อนหน้า: interface เดียวสามารถขับเคลื่อนการโต้ตอบข้อมูลทั้งหมด ทั้งภายใน CMS และจาก CMS กับ API ภายนอก)

ผู้ชนะในยกนี้: Gato GraphQL

​

ยกที่ 12: รองรับฟีเจอร์ที่มองไปข้างหน้า

GraphQL spec เสร็จสมบูรณ์แล้วหรือไม่? คำตอบคือไม่: spec มีการพัฒนาอยู่ตลอดเวลา ขณะนี้มี 100 open issues หลายอันมีข้อเสนอที่จะถูกทำให้เป็นทางการในอนาคต

ตอนนี้ ในบรรดา 100 issues เหล่านั้น แน่นอนว่าจะมีฟีเจอร์ใหม่ที่เราสามารถได้รับประโยชน์จากวันนี้ได้ใช่ไหม? ถ้าเป็นเช่นนั้น ทำไมต้องรอ?

นั่นคือวิธีคิดของผมพอดี

"แต่ถ้าบางอย่างไม่อยู่ใน GraphQL spec เราไม่ควรเพิ่มมันลงในเซิร์ฟเวอร์ GraphQL หรือผู้ใช้จะสับสน!"

จุดที่ดี อย่างไรก็ตาม หากเราทำให้ฟีเจอร์ใหม่นี้ใช้งานได้เฉพาะแบบ opt-in เท่านั้น ผู้ใช้ก็จะรับรู้ถึงมันอย่างจำเป็น และจะไม่มีปัญหาหรือความเข้าใจผิดเกิดขึ้น

อีกครั้ง นั่นคือวิธีคิดของผม อย่างไรก็ตาม นี่เป็นเรื่องของความคิดเห็น ดังนั้นหากคุณต้องการใช้เฉพาะฟีเจอร์ที่เซิร์ฟเวอร์ GraphQL ทุกตัวในโลกใช้ด้วย ก็ไม่เป็นไร

ผมเชื่อว่านี่คือวิธีที่ WPGraphQL ดำเนินการ อย่างน้อย ผมไม่เคยเห็นฟีเจอร์เดียวที่ก้าวไปเกินกว่าสิ่งที่ได้รับการอนุมัติใน spec

สำหรับ Gato GraphQL ผมสแกนรายการ issues ใน spec เป็นประจำ และหากผมพบฟีเจอร์ที่เจ๋ง ซึ่งสามารถทำได้โดยเซิร์ฟเวอร์ของผมโดยไม่ต้องใช้ความพยายามมาก ผมก็ใช้งานมัน (จริงๆ แล้ว นี่เป็นงานอดิเรกของผม)

นี่คือฟีเจอร์ "มองไปข้างหน้า" ที่ผมได้ใช้งานจนถึงตอนนี้:

✅ Multiple query execution
✅ Schema namespacing
✅ Nested mutations
✅ Composable directives
✅ Proactive feedback
✅ Field and directive-based versioning

และผมวางแผนที่จะเพิ่ม:

✳️ Subscriptions (นี่เป็นส่วนหนึ่งของ spec แล้ว)
✳️ directives @stream และ @defer
✳️ Flat chain syntax

ผู้ชนะในยกนี้: Gato GraphQL

​

คำตัดสิน!

สุภาพสตรีและสุภาพบุรุษทั้งหลาย

คืนที่ไม่มีวันลืมเลือน! การแข่งขันที่เราเพิ่งได้ประสบ! นักสู้หนักสองคนที่ทุ่มเทที่สุดเพื่อความฝันของพวกเขา

ความฝันที่ทั้งคู่กำลังไล่ตาม แต่มีเพียงคนเดียวเท่านั้นที่จะคว้ามันได้

และตอนนี้ เราจะได้รู้ว่าคนนั้นคือใคร ถึงเวลาแห่งความจริงแล้ว!

ใครจะเป็นแชมป์โลก "GraphQL ใน WordPress"?

จะเป็น WPGraphQL แชมป์ปัจจุบันที่ได้รับการยกย่องอย่างกว้างขวาง เป็นที่รักของมวลชน และถูกนำเสนอในสิ่งพิมพ์ชั้นนำ?

หรือจะเป็น Gato GraphQL ผู้ท้าชิงที่กล้าหาญ ไม่เกรงกลัว เหยียบเท้าคุณโดยไม่ขอโทษ และมางานโดยไม่ได้รับเชิญ?

เรากำลังรอคำตัดสินจากกรรมการ ช่างตึงเครียดเสียจริง! โอ้ Santa Maria ขอให้หัวใจฉันทนรับช่วงเวลานี้ได้!

🥁 และ 🥁 ผู้ 🥁 ชนะ 🥁 คือออออออออออออ 🥁 ...

เสมอกัน!

นักสู้ทั้งสอง นักสู้หนักทั้งสอง เสมอกัน!

ช่างเป็นช่วงเวลาที่งดงาม! ผู้ท้าชิงทั้งสองกอดกัน แสดงให้เห็นว่าเราทุกคนเป็นเพื่อนกันในชุมชน WordPress ดั่งครอบครัวใหญ่ที่เราเป็น

แล้วอะไรคือเหตุผลสำหรับผลเสมอ? กรรมการอธิบาย:

👑 WPGraphQL เป็นที่นิยมมากกว่า และมีการใช้งานที่แพร่หลายกว่า

👑 Gato GraphQL มีสถาปัตยกรรมที่ดีกว่า และอาจรองรับ WordPress ได้ดีกว่าในระยะยาว

สุภาพสตรีและสุภาพบุรุษทั้งหลาย คุณได้รับคำตัดสินจากกรรมการแล้ว!

และถ้วยรางวัลของเรามีถุงมือสองข้าง: ข้างละหนึ่งคู่สำหรับผู้ท้าชิงแต่ละคน

แต่คำตัดสินของ คุณ คืออะไร?

คุณจะยังคงใช้ WPGraphQL อย่างไม่มีเงื่อนไขสำหรับความต้องการ headless ของคุณ?

หรือคุณจะให้โอกาส Gato GraphQL ตามที่มันเรียกร้อง ดาวน์โหลดปลั๊กอิน และลองใช้ดู?

สุภาพสตรีและสุภาพบุรุษทั้งหลาย นี่คือทั้งหมดสำหรับคืนนี้

เราหวังเป็นอย่างยิ่งว่าคุณได้เพลิดเพลินกับการแข่งขัน

และขอให้เราได้พบปะกันอีกครั้งในเร็ววันระหว่างแชมป์ทั้งสองของเรา

ราตรีสวัสดิ์