CMS หัวขาด: Gatsby JS พร้อม WordPress

ความรู้ทั่วไปที่ WordPress ครอบคลุมประมาณหนึ่งในสามของเว็บไซต์ 1 ล้านอันดับแรกของโลกโดยมีส่วนแบ่งการตลาดมากกว่า 50% ในระบบการจัดการเนื้อหา เมื่อเร็ว ๆ นี้ในปี 2559 WordPress ได้ตัดสินใจที่จะแนะนำ REST API เพื่อให้แอปพลิเคชั่นอื่น ๆ เข้าถึงเนื้อหาในฐานข้อมูล WordPress ได้ดีขึ้น ส่งผลให้นักพัฒนาสามารถใช้ประโยชน์จาก WordPress เป็น CMS ที่ไม่มีหัวได้

สิ่งนี้บอกเป็นนัยอย่างหลีกเลี่ยงไม่ได้ว่าวิศวกรจะไม่ถูกจำกัดให้ใช้เลเยอร์การนำเสนอแบบธรรมดาของ WordPress (ส่วนหน้า) อีกต่อไป แต่ตอนนี้สามารถใช้ประโยชน์จากแอพพลิเคชั่นส่วนหน้าเพื่อส่งข้อมูลของพวกเขาได้ ด้วยเหตุนี้ บล็อกส่วนใหญ่จะสำรวจความสัมพันธ์ของ WordPress และ Gatsby.js เกี่ยวกับผลกระทบของ Headless CMS

ประวัติโดยย่อของ CMS

เมื่อเราย้อนกลับไปเพื่อทำความเข้าใจการปฏิวัติ Headless CMS ฉันคิดว่าการสรุปประวัติของระบบการจัดการเนื้อหา (CMS) เป็นเรื่องสำคัญ ตามเนื้อผ้า ในช่วงต้นทศวรรษ 90 เว็บเพจแบบสแตติกเป็นวิธีหลักในการดำเนินการเว็บไซต์ที่เว็บมาสเตอร์จะแก้ไขไฟล์ HTML โดยตรงและอัปโหลดไปยังเซิร์ฟเวอร์ผ่าน FTP ในที่สุด ในช่วงกลางทศวรรษที่ 1990 เทคโนโลยีเว็บเริ่มมีวิวัฒนาการและเนื้อหามีไดนามิกมากขึ้น นำไปสู่การเกิดขึ้นของระบบการจัดการเนื้อหาแบบเสาหินระบบแรก

โดยพื้นฐานแล้ว Monolithic CMS คือแอปพลิเคชันซอฟต์แวร์ที่รวมทุกอย่างที่จำเป็นในการแก้ไขและเผยแพร่เนื้อหาบนเว็บ ระบบแรกดังกล่าวจำกัดไว้สำหรับองค์กรเช่น EpiServer อย่างไรก็ตาม รูปแบบโอเพ่นซอร์สในภายหลังก็ปรากฏขึ้นเช่น WordPress, Drupal และ Joomla ที่เหลือคือประวัติศาสตร์เนื่องจาก WordPress ได้รับส่วนแบ่งการตลาดมากที่สุดเมื่อเวลาผ่านไป

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

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

CMS หัวขาด

ดังที่ได้กล่าวไว้ก่อนหน้านี้ Headless CMS คือหนึ่งที่ไม่มีเลเยอร์การนำเสนอ ด้วยเหตุนี้ เนื้อหาจึงถูกส่งผ่าน API (RESTful หรือ GraphQL) เพื่อแยกแอปพลิเคชันส่วนหน้าซึ่งแสดงออกมา API ทำให้เนื้อหาพร้อมใช้งานสำหรับช่องทางและอุปกรณ์ใดๆ โดยใช้เครื่องมือและภาษาโปรแกรมที่หลากหลาย โดยมีระดับความปลอดภัยและความสามารถในการปรับขนาดที่สูงขึ้น

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

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

การดำเนินการ CMS หัวขาดของ WordPress

ในแง่ของลำดับเหตุการณ์ที่แชร์ไว้ข้างต้น เราได้เห็นแล้วว่า WordPress มีผลกับ CMS ที่ไม่มีส่วนหัวอย่างไร WordPress ประกอบด้วย API (Application Programming Interface) ซึ่งช่วยให้คุณสามารถขยายได้ด้วยปลั๊กอิน (โดยพื้นฐานแล้วเป็น 'กรอบงานแอปพลิเคชัน') โดยเฉพาะอย่างยิ่ง สิ่งนี้ทำได้ผ่าน REST API อย่างที่เราจะต้องทำในภายหลัง

