กดสิ่งนี้: WPGraphQL และ Faust.js

ยินดีต้อนรับสู่ Press This พอดคาสต์ชุมชน WordPress จาก WMR แต่ละตอนนำเสนอแขกรับเชิญจากทั่วชุมชนและการสนทนาเกี่ยวกับปัญหาที่ใหญ่ที่สุดที่นักพัฒนา WordPress ต้องเผชิญ ต่อไปนี้เป็นการถอดความจากการ บันทึกต้นฉบับ

ขับเคลื่อนโดย RedCircle

Doc Pop : คุณกำลังฟัง Press This ซึ่งเป็นพอดคาสต์ชุมชน WordPress บน WMR ในแต่ละสัปดาห์เราจะแนะนำสมาชิกของชุมชน WordPress ฉันเป็นเจ้าภาพของคุณ Doc Pop ฉันสนับสนุนชุมชน WordPress ผ่านบทบาทของฉันที่ WP Engine และการมีส่วนร่วมของฉันบน TorqueMag.Io ที่ซึ่งฉันได้ทำพอดคาสต์และวาดการ์ตูนและวิดีโอแนะนำ ตรวจสอบว่า

คุณสามารถสมัครสมาชิก Press This ได้ที่ Red Circle, iTunes, Spotify หรือคุณสามารถดาวน์โหลดตอนต่างๆ ได้โดยตรงที่ wmr.fm

ในตอนนี้ของ Press This เรากำลังพูดถึง Headless WordPress, GraphQL และ Faust.js เครื่องมือเหล่านี้สามารถใช้ร่วมกันได้อย่างไร และค่าใช้จ่ายประเภทใดที่เกี่ยวข้องกับ Headless WordPress เราจะพยายามเจาะลึกเกี่ยวกับเรื่องนี้ และวันนี้ฉันมีแขกรับเชิญที่ยอดเยี่ยมสองคนมาร่วมงานด้วย ฉันมี Jason Bahl วิศวกรซอฟต์แวร์หลักที่ WP Engine ในเมืองเดนเวอร์ รัฐโคโลราโด ซึ่งเขาดูแล WPGraphQL . และเรามี Chris Weigman ผู้จัดการฝ่ายวิศวกรรมที่ทำงานเกี่ยวกับ Faust.js ฉันมักจะเริ่มรายการเหล่านี้ด้วยการถามแขกเกี่ยวกับเรื่องราวต้นกำเนิดของ WordPress แต่ฉันคิดว่าฉันจะเปลี่ยนสิ่งต่าง ๆ เล็กน้อยที่นี่

เจสัน คุณช่วยบอกเราได้ไหมว่า WPgraphQL คืออะไร และเรื่องราวของ wordPress Origin คืออะไร

Jason Bahl: ใช่แล้ว WPGraphQL เป็นปลั๊กอิน WordPress แบบโอเพ่นซอร์สฟรีที่นำ GraphQL API ไปยังไซต์ WordPress ของคุณและ GraphQL เป็นภาษาแบบสอบถามแบบกราฟ ดังนั้นจึงช่วยให้นักพัฒนาสามารถรับเนื้อหาเข้าและออกจาก WordPress โดยใช้ภาษาแบบสอบถามกราฟ

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

ดังนั้นเมื่อมีเหตุการณ์ต่างๆ เกิดขึ้น เราจำเป็นต้องย้ายข้อมูลไปทั่วเครือข่ายนี้ และเราใช้ WordPress REST API เพื่อดำเนินการย้ายข้อมูลจำนวนมาก และกำลังมีปัญหาบางอย่างกับสิ่งนั้นในทางเทคนิค และเช่นเดียวกับประสิทธิภาพจริงในทางเทคนิค แต่ยังรวมถึงประสบการณ์ของนักพัฒนาซอฟต์แวร์ด้วย ฉันค้นพบเกี่ยวกับ GraphQL ซึ่งเป็นภาษาคิวรีกราฟจริง ซึ่งเปิดแหล่งที่มาโดย Facebook ในปี 2015

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

