🙅‍♀️ ทำไม GraphQL ไม่ควรอยู่ใน WordPress core

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

ไม่นานมานี้ ผมเชื่อว่าGraphQL ควรอยู่ใน WordPress core เหตุผลคือนักพัฒนาต่างใช้เวลาและความพยายามในการพัฒนาฟีเจอร์สำหรับ WP REST API (เช่น batch operations) ซึ่งเป็นสิ่งที่ GraphQL มีอยู่แล้วโดยธรรมชาติ

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

นี่คือเหตุผลของผม

​

1. ไม่เป็นไปตามกฎ 80/20

ในอดีต ฟีเจอร์ใดๆ จะถูกเพิ่มเข้าสู่ WordPress core ก็ต่อเมื่อเป็นไปตามกฎ 80/20 ซึ่งหมายความว่าผู้ใช้ 80% ขึ้นไปจะใช้ฟีเจอร์นั้น

กรณีของ GraphQL จะเป็นเช่นนั้นหรือไม่? ผมคิดว่าคำตอบคือ "ไม่" โดยอ้างอิงจากบรรทัดฐานที่เกิดขึ้นเมื่อมีการเพิ่ม WP REST API เข้าสู่ WordPress 4.7

ใน talk ของเขาเรื่อง WordPress as Data, 5 Years In K. Adam White (หัวหน้าหลักของการพัฒนาและเปิดตัว WP REST API ในช่วงแรก) ได้อธิบายว่านักพัฒนาคาดหวังว่า REST API จะถูกนำไปใช้อย่างแพร่หลายเมื่อถูกรวมมาพร้อมกับ core แต่สิ่งนั้นไม่ได้เกิดขึ้น: นักพัฒนายังคงสร้างเว็บไซต์ WordPress ในแบบเดิม โดยให้ความสนใจน้อยมากกับ "headless" หรือ REST API

โชคชะตาเปลี่ยนไปในภายหลัง เมื่อ Gutenberg editor ถูกเปิดตัวใน WordPress 5.0 ซึ่งอิงจาก REST API แล้ว Gutenberg จะสามารถเป็นเหตุผลในการเพิ่ม GraphQL เข้าสู่ WordPress core ได้หรือไม่?

​

2. Headless ได้รับการตอบสนองผ่าน REST API แล้ว

WordPress editor สามารถพัฒนาด้วย GraphQL server แบบ native ได้ ทำให้นักพัฒนา block สามารถใช้ GraphQL (นอกเหนือจาก REST API ที่มีอยู่แล้ว) เพื่อดึงข้อมูลสำหรับ block ของตน นอกจากนี้ themes และ plugins ยังสามารถใช้ GraphQL เพื่อขับเคลื่อนฟังก์ชันภายในของตนเองได้ นี่คือเหตุผลที่หนักแน่นในการเพิ่ม GraphQL เข้าสู่ WordPress core

อย่างไรก็ตาม WordPress มี REST API อยู่แล้ว และสิ่งที่ทำได้ด้วย GraphQL ก็ทำได้ด้วย REST เช่นกัน การเพิ่ม GraphQL เสริมจาก REST นั้นเหมือนกับการซื้อ BMW ทั้งที่ขับ Toyota อยู่แล้ว คุณจะถึงจุดหมายได้เร็วขึ้น และประสบการณ์การขับขี่จะน่าสนุกยิ่งขึ้น แต่ทั้งสองคันก็พาคุณไปถึงที่หมายได้เหมือนกัน

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

​

3. WordPress themes และ plugins สามารถใช้ webonyx/graphql-php ได้

plugins สาธารณะไม่สามารถบังคับให้เว็บไซต์ติดตั้ง WPGraphQL หรือ Gato GraphQL เพื่อใช้ plugin ได้ เพราะจะลดขอบเขตการเข้าถึงที่เป็นไปได้ ดังนั้นplugins สาธารณะจึงไม่สามารถพึ่งพา GraphQL ได้ ซึ่งน่าเสียดายมาก

ผมคิดอย่างจริงจังเกี่ยวกับปัญหานี้ และได้คิดค้นแนวทางแก้ไขที่เป็นไปได้: GraphQL API Private ซึ่งเป็น GraphQL engine แบบ self-contained ที่ plugins สามารถฝังไว้เพื่อใช้งานของตนเอง โดยเผยแพร่เป็น Composer package (ผมยังไม่ได้เริ่มทำงานในโครงการนี้)

