Going Headless: Use Case and What It’s Good For

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

เมื่อมองย้อนกลับไปในช่วงหลายปีที่ผ่านมาของการพัฒนาสำหรับเว็บ ฉันได้ใช้เครื่องมือ CMS ต่างๆ มากมายทั้งนอกชั้นวางและแบบทำเองที่บ้าน ฉันได้ปรับใช้และสร้าง ไซต์และปลั๊กอิน WordPress มากมาย รวมถึงส่วนขยายสำหรับไซต์ CMS ที่ให้บริการเต็มรูปแบบใน .NET แต่สำหรับฉัน ทุกสิ่งทุกอย่างเปลี่ยนไปเมื่อฉันได้ยินเรื่อง headless เป็นครั้งแรก และตอนนี้ หลายปีต่อมา ฉันรู้สึกสบายใจมากขึ้นใน ระบบนิเวศแบบ headless

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

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

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

ก่อนหัวขาด

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

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

ทุกอย่างเปลี่ยนไปในช่วงไม่กี่ปีที่ผ่านมาโดย CMS ที่ไม่มีหัว ได้รับแรงฉุดลากไปทั่วทั้งอุตสาหกรรม

ยุคฟื้นฟูศิลปวิทยาของเครื่องมือพิเศษ

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

ความสามารถในการออกแบบส่วนหน้าของคุณเองตั้งแต่เริ่มต้นนั้นทำให้ทีมพัฒนาหลายๆ ทีมเป็นอิสระ คุณอาจมีทีมวิศวกรแคร็กที่เชี่ยวชาญในการส่งแอปหน้าเดียวที่ลื่นไหลใน Vue.js หรือการเรนเดอร์ที่รวดเร็ว เว็บไซต์ที่สร้างสแตติกแบบกันกระสุนด้วย 11ty เฟรมเวิร์กการพัฒนาเว็บล่าสุดทั้งหมดได้รับการออกแบบให้ทำงานได้อย่างง่ายดายด้วยข้อมูลที่มีโครงสร้างซึ่งสามารถให้จาก CMS ที่ไม่มีส่วนหัว

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

หัวขาดเหมาะสำหรับฉันหรือไม่?

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

• หากคุณต้องการ ปรับแต่งทุกขั้นตอนของขั้นตอนการชำระเงินของผลิตภัณฑ์ คุณสามารถใช้ตัวเลือกการค้าแบบไม่มีหัวเพื่อให้บรรลุเป้าหมายนั้น
• หากคุณต้องการ เพิ่มประสิทธิภาพอย่างมากสำหรับ Time to First Byte คุณอาจต้องการใช้ตัวสร้างไซต์แบบสแตติกที่สร้างเนื้อหาใหม่ตามการเปลี่ยนแปลงตาม CMS API ที่ไม่มีส่วนหัว
• หากคุณ โฮสต์เครื่องมือของคุณเอง และระมัดระวังเรื่องความปลอดภัย คุณอาจต้องการล็อกสภาพแวดล้อมการเขียนของคุณไว้หลังไฟร์วอลล์ และใช้ระบบนี้อย่างไร้เหตุผลจากส่วนหน้าที่ใช้ Jamstack ที่ง่ายกว่า
• หากคุณกำลัง ให้บริการเนื้อหาเดียวกัน แก่ลูกค้าหลายราย เช่น เว็บ แอพที่มาพร้อมเครื่อง หรือวิดเจ็ตของบุคคลที่สาม คุณสามารถสร้างเนื้อหาเหล่านั้นในลักษณะที่พวกมันทั้งหมดจะสื่อสารผ่าน CMS เดียวกันแบบไม่มีส่วนหัว

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

ตัวอย่าง: Headless eCommerce

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

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

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

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

ในเวลาเดียวกัน คุณยังคง ออกจากการประมวลผลธุรกรรม จนถึงโซลูชันอีคอมเมิร์ซแบบ headless ของคุณ ดังนั้นคุณจึงได้รับประโยชน์จากระบบแบ็กเอนด์ของพวกเขา

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