DP: อืม เจ๋ง คริส คุณช่วยเล่าเรื่องที่คล้ายกันนี้ให้เราฟังได้ไหมว่าเฟาสท์คืออะไร และมันเกิดขึ้นมาได้อย่างไร?

Chris Weigman: แน่นอนว่า Faust เพิ่งเปิดตัวสู่สาธารณะอย่างเป็นทางการในสัปดาห์นี้ เผยแพร่อีกครั้งสู่กรอบสาธารณะสำหรับการสร้างไซต์ WordPress ที่ไม่มีหัวโดยใช้ GraphQL การพัฒนาเริ่มต้นในปี 2020 และเป็นโครงการที่ไม่เป็นทางการของ WP Engine และนี่คือจุดเปลี่ยนหลักที่สาม

พวกเขาเริ่มต้นเป็นส่วนเสริมของ DevRel เริ่มทำให้มันเป็นทางการมากขึ้นเล็กน้อยด้วยและเปลี่ยนเป็นสิ่งที่เรียกว่า GQty และ JavaScript ซึ่งเป็นความคิดแรกของนักพัฒนา และเมื่อฉันเข้ามาคุมทีมในวันที่ 1 ธันวาคมปีที่แล้ว เราก็รู้ว่านั่นไม่ใช่ตลาดเป้าหมายของเรา

เราควรได้รับการพัฒนาสำหรับ WordPress devs เราจึงเริ่มสร้างใหม่อีกครั้ง และในที่สุดก็สามารถเปิดตัวใหม่ได้เมื่อไม่นานนี้

DP: Jason คุณเพิ่งทวีตว่าคุณได้เปิดตัว wpgraphql.com ใหม่บน Faust.js ฉันเชื่อว่าเว็บไซต์ก่อนหน้านี้คือ WordPress หัวขาด คุณช่วยบอกเราเกี่ยวกับการเปลี่ยนแปลงที่คุณทำและคุณทราบได้ไหมว่าคุณกำลังพูดถึงการปรับปรุงอะไรบ้าง

เจบี: อือ ดังนั้น wpgraphql.com จึงเป็นไซต์ที่ไม่มีส่วนหัวมาหลายปีแล้ว ฉันจึงใช้แหล่งข้อมูลหลายแหล่ง ดังนั้นฉันจึงมีเนื้อหามากมายใน WordPress เช่นเดียวกับบล็อกโพสต์ทั้งหมดที่อยู่ใน WordPress

เอกสารบางส่วนมีอยู่ใน WordPress เช่นกัน จากนั้นมีเอกสารบางส่วนอยู่ในไฟล์มาร์กดาวน์ใน GitHub repo เป็นเวลานานที่สุดที่ฉันใช้ Gatsby หรืออาจจะประมาณสามปี ฉันใช้ Gatsby ซึ่งเป็นเฟรมเวิร์ก JavaScript ที่แกนกลางมีชั้นข้อมูลซึ่งคุณสามารถดึงข้อมูลจากหลายแหล่งได้

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

ดังนั้นฉันต้องการใช้ Next ซึ่งเป็นสิ่งที่ Faust สร้างขึ้น มันเป็นเฟรมเวิร์ก JavaScript อื่น แต่ฉันคิดว่ามีชิ้นส่วนที่ขาดหายไปจำนวนมาก ถัดไป และเฟรมเวิร์ก JavaScript เหล่านี้ส่วนใหญ่มีความคิดที่ว่าเฟรมเวิร์กส่วนหน้าของคุณควรกำหนดเส้นทางทั้งหมด ใช่ไหม แต่ถ้าคุณใช้ CMS CMS ของคุณจะกำหนดเส้นทาง