อย่างไรก็ตาม แนวคิดหลักประการหนึ่งของ WordPress API คือ hooks โดยทั่วไป hooks อนุญาตให้ปลั๊กอินเปลี่ยนฟังก์ชันหลักของ WordPress ในทางปฏิบัติ Hooks ทำงานในลักษณะที่เมื่อมีเหตุการณ์บางอย่างใน WordPress เกิดขึ้น (เช่น การโหลดหน้า หรือหลังการแก้ไข) WordPress จะเรียก hook บางอย่างเพื่อเรียกใช้ฟังก์ชัน

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

WordPress และ REST API

การถ่ายโอนสถานะตัวแทน (REST) ​​ขึ้นอยู่กับโปรโตคอล HTTP และให้ความหมายของอินเทอร์เฟซที่เหมือนกันเพื่อสร้าง อ่าน อัปเดต และลบข้อมูล (CRUD)

โดยทั่วไป การดำเนินการ REST API ใน WordPress ช่วยให้นักพัฒนาสามารถเข้าถึงข้อมูลในฐานข้อมูล WordPress จากระยะไกลโดยการส่งและรับวัตถุ JSON (JavaScript Object Notation) ด้วยเหตุนี้ นักพัฒนาจึงมีโอกาสสร้าง อ่าน อัปเดต และลบข้อมูล WordPress จากแอปพลิเคชันอื่นๆ ที่ไม่ได้ออกแบบด้วย WordPress ตัวอย่างเช่น JavaScript Web Applications หรือแอพมือถือดั้งเดิม

อย่างไรก็ตาม เมื่อเราเข้าใจลึกซึ้งยิ่งขึ้นเกี่ยวกับความสัมพันธ์ของ Headless WordPress CMS กับ REST API และ Gatsby เราจำเป็นต้องสังเกตแนวคิดพื้นฐานบางประการของ WordPress API:

• เส้นทางและปลายทาง: เส้นทางคือเส้นทางที่คุณสามารถเข้าถึงได้ผ่านการเรียก HTTP ในขณะที่ปลายทางเป็นวิธี HTTP (เช่น รับ โพสต์ วาง หรือลบ) ที่แมปกับเส้นทางนั้น
• คำขอ: เมื่อคุณเริ่มต้นคำขอ HTTP ไปยังเส้นทาง REST ที่ลงทะเบียน WordPress จะสร้างวัตถุคำขอโดยอัตโนมัติ ข้อมูลที่ระบุในคำขอจะเป็นตัวกำหนดคำตอบที่คุณจะได้รับ
• ตอบกลับ: วัตถุตอบกลับคือข้อมูลที่คุณได้รับกลับเมื่อคุณส่งคำขอ อาจประกอบด้วยข้อมูลที่ร้องขอหรือข้อความแสดงข้อผิดพลาด
• สคีมา : สคีมาหมายถึงโครงสร้างข้อมูลในจุดสิ้นสุด จุดสิ้นสุดแต่ละจุดสามารถมีโครงสร้างข้อมูลที่แตกต่างกันเล็กน้อยหรืออย่างมีนัยสำคัญที่ส่งกลับได้ ดังนั้น สคีมาจะกำหนดคุณสมบัติที่เป็นไปได้ทั้งหมดที่จุดปลายสามารถส่งคืนได้ และพารามิเตอร์ที่เป็นไปได้ทั้งหมดที่จะได้รับ
• Controller Classes: Controller Classes ช่วยให้นักพัฒนาสามารถจัดการและลงทะเบียนปลายทางและเส้นทาง ในขณะที่ยังช่วยให้จัดการคำขอ ใช้สคีมา และสร้างการตอบสนอง

ปฏิกิริยา 'กรอบ'