แต่แล้ว เมื่อไม่กี่สัปดาห์ก่อน WordPress plugin ที่ขับเคลื่อนด้วย GraphQL ก็ถูกเปิดตัว ผมสงสัยว่าผู้เขียนทำได้อย่างไร: จะใช้ WPGraphQL หรือ Gato GraphQL ภายใต้ฝากระโปรงหรือไม่? ดังนั้นผมจึงตรวจสอบsource code และปรากฏว่า มันใช้webonyx/graphql-php โดยตรง!

นี่เป็นแนวทางแก้ไขที่น่าสนใจ ซึ่งแสดงให้เห็นว่าด้วยความพยายามเพียงเล็กน้อย นักพัฒนาในปัจจุบันก็สามารถเข้าถึง GraphQL สำหรับ themes และ plugins ของตนได้

plugin นี้ใช้ GraphQL เพื่อดึงข้อมูล entity ของตนเอง ไม่ใช่ข้อมูลของ WordPress (posts, users, comments ฯลฯ) ดังนั้นจึงไม่จำเป็นต้องสร้าง GraphQL schema ที่มี WordPress data model ใหม่ เหมือนที่ WPGraphQL และ Gato GraphQL ทำ (และท้ายที่สุดคือ GraphQL API Private) ด้วยเหตุนี้ การพึ่งพา webonyx/graphql-php จึงสมเหตุสมผล

​

4. GraphQL มีความเสี่ยงเพิ่มเติม

ปัญหาทั้งสามข้อข้างต้นบ่งชี้ว่า GraphQL จะช่วยพัฒนา WordPress แม้ว่าจะไม่น่าสนใจมากนัก ในแง่นี้ เราอาจยังเพิ่ม GraphQL เข้าสู่ WordPress core ได้ และอาจได้รับประโยชน์จากมันหรือไม่มีอะไรเกิดขึ้น

แต่ปัญหาที่ 4 นี้บ่งชี้ว่า หาก GraphQL จะไม่เพิ่มคุณค่ามากนักให้กับ WordPress ก็ไม่ควรเพิ่มเข้าไป เนื่องจากความเสี่ยงที่เพิ่มขึ้น

GraphQL มีความเสี่ยงต่อ attack vector ต่อไปนี้ (รวมถึงอื่นๆ):

• endpoint เดียวให้การเข้าถึงข้อมูลทั้งหมดจากเว็บไซต์ ดังนั้นอาจมีการเปิดเผยข้อมูลส่วนตัวโดยไม่ตั้งใจ
• queries อาจซับซ้อนมากและอาจทำให้ web server และ database server ทำงานหนักเกินไป
• mutation เดิมสามารถถูกเรียกใช้หลายครั้งใน query เดียว และหลาย queries สามารถถูกเรียกใช้พร้อมกันใน request เดียว ทำให้ผู้โจมตีสามารถพยายามเข้าถึง back-end โดยให้ชุดค่าผสมของ user/password จำนวนมาก

การโจมตีเหล่านี้อาจสร้างความเสียหายได้จริง ในการนำเสนอ Damn GraphQL - Defending and Attacking APIs ของเขา นักวิจัยด้าน cybersecurity ชื่อ Dolev Farhi สามารถทำให้เว็บไซต์ WordPress ล่มได้ภายในเวลาน้อยกว่า 30 วินาที ด้วยการโจมตี WPGraphQL endpoint ด้วย batch ของ queries ที่ซับซ้อน

ทีม WPGraphQLแก้ไขปัญหาทันที แต่เราจะแน่ใจได้อย่างไรว่าจะไม่มี exploit อื่นเกิดขึ้น? (ผมหมายถึงไม่ใช่แค่ WPGraphQL เท่านั้น แต่รวมถึง Gato GraphQL ด้วย)

การโจมตีเหล่านี้สามารถเกิดขึ้นกับ GraphQL แต่ไม่ใช่กับ REST เพราะ GraphQL มีพลังมากกว่า REST ในขณะที่ REST นั้น query จะถูกกำหนดไว้ล่วงหน้าและจัดเก็บในเซิร์ฟเวอร์ แต่ใน GraphQL นั้น query จะถูกส่งมาจาก client ณ runtime (เว้นแต่จะใช้ persisted queries)

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

​

สรุป

เพื่อความชัดเจน: ผมไม่ได้สนับสนุนให้ไม่ใช้ GraphQL ใน WordPress (แน่นอนว่าไม่ใช่!) แต่ให้ใช้ GraphQL อย่างมีความรับผิดชอบ GraphQL มีพลัง ซึ่งหมายความว่ามันก็อันตรายด้วย เมื่อใช้ GraphQL เราต้องแน่ใจว่าเรารู้ว่าเรากำลังทำอะไร

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