ดังนั้นจึงมีปัญหาทางเทคนิคมากมายในการทำให้สิ่งเหล่านั้นเล่นได้ดี โดยที่ส่วนหน้าของคุณมีความคิดเห็นเกี่ยวกับบางสิ่ง และส่วนหลังของคุณมีความคิดเห็นที่ต่างออกไป เช่นเดียวกับหนึ่งในปัญหาที่ฉันพยายามแก้ไขคือการทำให้ส่วนหน้าของฉันรับรู้ว่า URL หนึ่งๆ เป็นประเภทเฉพาะ จากนั้นจึงแสดงเทมเพลตที่เป็นตัวแทนของสิ่งนั้น

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

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

DP: คริส คุณบอกว่าเฟาสท์มีการเปลี่ยนแปลงบางอย่าง การเปลี่ยนแปลงเหล่านั้นคืออะไร? คุณรู้ไหม เจสันพูดถึงพวกเขา การเปลี่ยนแปลงใดบ้างที่ทำให้การปรับปรุงนี้เป็นไปได้

CW: เน้นที่ WPGraphQL เสมอ มันเป็นอย่างอื่นที่เป็นประเด็นจริงๆ ตัวอย่างเช่น Faust เวอร์ชันหลักล่าสุดใช้ไลบรารีด้านล่างเพื่อโต้ตอบกับ GraphQL ที่เรียกว่า GQty ซึ่งบนกระดาษฟังดูดีมาก แนวคิดที่มาจากทีม Faust ในตอนนั้น เรามาสรุปกันง่ายๆ ว่าผู้คนไม่จำเป็นต้องรู้วิธีสร้างข้อความค้นหาที่ซับซ้อนเหล่านี้

กรอบนี้ควรเป็นนามธรรมสำหรับคุณ บนกระดาษที่ดูดีจริงๆ ในทางปฏิบัติ เนื่องจากความซับซ้อนทั้งหมดของข้อมูล WordPress แม้แต่โพสต์ประเภทเดียวก็สามารถมีรูปแบบที่หลากหลายได้ บางทีคุณอาจผสมมันเข้ากับหมวดหมู่ อาจจะต่างกันทั้งหมด GQty ไม่สามารถขับเคลื่อนมันได้

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

Next.js เป็นเฟรมเวิร์กส่วนหน้า ดังนั้นการกำหนดเส้นทางทั้งหมดจึงอิงตาม ซึ่งเป็นกระบวนทัศน์ที่แตกต่างอย่างสิ้นเชิงสำหรับวิธีการกำหนดเส้นทาง สิ่งที่อาจเป็นได้ /Blog on Next อาจไม่เกี่ยวข้องกับเนื้อหาสำหรับบล็อก ไปที่ชุดของเทมเพลต มันจะเป็นส่วนหนึ่งของแอปพลิเคชันที่สามารถสร้างบล็อกได้

ในขณะที่ /Blog บน WordPress อาจหมายถึงสิ่งเหล่านี้คือบล็อกโพสต์ทั้งหมด และกระบวนทัศน์นั้นเมื่อสร้าง หากคุณต้องการให้ WordPress เป็นส่วนหน้าที่แข็งแกร่งมากหรือ CMS ที่ไม่มีส่วนหัว เราต้องจัดการกับการกำหนดเส้นทางนั้น การเปลี่ยนแปลงอีกครั้งเมื่อเราทำสิ่งนี้ เช่นที่ฉันพูดในเวอร์ชัน GQty เป้าหมายของเราคือนักพัฒนา JavaScript ที่ต้องใช้ WordPress ซึ่งดูเหมือนจะสูงส่งจนกว่าคุณจะรู้ว่านี่คือ WP Engine

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

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

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

DP : ใช่ อย่างแน่นอน. คุณรู้ไหม ฉันคิดว่าเป็นจุดที่ดีที่จะพักผ่อนอย่างรวดเร็วที่นี่ คุณกำลังฟัง Press This ซึ่งเป็นพอดคาสต์ชุมชน WordPress ที่มี Chris Weigman และ Jason Bahl เราจะกลับมาพูดถึง WordPress และหัวขาด คอยติดตาม.