เมื่อเราพูดถึงความสัมพันธ์ของ Gatsby.js และ WordPress สำหรับบริบทที่มากขึ้น เราต้องถอดรหัสภูมิทัศน์ทางเทคโนโลยีนี้จากพื้นฐานทางประวัติศาสตร์ที่มากขึ้น React เป็นหัวใจสำคัญของเรื่องนี้ เนื่องจากเป็นไลบรารี/เฟรมเวิร์กส่วนหน้าของ JavaScript ที่เติบโตเร็วที่สุด สร้างชื่อเสียงโดย Facebook (นักพัฒนาหลัก) เว็บไซต์ขนาดใหญ่อื่น ๆ ใช้ React สำหรับส่วนหน้าเช่น: Airbnb, Netflix, Dropbox, BBC, PayPal, Reddit, Salesforce, Squarespace และ Tesla

ดังนั้น เนื่องจาก React เป็นไลบรารี่ในทางปฏิบัติ (เนื่องจากยังขาดคุณสมบัติเด่นของเฟรมเวิร์กที่เต็มเปี่ยม) นี่หมายความว่า 'เฟรมเวิร์ก' อื่นๆ สามารถออกแบบเพิ่มเติมได้ ดังนั้น หนึ่งในนั้นคือ Gatsby.js

แนะนำแกสบี้

ตามเว็บไซต์หลัก Gatsby.js เป็นเฟรมเวิร์ก JavaScript แบบโอเพ่นซอร์สฟรีที่ใช้ React ซึ่งช่วยให้นักพัฒนาสร้างเว็บไซต์และแอปที่รวดเร็ว โดยหลักการแล้ว Gatsby.js จะสร้างหน้า HTML แบบคงที่จากแอปพลิเคชันสำหรับการโหลดเริ่มต้น จากนั้นจึงดำเนินการเป็นแอปพลิเคชัน React แบบหน้าเดียว (SPA)

Gatsby.js คุณสมบัติ

ภายใต้สถานการณ์ดังกล่าว Gatsby ใช้ประโยชน์จากหลักการ Progressive Web App (PWA) เพื่อดึงเฉพาะองค์ประกอบที่จำเป็นก่อน แล้วจึงโหลดส่วนที่เหลือของแอปพลิเคชันในพื้นหลังในภายหลัง นอกจากนี้ เพื่อให้แน่ใจว่ามีการโหลดเฉพาะข้อมูลที่จำเป็น Gatsby ใช้ประโยชน์จากภาษาการสืบค้น GraphQL (เช่น Facebook) เพื่อโหลดข้อมูลจากแหล่งที่มา มันยังรักษาการเพิ่มประสิทธิภาพภาพที่ยอดเยี่ยมอีกด้วย

ความสามารถทั้งหมดเหล่านี้รวมกันทำให้นักพัฒนามีเครื่องมือที่จำเป็นในการสร้างเว็บไซต์และเว็บแอปที่เร็วที่สุดเท่าที่จะเป็นไปได้ เนื่องจากจะโหลดเฉพาะ HTML, CSS, ข้อมูล และ JavaScript ที่สำคัญเท่านั้น ดังนั้น เมื่อโหลดหน้าเว็บแล้ว Gatsby จะดึงทรัพยากรล่วงหน้าสำหรับหน้าที่เชื่อมโยง และการนำทางไซต์จึงรู้สึกค่อนข้างเร็ว

นอกจากนี้ เนื่องจากหน้าต่างๆ ถูกสร้างขึ้นในการคอมไพล์ ก่อนการวางออนไลน์ คุณไม่จำเป็นต้องมีเซิร์ฟเวอร์ PHP ที่มีประสิทธิภาพอีกต่อไป และสามารถให้บริการไฟล์แบบคงที่ (HTML, JS และ CSS ได้โดยตรงจากที่เก็บข้อมูลบัคเก็ต) นอกจากนี้ เนื่องจาก Gatsby นั้นขับเคลื่อนโดย React คุณจะสามารถจัดโครงสร้างทุกอย่างด้วยส่วนประกอบได้อย่างสวยงาม ลักษณะโมดูลาร์นี้ช่วยให้นักพัฒนาสามารถนำส่วนประกอบกลับมาใช้ใหม่ได้อย่างง่ายดาย

คุณสมบัติที่สำคัญอื่น ๆ ของ Gatsby ได้แก่:

