อย่าหัวเสีย: การประเมินหัวขาด

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

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

หัวขาด? อะไร?

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

หากคุณกำลังวางแผนที่จะสร้างไซต์โดยใช้ Jamstack คุณจะต้องมุ่งหน้าไปในทิศทางนี้โดยค่าเริ่มต้น แต่วิธีการนี้ก็ใช้ได้กับโครงการประเภทอื่นๆ ด้วย โดยใช้ภาษาฝั่งเซิร์ฟเวอร์ เช่น PHP, . เน็ตหรือทับทิม

แต่ทำไมเรื่องนี้ถึงเป็นเรื่อง?

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

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

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

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

เราบังเอิญบรรลุผลนี้โดยใช้ Nuxt เพื่อสร้างไซต์ แต่เราสามารถเลือกที่จะรวมข้อมูลจาก CMS ได้โดยตรงภายในเทมเพลต Shopify Jamstack ได้รับเลือกให้เป็นแนวทางที่ดีกว่าที่นี่ แต่หัวขาดนั้นยืดหยุ่นพอที่จะใช้งานได้เกือบทุกที่ ตราบใดที่คุณสามารถเข้าถึงการเขียนสคริปต์บางประเภทผ่าน JavaScript หรือภาษาแบ็คเอนด์แบบดั้งเดิม เช่น PHP หรือ .Net คุณก็จะสามารถผสานรวมหัวเรื่องเข้ากับเวิร์กโฟลว์ของคุณได้

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

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

ฟังดูดีมาก! หัวขาดเหมาะกับฉันไหม

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

คุณพอใจกับความต้องการความรู้ในการแยกส่วนหรือไม่?

หลายคนคิดว่าการเปลี่ยนไปใช้ระบบ Headless สามารถ “ขจัด” ความจำเป็นของ Back-end Developer ได้ แต่ความจริงก็คือ Mindset ในการ จัดโครงสร้างข้อมูลอย่างมีประสิทธิภาพ และสร้างโมเดลเนื้อหาที่ทำงานและปรับขนาดได้ดี ยังคงแตกต่างจาก Mindset อย่างมาก จำเป็นต้องเป็นนักพัฒนาส่วนหน้าที่ยอดเยี่ยมเป็นส่วนใหญ่ ยังมีช่องว่างความรู้และยังคงต้องการเติมเต็ม

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

คุณรู้ต้นทุนรวมของการเป็นเจ้าของหรือไม่?

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

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

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

คุณได้อธิบายให้ลูกค้าของคุณเข้าใจดีพอแล้วหรือยัง?

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

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

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

คุณใช้เวลาในการพัฒนาเพิ่มเติมหรือไม่?

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

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

คุณ/ลูกค้าของคุณสบายใจกับข้อมูลที่ไม่ได้อยู่บนโครงสร้างพื้นฐานของคุณเองหรือไม่

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

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

โอเค เยี่ยมเลย ดังนั้นตัวเลือกของฉันคืออะไร?

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

อิ่มเอม

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

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

Contentful มีชุดการผสานรวมกับแอป SaaS อื่นๆ ดังนั้นจึงง่ายต่อการผสานรวมกับ Shopify หรือ CommerceLayer สำหรับอีคอมเมิร์ซ หรือ Cloudinary สำหรับการโฮสต์และประมวลผลสินทรัพย์

ดีที่สุดสำหรับ:

ผู้ที่กำลังมองหาวิธีแก้ปัญหาที่มั่นคงที่สุดในพื้นที่หัวขาด

Storyblok

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

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

ดีที่สุดสำหรับ:

ผู้ที่มองหาโซลูชันการแก้ไขเนื้อหา WYSIWYG ที่ดีที่สุดในระดับเดียวกันจาก CMS ที่ไม่มีส่วนหัว

สติ

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

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

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

ดีที่สุดสำหรับ:

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

ปริซึม

ปริซึมเป็นตัวละครเก่าในห้องในพื้นที่หัวขาด ย้อนกลับไปในปี 2013 แต่นั่นก็ไม่ได้หยุดพวกเขาในการสร้างสรรค์สิ่งใหม่ ๆ ในพื้นที่ เมื่อปีที่แล้ว พวกเขาได้เปิดตัว SliceMachine ซึ่งมีจุดมุ่งหมายเพื่อเชื่อมช่องว่างระหว่างนักพัฒนาส่วนหน้าที่สร้างส่วนประกอบและผู้เขียนเนื้อหาโดยสร้างความสัมพันธ์แบบ 1:1 ระหว่างบล็อกเนื้อหา (หรือ "ส่วน") และส่วนประกอบส่วนหน้า ซึ่งทำให้การสร้างใหม่ หน้าและส่วนเนื้อหาเป็นเรื่องง่ายสำหรับบรรณาธิการ

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

ดีที่สุดสำหรับ:

ผู้ที่ต้องการลดความขัดแย้งสำหรับผู้แก้ไขเนื้อหา