DP: เรากลับมาพร้อมกับ Press This และคุณรู้ไหม คริส ก่อนที่คุณจะพูดถึงบางอย่าง คุณพูดถึงบริษัทจำนวนมากขึ้นเรื่อยๆ ที่เข้าสู่โหมดไร้สมอง และฉันรู้ว่า WP Engine ได้ทำการวิจัยมากมายเกี่ยวกับการแสดงที่เป็นกรณีนี้ ฉันค่อนข้างสงสัย หัวขาดมีชื่อเสียงเป็นบางอย่าง ฉันคิดว่าองค์กร เมื่อฉันคิดว่าหัวขาด ฉันคิดถูกต้อง นั่นคือสิ่งที่หัวขาดคืออะไร? เป็นเพียงเครื่องมือสำหรับองค์กรหรือเป็นเครื่องมือที่ไซต์ต่างๆ จะใช้มากขึ้น

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

นี่ไม่ใช่คนที่ใช้ WordPress นอกกรอบ แต่คุณต้องการบล็อกส่วนตัวของคุณ มันสามารถทำเช่นนั้นได้ แต่จนถึงตอนนี้มันเป็นลิฟต์ที่หนักกว่ามากเพื่อที่จะสามารถทำเช่นนั้นได้ เช่นเดียวกับ Contentful เช่นเดียวกับ CMS อื่น ๆ เหล่านี้ทั้งหมด ถ้าคุณแค่ต้องการอะไรที่เรียบง่าย สิ่งที่คุณรู้ ประเภทของเนื้อหาที่อยู่ในเว็บมานานหลายปี ส่วนหัวอาจเป็นงานมากกว่าที่คุณต้องการจัดการจนถึงตอนนี้

เป็นองค์กรที่เคร่งครัดหรือไม่? ดูไม่ แกสบี้แก้ปัญหานี้มาหลายปีแล้ว คุณมีพอดแคสต์อีกรายการในภายหลัง Doc with Mastodon เป็นชุมชนที่ฉันมีส่วนร่วมด้วยเป็นเวลาหลายปี คนส่วนใหญ่ที่ใช้รูปแบบต่างๆ ของ Headless CMS โดยเฉพาะ Gatsby แต่ก็มี Hugo เทคโนโลยีประเภทนั้นแตกต่างกันทุกประเภทในระดับรากหญ้า

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

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

และเฟาสท์ทำให้การใช้สิ่งนั้นง่ายขึ้นมาก และบางอย่างที่คุณสามารถสร้างได้ในหนึ่งวันแทนที่จะเป็นหนึ่งเดือน

DP: เจสัน คริสพูดถึงบางอย่างที่ฉันอยากฟังความคิดเห็นของคุณ ฉันได้ยินมาว่านี่อาจไม่ดีสำหรับทีมเล็กๆ บล็อกเกอร์เล็กๆ อย่างฉัน ซึ่งก็สมเหตุสมผลดี ฉันไม่ต้องการ WordPress แบบไร้หัวคิด แต่ชอบ ฉันเดาว่าสิ่งที่ฉันสงสัยคือ WordPress แบบไม่มีหัวจะทำให้ฉันเสียค่าใช้จ่ายมากขึ้นเพราะฉันจะต้องมี iOS dev และ WordPress dev หรือไม่ มีราคาแพงกว่าหรือคุ้มค่ากว่าหรือไม่?

JB: น่าจะขึ้นอยู่กับสิ่งที่คุณผลิต ฉันเดา หากคุณกำลังทำอย่างที่คุณพูดถึง iOS หากคุณกำลังทำแอปมือถือแบบเนทีฟ ฉันหมายความว่ามีค่าใช้จ่ายที่เกี่ยวข้องกับสิ่งนั้นอย่างชัดเจน และไม่มีวิธีที่ดีที่จะทำหากคุณใช้ข้อมูลจาก WordPress หรืออื่นๆ กว่าการทำแบบไร้หัว เพราะคุณรู้ว่าแอพแบบเนทีฟไม่เรนเดอร์ php ดังนั้นคุณจะต้องทำแบบไร้หัว