หลีกเลี่ยงการล็อคอินด้วยแพลตฟอร์มเดียว

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

API เปิดใช้งานการตั้งค่า Jamstack ดังนั้นจึงมักเชื่อมโยงกับ CMS ที่ไม่มีส่วนหัว การเลือกหัวขาด ไม่จำเป็นต้องใช้ Jamstack front-end แน่นอน คุณยังสามารถเรียกใช้โค้ดฝั่งเซิร์ฟเวอร์ได้หากต้องการ

ตัวอย่างเช่น ฉันได้ช่วยสร้างไซต์บางไซต์ที่ใช้ Node.js และ Express ซึ่งใช้แบ็คเอนด์ API เช่น Wordnik.com และรูปแบบยอดนิยมนี้ทำงานได้อย่างราบรื่น การ เข้าถึงข้อมูลของคุณผ่าน API ทำให้สามารถทิ้งโค้ดฝั่งเซิร์ฟเวอร์ในการผลิตได้ ดังนั้นคุณจึงสามารถใช้แนวทางฝั่งไคลเอ็นต์ เช่น Jamstack ได้อย่างง่ายดาย หากมีความเหมาะสมในโครงการของคุณ

ปัญหาเกี่ยวกับโซลูชันแบบ "ครบวงจร" คือแต่ละโซลูชันมี ข้อผูกมัด มากมาย ตัวอย่างเช่น คุณต้องมุ่งมั่นที่จะสนับสนุนฐานข้อมูลและสภาพแวดล้อมการเขียนโปรแกรมหรือเลือกจากผู้ขาย SaaS ที่ทำ นอกจากนี้ การเปลี่ยนแปลงการออกแบบของคุณจะต้องเกิดขึ้นภายในธีมและปลั๊กอินที่มี

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

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

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

“

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

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

ไม่ใช่ทุกอย่างจะต้องหัวขาด

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

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

วิธีหัวขาดช่วยให้คุณฟื้นตัวจากความผิดพลาด

การอัพเกรดแบ็กเอนด์

อันตรายจากราคาต่อผู้ใช้

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

โซลูชัน CMS ที่โฮสต์ไว้ส่วนใหญ่ ไม่เผยแพร่โครงสร้างการกำหนดราคา สำหรับหมายเลขผู้ใช้ที่ใหญ่โตเช่นนี้ เมื่อเราสอบถามเกี่ยวกับค่าใช้จ่ายในการดำเนินการนี้ต่อบนแพลตฟอร์มเดียวกัน เราไม่ค่อยชอบคำตอบเท่าไหร่ เพื่อให้ระบบนี้มีเหตุผลทางธุรกิจต่อไป เราต้องเปลี่ยน CMS ออก เราสามารถทำ swap ได้โดยไม่ต้องทิ้ง frontend ด้วยเนื่องจากสถาปัตยกรรมแบบ headless

การควบคุมปริมาณ API

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

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

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

เมื่อระบบขยายตัวและปริมาณข้อมูลเพิ่มขึ้น เราก็มีอัตราการเติบโตเกินกว่าเครื่องมือนี้ ฉันสามารถแก้ไขปัญหานี้ได้โดยการสร้างคุณสมบัติการแก้ไขข้อมูลเบื้องต้นลงในระบบโดยอิงตามอินสแตนซ์ AWS DynamoDB ที่เคยอ่านจาก airtable เราสามารถแลกเปลี่ยนคุณสมบัติ UI การเขียน Airtable ที่ลื่นไหลได้อย่างรวดเร็วสำหรับขนาดที่ใหญ่ขึ้นและค่า SaaS รายเดือนที่ต่ำลง

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

การอัพเกรด Frontend

กรอบงานใหม่เงางาม

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

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