เกิดอะไรขึ้นถ้าฉันต้องการบางสิ่งบางอย่างแบบดั้งเดิมมากขึ้น?

เวิร์ดเพรส

Wordpress ยังคงมีขนาดใหญ่ในปี 2021 สำหรับโฆษณาทั้งหมดบนแพลตฟอร์มอื่น ๆ WordPress ยังคงให้พลังงานแก่อินเทอร์เน็ตประมาณ 40% และจะไม่ไปไหน นักพัฒนาซอฟต์แวร์กำลังช่วยให้แน่ใจว่าสิ่งนี้โดยการปรับปรุงความสามารถที่ไม่มีส่วนหัวและมุ่งเน้นที่การสนับสนุน API ให้มากขึ้น เครื่องมือแก้ไขใหม่ๆ ยังทำให้ประสบการณ์ในการเขียนใน WordPress นั้นสนุกยิ่งขึ้น และข้อเสียบางประการในการทำงานร่วมกับ WordPress ก็ได้รับการปรับปรุงอย่างมากในช่วงไม่กี่ปีที่ผ่านมา

การทำงานกับบริษัท WordPress-as-a-service เช่น Nestify ช่วยลดความวิตกกังวลและปัญหาด้านความปลอดภัยได้มากในฐานะนักพัฒนา แต่พึงระลึกไว้เสมอว่าในฐานะที่เป็นแพลตฟอร์มที่ใหญ่ที่สุดบนอินเทอร์เน็ต WordPress ยังคงเป็นสิ่งที่ดึงดูดใจอย่างมาก เป้าหมายสำหรับผู้ที่มีเจตนาร้าย

ดีที่สุดสำหรับ:

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

Sitecore

ในฐานะที่เป็นหนึ่งในยักษ์ใหญ่ด้านการจัดการเนื้อหาระดับองค์กร Sitecore อาจเป็นหนึ่งในชื่อที่คุณคาดหวังน้อยที่สุดในรายการนี้ แต่พวกเขามีความก้าวหน้าอย่างมากในการสนับสนุนหัวขาด โดยปล่อย Sitecore JSS เพื่อให้โครงการ Jamstack สามารถเชื่อมต่อกับข้อมูล Sitecore

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

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

ดีที่สุดสำหรับ:

ผู้ที่มองหาโครงการระดับองค์กรกับลูกค้าที่ไม่ต้องการ "เต็มที่" กับเทคโนโลยีใหม่

Adobe Experience Manager

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

ขณะนี้ AEM รองรับวิธีการขอข้อมูลออกจากแพลตฟอร์มได้หลายวิธี และตอนนี้ Adobe ทำการตลาด AEM เป็น "CMS แบบไฮบริด" ซึ่งหมายความว่าจะรวมการทำงานแบบ Headless และแบบดั้งเดิมเฉพาะช่องสัญญาณเข้าไว้ด้วยกัน นี่อาจเป็นข้อได้เปรียบที่ยิ่งใหญ่สำหรับทีมการตลาดที่ต้องการทำงานข้ามแพลตฟอร์มที่หลากหลายและต้องการการควบคุมเนื้อหาที่ละเอียดระหว่างแพลตฟอร์มเหล่านี้ แต่ผู้ที่ต้องการใช้งาน "แพลตฟอร์มเดียวที่จะปกครองพวกเขาทั้งหมด" ของ Adobe จะต้องมีกระเป๋าที่ลึกเพื่อเริ่มต้น

ดีที่สุดสำหรับ:

ผู้ที่มองหาจุดสุดยอดขององค์กรด้วยกระเป๋าที่ลึกล้ำ! AEM ทำอะไรได้มากมาย (มากกว่าที่เราเคยหวังจะพูดถึงที่นี่) แต่มี ราคาแพง

ตอนนี้ฉันมีไอเดียเกี่ยวกับตัวเลือกของฉันแล้ว แต่ฉันจะหวังว่าจะเลือกระหว่างตัวเลือกเหล่านี้ได้อย่างไร

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

ต้องใช้เวลานานแค่ไหนกว่าจะถึงความเร็ว?

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

คุณต้องการการสนับสนุนรูปแบบใด

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

ผู้ขายมีฐานะดีแค่ไหน?

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

ประสบการณ์การแก้ไขเป็นอย่างไร?

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

“ระบบที่คุณกำลังดูอยู่สามารถแก้ไขในบริบทหรือแสดงตัวอย่างแบบร่างสดได้หรือไม่”

“ความพยายามมากแค่ไหนในการตั้งค่าสิ่งเหล่านี้”

“ตัวแก้ไขทำงานเร็วหรือช้าแค่ไหน”

“ผู้ใช้ถูกโจมตีด้วยตัวเลือกและปุ่มที่ไม่คุ้นเคย หรือมีการจัดการที่ดีหรือไม่”

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

การนำข้อมูลของคุณออกจากแพลตฟอร์มทำได้ง่ายเพียงใด?

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

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

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

สรุป

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

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

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

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