แต่ถ้าตอนนี้คุณกำลังสร้างเว็บด้วย WordPress แบบดั้งเดิม คุณสามารถไปหาธีม รู้จักธีมฟรีหรือหาธีมในตลาด ดาวน์โหลด ติดตั้ง แล้วคุณก็ ออกไปแข่ง. คนส่วนใหญ่กำลังจะปรับแต่งไม่ทางใดก็ทางหนึ่ง

โดยปกติแล้วคุณจะต้องมีค่าใช้จ่ายสำหรับนักพัฒนาซอฟต์แวร์ ไม่ว่าจะเป็นตัวคุณเองหรือคนอื่น สิ่งหนึ่งที่ WordPress ไม่มีหัวซึ่งแตกต่างจากธีม PHP แบบดั้งเดิม ตัวอย่างเช่น เมื่อฉันเปิดตัว wpgraphql.com ใหม่ ฉันสามารถใช้อินสแตนซ์เดียวกันกับ WordPress ที่ขับเคลื่อนไซต์ Gatsby ของฉันได้

ฉันได้รับข้อมูล ข้อมูลกำลังออกมาและเข้าสู่ไซต์ Gatsby ฉันสามารถเผยแพร่เนื้อหาต่อไปใน CMS ในขณะที่พัฒนาส่วนหน้าถัดไปของฉันในเวลาเดียวกัน ในการพัฒนา WordPress แบบดั้งเดิม โดยปกติแล้วคุณจะต้องย้ายไซต์ของคุณไปยังสภาพแวดล้อมแบบจัดเตรียม

เปิดใช้งานธีมใหม่บนสภาพแวดล้อมนั้น สร้างธีมของคุณที่นั่น จัดการกับช่วงหยุดเนื้อหาบางประเภท เช่น ที่คุณบอกผู้สร้างเนื้อหาของคุณว่า “เฮ้ วันนี้คุณไม่สามารถเผยแพร่เนื้อหาได้ เพราะเราจะย้ายข้อมูล แล้วเราจะ กำลังจะตั้งค่าอินสแตนซ์ WordPress ใหม่ อินสแตนซ์สด” จากนั้นคุณต้องเข้าสู่ระบบที่นั่นและเริ่มทำเนื้อหาของคุณให้ถูกต้อง

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

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

อีกสิ่งที่น่าสนใจเช่นกันคือระบบนิเวศของ JavaScript นั้นมีการจัดส่งจริง ๆ ในความคิดของฉัน แรงผลักดันทั่วไปหนึ่งในตัวกระตุ้นทั่วไปสำหรับการย้ายหัวขาดคือสถาปัตยกรรมที่ใช้ส่วนประกอบ และมีไลบรารีคอมโพเนนต์ทุกประเภทในระบบนิเวศ React และ VUE ซึ่งอนุญาตให้คุณนำส่วนประกอบกลับมาใช้ใหม่ในโครงการต่างๆ

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

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

และฉันคิดว่าในอนาคตอันใกล้นี้ การสร้างหัวขาดอาจจะถูกกว่าการสร้างหัวขาด

DP: คริส คุณมีอะไรอยากจะเพิ่มให้กับเอเจนซี่ที่อาจต้องคิดเกี่ยวกับค่าใช้จ่ายของ WordPress แบบไม่มีหัวไหม?

CW: ฉันคิดว่าเจสันโดนตะปูเข้าที่หัวจริงๆ

และนั่นคือสิ่งหนึ่งที่ฉันชอบเกี่ยวกับ WPGraphQL คือทีมของฉันกำลังทำงานต่อไปเพื่อขยาย WordPress ไปในทิศทางนั้นด้วยสิ่งที่เราเรียกว่า ชื่อการทำงานของเราคือ React Gutenberg Bridge แต่ก็เป็นปัญหาใน WordPress เช่นกัน คุณจะใช้ส่วนประกอบเหล่านี้ซ้ำได้อย่างไร? ฉันไม่อยากใช้คำว่าแค่ส่วนประกอบเพราะมันไม่ได้ใช้กับฝั่ง WordPress ในลักษณะเดียวกับที่ใช้กับฝั่ง JavaScript ใช่ไหม

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

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