• เครื่องกำเนิดไซต์คงที่
• การเข้าถึงแบบออฟไลน์
• กำลังดึงหน้าที่เชื่อมโยงล่วงหน้า
• การแคชหน้า
• ไม่มีการเรียกรหัสภายนอก
• ส่งออกเป็นรหัส
• เนื้อหาโหลดซ้ำสุดฮอต
• รหัสโหลดร้อน
• การจัดองค์ประกอบ
• การผูกข้อมูลทางเดียว
• การสืบค้นข้อมูล API แบบประกาศ (GraphQL)
• ประกาศ UI
• การโหลดภาพแบบโปรเกรสซีฟ
• กำลังโหลดรูปภาพที่ตอบสนอง
• การวางแนวของ CSS ที่สำคัญ
• แบบอักษร self-hosting
• ไร้เซิร์ฟเวอร์
• ท่อส่งสินทรัพย์
• ส่วนขยาย CSS (SaSS)
• ไวยากรณ์ JavaScript ขั้นสูง
• ระบบนิเวศองค์ประกอบตอบสนอง

ปลั๊กอิน Gatsby

โดยพื้นฐานแล้ว ปลั๊กอิน Gatsby เป็นแพ็คเกจ Node.js โดยพื้นฐานที่ใช้ Gatsby API ปลั๊กอินเหล่านี้สามารถเพิ่มแหล่งข้อมูล แปลงข้อมูลเป็นรูปแบบอื่น และเพิ่มบริการของบุคคลที่สาม แม้ว่า Gatsby.org จะรักษาไลบรารีปลั๊กอินที่มีปลั๊กอินที่สร้างไว้แล้วจำนวนมากที่สร้างโดยทีมหลักของ Gatsby หรือบุคคลที่สาม ตามหลักการแล้ว ในการติดตั้งปลั๊กอินสำหรับโปรเจ็กต์ Gatsby นักพัฒนาจะใช้ node package manager (NPM) บนเทอร์มินัล UNIX และรันคำสั่ง npm install

GraphQL มาเกี่ยวข้องกับ Gatsby อย่างไร

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

การใช้งานที่ไม่เหมือนใครนี้ช่วยให้นักพัฒนาสามารถเชื่อมต่อแหล่งข้อมูลใดๆ กับ Gatsby ได้ ตัวอย่างเช่น บล็อกโพสต์อาจมาจากไฟล์ Markdown, Google ชีต หรือแม้แต่เว็บไซต์ WordPress อื่น ดังนั้นให้ความยืดหยุ่นที่เพิ่มขึ้นกับการจัดส่งเนื้อหา

กลไก Gatsby-WordPress (ปลั๊กอินที่มา)

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

Gatsby รองรับตัวเลือก CMS แบบไม่มีหัวในความกว้างเดียวกัน ทีมงานด้านวิศวกรรมและเนื้อหาจะได้รับความสะดวกสบายและความคุ้นเคยของอินเทอร์เฟซผู้ดูแลระบบที่ต้องการ พร้อมประสบการณ์นักพัฒนาที่ได้รับการปรับปรุงและประโยชน์ด้านประสิทธิภาพของการใช้ Gatsby, GraphQL และ React เพื่อสร้าง ส่วนหน้า

ปลั๊กอิน 'Gatsby-source-WordPress' สร้างและดูแลโดยทีมงานหลักของ Gatsby และดึงข้อมูลจากเว็บไซต์ WordPress ที่โฮสต์เองหรือ WordPress.com นอกจากนี้ยังให้การรับรองความถูกต้อง OAuth กับ Word-Press.com API และยังช่วยให้นักพัฒนาสามารถสืบค้นรูปภาพที่ตอบสนองได้

โดยพื้นฐานแล้ว ปลั๊กอินนี้สนับสนุนเอนทิตีทั้งหมดบน WordPress REST API เช่น โพสต์ หน้า แท็ก หมวดหมู่ สื่อ ประเภท ผู้ใช้ สถานะ อนุกรมวิธาน ข้อมูลเมตาของไซต์ และประเภทโพสต์ที่กำหนดเอง นอกจากนี้ยังรองรับเอนทิตี Advanced Custom Fields (ACF) และข้อมูลภาษา Polylang และ WPML นอกเหนือจากเมตาโพสต์อื่นๆ ที่ลงทะเบียนกับ REST API

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

ในทางปฏิบัติ เครื่องมือ 'Gatsby-source-WordPress' มีกระสุนสำหรับโพสต์และเอนทิตีอื่นๆ ทั้งหมด ดังนั้น วิศวกรทั้งหมดที่ต้องทำคือสร้างฟังก์ชัน 'createPage' ที่เรียกเพจ การดำเนินการนี้จะดำเนินการในไฟล์ Gatsby-node.js โดยปกติแล้วจะเรียกใช้แบบสอบถามสำหรับแหล่งข้อมูลก่อน จากนั้นจึงเรียก 'createPage' สำหรับแต่ละโหนดที่พบ จากนั้นตั้งค่าไฟล์เทมเพลตเพื่อใช้เป็นส่วนประกอบ