Riot.js เป็นไลบรารี่สุดเจ๋งที่อัดแน่นไปด้วยฟีเจอร์มากมายในขนาดที่เล็ก ช่วยให้คุณเขียนส่วนประกอบไฟล์เดียวที่ขับเคลื่อนด้วยข้อมูล เช่น Vue.js เมื่อผู้พัฒนาฟรอนท์เอนด์นี้ออกจากบริษัทหลังจากจัดส่งเวอร์ชัน 1.0 ได้ไม่นาน ทีมงานก็สูญเสียคนเดียวที่มีความกระตือรือร้นในห้องสมุดนั้นไป

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

“

โชคดีที่ลักษณะที่แยกจากกันของสถาปัตยกรรม CMS ที่ไม่มีส่วนหัวนั้นให้ความยืดหยุ่นใน การเปลี่ยนส่วนหน้าของคุณโดยไม่ต้องแตะส่วนหลัง เราสามารถเขียนโค้ด front-end ใหม่และสลับในส่วนประกอบ front-end ที่อัปเดตตามไลบรารีต่างๆ ที่ใช้กันทั่วไปในโปรเจ็กต์อื่นๆ

ความเร็วดิบ

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

มีด้านหนึ่งของการแก้ปัญหาที่ยังไม่สมบูรณ์แม้ว่า Time to First Byte บนบล็อกที่โฮสต์โดย Ghost ของฉันช้าเกินไป เนื่องจากฉันสามารถดึงเนื้อหาโพสต์ทั้งหมดผ่าน API ได้ ฉันจึงสามารถตั้งค่าส่วนหน้าที่สร้างขึ้นแบบสแตติกของตัวเองบน S3 + Cloudfront ซึ่งใช้เนื้อหาโพสต์ทั้งหมดที่ฉันเขียนใน Ghost แต่มีเวลาเร็วกว่าในไบต์แรก

Headless CMS As A Service

มีธุรกิจ Software As A Service มากมายที่ทุ่มเท อย่าง เต็มที่ การลงทะเบียนกับผู้ขายรายใดรายหนึ่งเหล่านี้จะทำให้คุณมีสภาพแวดล้อมใน การแก้ไขเนื้อหาที่เป็นมิตร และปลายทาง API ที่สะอาดเพื่อใช้งานได้ทันที ต่อไปนี้คือการเปรียบเทียบสั้นๆ ของผู้คนที่มีแผนระดับเริ่มต้นที่มีต้นทุนต่ำมาก และให้ความสำคัญกับประสบการณ์ CMS แบบไม่ใช้หัวด้วยเลเซอร์

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

รูปแบบหัวขาดที่น่าตื่นเต้น

การใช้ CMS ตาม GitHub

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

มีเครื่องมือ CMS ที่ใช้ GitHub หลากหลายรสชาติ นี่เป็นวิธีที่รวดเร็วในการขยายไซต์เอกสาร: Spacebook คุณสามารถรวมเข้ากับ Netlify เพื่อรับ UI การแก้ไข markdown ที่สะอาดขึ้น หรือใช้โดยตรงบน GitHub

คุณลักษณะการแสดงตัวอย่าง ที่ตอนนี้สร้างไว้ในโปรแกรมแก้ไขเว็บ GitHub ทำให้เครื่องมือบางอย่างเหล่านี้เข้าถึงได้ง่ายขึ้นสำหรับผู้ที่ไม่คุ้นเคยกับ HTML ฉันชอบตัวเลือกความแตกต่างของมุมมองที่หลากหลายซึ่ง GitHub แสดงการเปลี่ยนแปลงการลดราคาในโหมดแสดงตัวอย่างแบบเต็ม

นี่คือรายการเครื่องมือ 85 CMS ที่ยอดเยี่ยมที่ให้คุณจัดเรียงได้ว่าเป็นเครื่องมือที่ใช้ GitHub หรือไม่

API สำหรับเครื่องมือที่คุ้นเคย