DP: ใช่อย่างแน่นอน คุณรู้ไหมว่ามาจากพื้นเพด้านหนังสือพิมพ์ ทำงานให้กับ Weeklys in the Twin Cities และในแนชวิลล์ เจสัน ฉันนึกออกว่าจะเป็นอย่างไรถ้าบอกหนังสือพิมพ์ 56 ฉบับของคุณไม่ให้ตีพิมพ์เป็นเวลาหนึ่งวัน

ไม่มีข่าวสารในวันนี้ เนื่องจากเรากำลังปรับปรุงเว็บไซต์

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

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

DP: ใช่ และฉันคิดว่ายังมีอีกมาก เมื่อคุณยังคงใช้ WordPress อยู่ คุณยังคงได้รับระบบนิเวศที่ช่วยให้คุณประหยัดค่าใช้จ่ายได้ คุณไม่จำเป็นต้องสร้างเครื่องมือ SEO

คุณสามารถใช้ปลั๊กอิน Yoast SEO หรืออะไรก็ได้ แม้ว่าคุณจะเป็นไซต์ที่ไม่มีส่วนหัว แต่ฉันเดาว่าปลั๊กอินส่วนใหญ่จะยังคงใช้งานได้ตราบเท่าที่ไม่ได้หันหน้าเข้าหากัน

เจบี: อือ นั่นเป็นสิ่งที่น่าสนใจจริงๆ ดังนั้น Faust ใหม่จึงถูกสร้างขึ้นด้วยสถาปัตยกรรมปลั๊กอินเอง เหมือนแกะกล่องเลย มันจะมาพร้อมกับไคลเอ็นต์ ใช้ไคลเอ็นต์ Apollo เพื่อให้คุณสามารถดึงข้อมูลจาก WPGraphQL ได้ คุณจะได้รับข้อมูล WordPress แต่คุณสามารถสร้างปลั๊กอินได้ สมมติว่าคุณทำเช่นเดียวกับคุณ กล่าวถึง ติดตั้ง Yoast SEO บนไซต์ WordPress ของคุณ

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

เป็นสิ่งที่ฉันไม่คิดว่าจะมีฟรอนท์เอนด์หัวขาดตัวอื่นที่มีแนวคิดแบบเดียวกับที่เฟาสท์กำลังเข้าใกล้ ก็เลยคิดว่า Plugin ก็เป็นอีกตัวที่นักพัฒนา WordPress คุ้นเคยกันดี มันนำแนวคิดที่คุ้นเคยจาก WordPress แต่เชื่อมโยงกับส่วนหน้าของ JavaScript ที่ทันสมัย

DP: นั่นเป็นจุดที่ดีสำหรับช่วงพักสุดท้ายที่ Press This และเมื่อเรากลับมา เราจะปิดการสนทนากับ Chris Weigman และ Jason Bahl คอยติดตาม.

DP: คุณกำลังฟัง Press This ซึ่งเป็นพอดคาสต์ชุมชน WordPress ฉันเป็นเจ้าภาพของคุณ Doc Pop วันนี้เรากำลังพูดถึง WPGraphQL, Faust และวิธีเพิ่มประสิทธิภาพไซต์ WordPress ของคุณ ก่อนพัก เรากำลังพูดถึงเฟาสต์และปลั๊กอิน และฉันจะถามคำถามแบบสุ่มๆ กับคุณ และดูว่ามีคำตอบดีๆ ไหม

แต่คริส ฉันค่อนข้างสงสัยว่า Faust มีศักยภาพอะไรไหม ฉันรู้ว่ามันเป็นแพลตฟอร์มที่ไม่มีหัวสมอง แต่มีความเป็นไปได้ไหมที่จะเหมือนกับธีม WordPress Faust ที่อย่างน้อยก็ทำให้คุณตั้งค่าได้ นี่คือปลั๊กอินที่คุณต้องการและนี่คือทุกอย่างที่แกะกล่อง