CI/CD และ Application Release Automation

เมื่อใช้งาน WordPress CMS แบบไม่มีส่วนหัวกับ Gatsby วิธีการปรับใช้นั้นมีความสำคัญอย่างยิ่ง โดยทั่วไป การดำเนินการดังกล่าวต้องการการปรับใช้แอปพลิเคชันเพื่อให้ใช้ Application Release Automation (ARA) โดยอัตโนมัติ

โดยทั่วไป ARA มีหน้าที่หลัก:

• การปรับใช้ข้อมูล รหัสแอปพลิเคชัน และสิ่งประดิษฐ์
• การปรับใช้การกำหนดค่าเฉพาะสำหรับแต่ละสภาพแวดล้อม
• การออกแบบเวิร์กโฟลว์กระบวนการสำหรับงานอัตโนมัติและขั้นตอนการปรับใช้
• สุดท้าย การสร้างแบบจำลองสภาพแวดล้อมและ/หรือไบนารีการจัดเตรียม

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

การสืบค้นจาก WordPress โดยใช้ GraphQL และ gatsby-source-WordPress

ตามภาพประกอบ gatsby-source-WordPress ทำงานในลักษณะที่จะดึงข้อมูลทุกอย่างบนปลายทางของคุณโดยใช้ REST ก่อน จากนั้นจะสร้าง GraphQl API ภายในตามข้อมูลนั้น ต่อจากนั้นจะผ่านการค้นหาของคุณและรวบรวมข้อมูลจาก GraphQL API ภายในนั้น โดยพื้นฐานแล้ว บิลด์ของคุณจะจบลงด้วยข้อมูลที่คุณขอเท่านั้น และไม่มีอย่างอื่นอีก

ข้อดีของการพัฒนา WordPress แบบ Headless ด้วย Gatsby.js

เนื่องจากเราได้สัมผัสกับการพัฒนา Headless WordPress กับ Gatsby เราจึงสามารถแยกแยะข้อดีของแนวทางทางเทคนิคประเภทนี้ได้ สิ่งนี้ควรเป็นแนวทางในการตัดสินใจของคุณว่าจะรับ Gatsby หรือไม่!

• ประโยชน์ประการแรกคือความสามารถในการมีไซต์แบบคงที่และแสดงผลล่วงหน้า นี่เป็นวิธีที่มีประสิทธิภาพที่สุดในการแสดงผลหน้าเว็บ และเนื่องจาก Gatsby ใช้ GraphQL เพื่อดำเนินการตามจำนวนข้อมูลขั้นต่ำที่จำเป็น วิธีนี้จึงให้ประสิทธิภาพเพิ่มเติมสำหรับช่วงเวลาหลังจากการโหลดครั้งแรก
• การมองเห็น SEO ที่ได้รับการปรับปรุง: หน้าเว็บแบบคงที่นั้นง่ายต่อการอ่านสำหรับเครื่องมือค้นหา เนื่องจากทุกอย่างแสดงผลล่วงหน้าและจัดทำดัชนีได้ นี่เป็นข้อดี ตรงกันข้ามกับกลไกหัวขาดอื่นๆ ที่การแสดงหน้าเว็บด้วย JavaScript เป็นปัญหาเกี่ยวกับการเพิ่มประสิทธิภาพกลไกค้นหา (SEO)
• ความเร็วในการพัฒนาค่อนข้างเร็ว: เมื่อเปรียบเทียบกับวิธีการแบบโง่ๆ อื่นๆ Gatsby มีวิธีดึงข้อมูลที่เป็นหนึ่งเดียวและเข้าใจง่ายโดยไม่คำนึงถึงแหล่งที่มา สิ่งนี้ทำให้การพัฒนาค่อนข้างง่าย เนื่องจากคุณสามารถมุ่งเน้นไปที่ไซต์จริงของคุณ และปล่อยให้ Gatsby ทำหน้าที่ส่วนใหญ่
• โฮสติ้งที่ถูกกว่า: คุณสามารถโฮสต์แอปพลิเคชัน Gatsby ของคุณได้จากทุกที่ เนื่องจากเป็นเพียงการให้บริการไฟล์แบบสแตติก จึงช่วยลดค่าใช้จ่ายในการโฮสต์ นอกจากนี้ เนื่องจาก WordPress ถูกเรียกในระหว่างกระบวนการสร้างเท่านั้น และจะไม่ถูกเรียกในระหว่างเซสชันของผู้ใช้ จึงสามารถโฮสต์บนโซลูชันโฮสติ้งราคาไม่แพงได้เช่นกัน
• ความปลอดภัยขั้นสูง: โดยทั่วไปแล้ว ตัวสร้างไซต์แบบคงที่มีความปลอดภัยอย่างมาก เนื่องจากไม่มีการเชื่อมต่อโดยตรงกับฐานข้อมูล การขึ้นต่อกัน ข้อมูลผู้ใช้ หรือข้อมูลที่ละเอียดอ่อนอื่นๆ
• ไม่มีปลั๊กอิน: จากมุมมองของผู้ที่ไม่ใช่นักพัฒนา WordPress ใช้งานได้ง่ายเนื่องจากมีปลั๊กอินที่มีอยู่ อย่างไรก็ตาม สิ่งนี้จำกัดการใช้งานฟังก์ชันแบบกำหนดเอง น่าเสียดายที่ปลั๊กอินจำนวนมากเกินไปอาจทำให้ไซต์ช้าลงได้ เนื่องจากไซต์มีขนาดใหญ่และแสดงผลได้ยากขึ้น การดำเนินการของ Gatsby จะหลีกเลี่ยงปัญหาคอขวดเหล่านี้ได้