การติดตั้ง WordPress ของคุณมาพร้อมกับจุดปลาย API ดังนั้นคุณจึงสามารถใช้เครื่องมือการเขียนที่ทีมของคุณมีประสบการณ์ในรูปแบบหัวขาดได้ต่อไป WordPress มีเอกสารที่ดีสำหรับ REST API สิ่งนี้เปิดใช้งานในการติดตั้ง WordPress ใหม่ ดังนั้นเมื่อคุณสร้างสภาพแวดล้อมการเขียน WordPress ใหม่ คุณสามารถเริ่มอ่าน JSON ได้จาก https://example.com/wp-json/wp/v2/posts

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

การรวมแหล่งข้อมูล

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

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

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

WordPress -> FAAS -> GitHub repo ส่วนหนึ่งของสถาปัตยกรรมถูกสร้างขึ้นโดย Carter Medlin เขาเชื่อมโยงไปป์ไลน์นี้เข้าด้วยกันตั้งแต่ต้นในสองสามวันในขณะที่เราออกแบบและสร้างส่วนหน้าของไซต์ สิ่งนี้ทำงานบนฟังก์ชัน MS Azure แบบไร้เซิร์ฟเวอร์ ดังนั้นจึงมีต้นทุนโครงสร้างพื้นฐานและการบำรุงรักษาต่ำ มันได้รับ ping จากบริการอัปเดต WordPress ที่อธิบายไว้ก่อนหน้านี้ ดึง json จาก WordPress API และเขียนเนื้อหาใหม่ลงใน GitHub รหัสสำหรับปลายทางแบบไร้เซิร์ฟเวอร์นี้สามารถดูได้บน GitHub

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

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

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

ข้อควรพิจารณาในการตัดสินใจเลือกหัวขาด

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

การเขียนคุณสมบัติสภาพแวดล้อม

• ง่ายต่อ การเขียนเอกสาร
• ง่ายต่อการเพิ่มข้อมูลที่มีโครงสร้าง
• ตัวเลือกเค้าโครง
• ดูตัวอย่าง คุณสมบัติ
• เวิร์กโฟลว์การอนุมัติเนื้อหา

ฟีเจอร์ Content API

• มีคำถามอะไรบ้าง
• โครงสร้างเนื้อหา ละเอียด แค่ไหน
• มีข้อ จำกัด ในการเข้าถึงข้อมูลหรือไม่ (ขีดจำกัดฮาร์ด REST API ของ Airtable)
• ความสามารถใน การปรับขนาด : คุณต้องวาง CDN ไว้ข้างหน้า API เนื้อหาของคุณหรือไม่
• ง่ายต่อการเพิ่มการแปล
• การนำเนื้อหาของคุณออกไป จะเป็นอย่างไรถ้าคุณเปลี่ยนแผน การดึงข้อมูลทั้งหมดของคุณจะยากเพียงใด

ค่าใช้จ่าย

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

การควบคุมแหล่งที่มา/กระแสการอนุมัติ

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

การจัดการไฟล์แบบคงที่

• ผู้เขียนของคุณเพิ่มรูปภาพใหม่ pdf ฯลฯ ได้ง่ายเพียงใด?
• ความง่ายในการขอไฟล์ที่ผู้เขียนอัปโหลดไปยังโฟลว์การปรับภาพให้เหมาะสม?

ที่หัวขาดกำลังมุ่งหน้าไป

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

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

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

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

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

แหล่งข้อมูลเพิ่มเติม

• Headless CMS รายการเครื่องมือ 85 CMS ที่ยอดเยี่ยมที่ให้คุณจัดเรียงได้ว่าเป็นเครื่องมือที่ใช้ GitHub หรือไม่
• “วิธีสร้างเว็บไซต์ WordPress ที่ไม่มีหัวบน Jamstack” Sarah Drasner และ Geoff Graham
• การค้าหัวขาด Shopify
• “GoTrue JS: นำการตรวจสอบสิทธิ์ไปยังไซต์คงที่ด้วย JS เพียง 3kb” Divya Sasidharan, Netlify
• ประสบการณ์การแก้ไขสำหรับไซต์ Jamstack, Stackbit
• API การรวม Wordpress, CAdotGov, GitHub

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