CW: แน่นอน ที่จริงเรามีอยู่แล้ว เราเรียกมันว่าพิมพ์เขียวเพราะมันทำงานอย่างหนักกับ Local คนส่วนใหญ่จะปรับแต่งสิ่งนี้ก่อนที่จะเปิดตัวบนแพลตฟอร์มเช่น WP Engine ดังนั้นเราจึงยืมชื่อของพิมพ์เขียวในท้องถิ่น

สำหรับ Faust ใหม่ เรามีหนึ่งชื่อ Portfolio ซึ่งโดยพื้นฐานแล้วเป็นธีมพอร์ตโฟลิโอเต็มรูปแบบ และเรากำลังทำงานบนโครงร่างที่ว่างเปล่าที่เอเจนซีสามารถใช้ได้ เมื่อคุณเริ่มเข้าใจแล้ว คุณอาจต้องปรับแต่งทุกอย่างด้วยตัวเอง โครงร่างจะเป็นแนวปฏิบัติที่ดีที่สุดของโปรเจกต์ หมุนมันขึ้นมา จากนั้นคุณก็สามารถทำสิ่งต่างๆ ของคุณเองได้

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

DP: ใช่ มันเจ๋งมากที่จะคิด นั่นเป็นระบบนิเวศที่แตกต่างไปจากเดิมอย่างสิ้นเชิง

และคุณรู้ไหม Jason ฉันเคยสัมภาษณ์คุณมาก่อน และฉันแน่ใจว่าคำถามนี้มักจะเกิดขึ้นตลอดเวลา แต่ทุกครั้งที่ฉันได้ยินเกี่ยวกับ WPGraphQL ฉันคิดว่ามันฟังดูเหมือน REST API มาก จริง ๆ แล้วฟังดูมีพลังมากกว่าที่ REST API ทำ และ REST API เป็นส่วนหนึ่งของคอร์ และฉันแค่สงสัย คุณรู้สึกว่า WPGraphQL ควรเป็นส่วนหนึ่งของ WordPress Core หรือไม่

JB: อาจจะสักวันหนึ่ง ฉันไม่คิดว่าเรายังไปที่นั่น เมื่อสิ่งต่าง ๆ ถูกรวมเข้ากับ WordPress Core อาจยกเว้น Gutenberg นวัตกรรมจะหยุดลง ตัวอย่างเช่น REST API ยังคงมีข้อผิดพลาดที่ฉันชี้ให้เห็นผู้คนที่ยังคงมีอยู่ตั้งแต่ฉันคิดว่าปี 2016 ดังนั้นฉันหมายความว่า เมื่อสิ่งต่างๆ เข้าสู่แกนหลัก คุณกำลังเพิ่มคุณลักษณะที่กำหนดเป็น 40 เปอร์เซ็นต์ของเว็บและ ดังนั้นการเปลี่ยนแปลงจึงต้องทำช้าลงมาก ซึ่งถ้าเป็นปลั๊กอิน คุณสามารถให้ผู้ใช้เลือกใช้เวอร์ชันที่พวกเขาต้องการเลือกใช้ และคุณสามารถทำซ้ำได้เร็วกว่ามาก เพราะพวกเขาสามารถเลือกเวอร์ชันที่ดีที่สุดสำหรับโครงการของตนได้

ในส่วนแกนหลัก หากคุณอัปเดตคอร์และมีการเปลี่ยนแปลงที่ทำลาย คุณอาจทำเว็บล่มไป 40 เปอร์เซ็นต์ ดังนั้น GraphQL จึงเป็นข้อกำหนด จึงไม่มีส่วนเกี่ยวข้องกับ WordPress เช่นกัน