แง่มุมเพิ่มเติมที่สามารถกระตุ้นให้คุณพิจารณา Gatsby กับ WordPress:

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

ข้อเสียของการพัฒนา Headless WordPress ด้วย Gatsby.js

• ข้อจำกัดในการอัปเดต: เมื่อเนื้อหาเปลี่ยนตั้งแต่เริ่มต้น จะเป็นการจำกัดความถี่ที่ไซต์ของคุณสามารถอัปเดตได้ นอกจากนี้ อาจใช้เวลานานถึง 10 นาทีในการรัน Gatsby build หากไซต์ของคุณมีข้อมูลจำนวนมาก ซึ่งอาจเป็นปัญหาสำหรับไซต์ที่อัปเดตบ่อยๆ
• การอัปเดตเป็นประจำ: นอกจากนี้ เนื่องจาก Gatsby เป็นเครื่องมือสร้างไซต์แบบสแตติก จึงไม่สามารถ "แก้ไข" ได้เพียงเท่านั้น เนื่องจากการเปลี่ยนแปลงข้อความเพียงเล็กน้อยก็ยังต้องมีการปรับใช้ใหม่ ดังนั้น หากคุณมีหน้าเว็บที่ต้องการการเปลี่ยนแปลงเนื้อหารายวันแบบไดนามิกจำนวนมาก การดำเนินการนี้อาจใช้เวลานานและเร่งรีบ
• ความล่าช้า: โดยปกติคุณจะต้องรอหลายนาทีจึงจะเห็นการเปลี่ยนแปลงในเนื้อหาของคุณเมื่อมีการเผยแพร่
• ไม่มีการแสดงตัวอย่าง: คุณไม่มีการแสดงตัวอย่างใน Gatsby ไม่เหมือนแอปพลิเคชัน WordPress ทั่วไป น่าเศร้า นี่เป็นปัญหาที่ใหญ่ที่สุดที่ผู้สร้างเนื้อหาพบใน Gatsby คุณจะต้องคอมไพล์ทุกอย่าง อาจเป็นเพราะไปป์ไลน์ Gitlab CI/CD ที่คอมไพล์เว็บไซต์และนำทุกอย่างมาออนไลน์
• เส้นโค้งการเรียนรู้ขั้นสูง: โดยทั่วไป หากคุณต้องการทำงานกับ Gatsby และ WordPress ในเวลาเดียวกัน คุณต้องคุ้นเคยกับทั้งภาษา PHP และ JavaScript เนื่องจาก Gatsby รวม React และ GraphQL นี่อาจเป็นช่วงการเรียนรู้ที่สูงชันสำหรับหลาย ๆ คน

ความคิดสุดท้าย.

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

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

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