ถูกต้อง. ดังนั้นข้อกำหนด GraphQL จึงยังคงพัฒนาอยู่ และในขณะที่มีการพัฒนาอย่างต่อเนื่อง เราจึงต้องการติดตามข้อมูลจำเพาะ GraphQL ล่าสุดและยิ่งใหญ่ที่สุด ถ้าเราจะรวม WPGraphQL เข้ากับ Core ในวันนี้ และ GraphQL พัฒนาขึ้นเรื่อยๆ WordPress จะติดอยู่ที่ GraphQL รุ่นปี 2022 โดยที่ส่วนอื่นๆ ของโลกอยู่ในรุ่นปี 2030 หรืออะไรก็ตาม สำหรับฉัน ฉันคิดว่ามันอาจจะสมเหตุสมผลในบางจุดที่จะได้รับการยอมรับว่า WPCLI เป็นเหมือนวิธีอย่างเป็นทางการในการทำสิ่ง X

เช่นเดียวกับที่คุณสามารถสร้างไคลเอนต์ CLI ของคุณเองสำหรับ WordPress ได้ แต่ชุมชนได้รับการยอมรับว่า WPCLI เป็นทางการ ไม่ใช่ส่วนหนึ่งของ WordPress Core แต่ได้รับการยอมรับจาก WordPress Foundation และชุมชน WordPress ส่วนใหญ่ว่าเป็นสิ่งที่เป็นทางการ ดังนั้นมันอาจจะดีในบางครั้งที่ WPGraphQL ได้รับการยอมรับเช่นนั้น เช่น ถ้าคุณจะทำ WordPress แบบไม่มีหัว ให้ทำอย่างนี้

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

ดังนั้นการทำเป็นปลั๊กอินสำหรับฉันจึงสมเหตุสมผล

DP: ได้เลย และใช่ คุณได้พูดถึง WPCLI และฉันก็ลืมไปเรื่อย ๆ เหมือนพวกเขาเพิ่งรู้สึกว่ามันเป็นส่วนหนึ่งของแกนหลัก อะไรก็ตามที่มันให้ความรู้สึกเหมือนเป็นทางการ ใช่ มันเหมือนกับ โอ้ ใช่ มันเหมือนกับสิ่งที่เป็นอิสระ เหมือนกับที่ WPGraphQL เป็นอยู่ในขณะนี้

นั่นเป็นการเปรียบเทียบที่ดี ฉันจะไป ฉันจะจบที่นี่ มันเป็นการสนทนาที่ยอดเยี่ยมจริงๆ กับคุณทั้งสองคน หากผู้ฟังสนใจติดตามคุณ คุณสามารถติดตาม @JasonBahl และ @ChrisWeigman เราจะใส่แฮนเดิล Twitter ในคำอธิบายรายการหากทำได้ คุณได้รับฟัง Press This ซึ่งเป็นพอดคาสต์ชุมชน WordPress บน WMR

ในตอนของสัปดาห์หน้า เราจะให้แอนน์ แมคคาร์ธี ผู้ประสานงานผลิตภัณฑ์ที่ Automatic พูดคุยเกี่ยวกับการเปลี่ยนแปลงในการแก้ไขไซต์และ 6.1 และสิ่งที่จะเกิดขึ้นกับ 6.2 ขอขอบคุณอีกครั้งสำหรับการฟัง Press This

คุณสามารถติดตามการผจญภัยของฉันกับนิตยสาร Torque ได้บน Twitter @thetorquemag หรือคุณสามารถไปที่ Torquemag.io ซึ่งเรานำเสนอบทแนะนำและวิดีโอและบทสัมภาษณ์เช่นนี้ทุกวัน ลองดูที่ Torquemag.io หรือติดตามเราทาง Twitter คุณสามารถสมัครสมาชิก Press This ได้ที่ Red Circle, iTunes, Spotify หรือดาวน์โหลดได้โดยตรงที่ wmr.fm ในแต่ละสัปดาห์ ฉันเป็นโฮสต์ Doctor Popular ของคุณ ฉันสนับสนุนชุมชน WordPress ผ่านบทบาทของฉันที่ WP Engine และฉันชอบที่จะเน้นสมาชิกของชุมชนทุกสัปดาห์ใน Press This