เราใช้ Strapi กับระบบจ่ายเงิน แต่เลือก Directus ให้เว็บตัวเอง

ตอนเที่ยงในโรงอาหารของ muRata พนักงานจ่ายค่าอาหารด้วยบัตรพนักงาน ยอดเงินถูกตัดจากบัตร Rabbit แบบเติมเงิน แล้วก็ถือถาดไปนั่งได้เลย เบื้องหลังเครื่องนั้นคือ API ที่เราสร้างด้วย Strapi และมันยังทำงานอยู่บน production จนถึงวันนี้ครับ (อ่านเรื่องโปรเจกต์นี้)

ส่วนเว็บที่คุณกำลังอ่านอยู่นี้ เราไม่ได้ใช้ Strapi ครับ เราใช้ Directus

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

จุดต่างจริง ๆ อยู่ที่ว่าใครเป็นเจ้าของโครงข้อมูล

Strapi เริ่มจากโค้ดครับ content type แต่ละตัวคือไฟล์ schema.json ในโปรเจกต์ พร้อม controller, service และ route ของมันเอง ใน Smart Canteen เรามี content type หกตัว คือ canteen, shop, menu, menu group, dish และ transaction ทั้งหมดอยู่ใน git ผ่าน code review และ deploy ไปพร้อมกับโค้ดส่วนอื่น

Directus เริ่มจากฐานข้อมูลครับ collection คือตารางจริงใน SQL พอเพิ่ม field ในหน้า admin ตารางก็เปลี่ยนตาม และ REST กับ GraphQL ก็เห็น field ใหม่ทันที ไม่ต้อง build ไม่ต้อง restart

ลองนึกภาพตามนะครับ ฝั่งหนึ่ง ฐานข้อมูลเป็นผลลัพธ์ของโค้ด อีกฝั่ง API เป็นผลลัพธ์ของฐานข้อมูล ความต่างข้อเดียวนี้พาไปสู่วิธีทำงานคนละแบบเลย

Strapi เก่งตรงที่เรามี logic ต้องเขียนเอง

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

ตรงนี้ Strapi ช่วยเราได้ดีมากครับ มันมีจุดให้แทรกโค้ดได้ทั้งก่อนและหลังการบันทึก เราเขียน custom validation และ action ที่ต้องทำหลัง transaction เสร็จได้ตรง ๆ เป็น JavaScript ธรรมดาในโปรเจกต์เดียวกัน ทดสอบได้ อ่านย้อนหลังได้ dev ที่เข้ามาใหม่ก็ไล่ตามได้ไม่ยาก

เมื่อ logic คือหัวใจของระบบ การที่ model อยู่ในโค้ดเดียวกับ logic เป็นข้อดีครับ ไม่ใช่ข้อเสีย

ต้นทุนที่จ่ายทุกครั้งที่ model เปลี่ยน

แต่ข้อดีเดียวกันนี้ก็มีราคาครับ บน production ตัว Content-Type Builder ของ Strapi ถูกปิดไว้ ใช้ได้เฉพาะตอน develop ดังนั้นพอลูกค้าขอเพิ่ม field หนึ่งตัว เราต้องแก้ schema ในโค้ด build แล้ว deploy ใหม่

กับ Smart Canteen เราเจอแบบนี้จริงครับ การแก้และ deploy แต่ละรอบใช้เวลาราว 10 ถึง 30 นาที และยังไม่จบแค่นั้น เพราะเป็นระบบที่เกี่ยวกับเงิน หลัง deploy เราต้องรัน test ตรวจอีกพักใหญ่กว่าจะวางใจได้

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

ทำไมเว็บนี้ถึงเป็น Directus

ตอนเริ่มทำเว็บนี้กลางเดือนสิงหาคม 2026 เราคิดถึง Strapi ก่อนครับ เพราะคุ้นมือและรู้ว่ามันดีจริง แต่พอมองว่าเว็บนี้จะโตไปทางไหน เราเลือก Directus เพราะแก้ data model ได้โดยไม่ต้องหยุด API และไม่ต้อง deploy API ใหม่

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

อีกอย่างที่ใช้แล้วชอบคือ Flow ครับ เรามี Flow ชื่อ Revalidate the website คอยส่งสัญญาณไปที่หน้าเว็บทุกครั้งที่เนื้อหาเปลี่ยน ของใหม่ขึ้นเว็บเองภายในราวหนึ่งนาที เราไม่ต้อง deploy เพื่อให้เนื้อหาขึ้น deploy เฉพาะตอนแก้โค้ดหน้าเว็บเท่านั้น

"ไม่ต้อง dev" ไม่ได้แปลว่าไม่มีโค้ด

ตรงนี้คือเรื่องที่คนเข้าใจผิดบ่อยที่สุดครับ เวลาได้ยินว่า Directus แก้ model ได้โดยไม่ต้องพึ่ง dev หลายคนนึกภาพว่าทุกอย่างทำด้วยการคลิกในหน้า admin

ของจริงในเว็บเรา เรามีสคริปต์สำหรับ Directus อยู่ 54 ตัว ในนั้น 21 ตัวทำหน้าที่สร้างหรือแก้ collection, field และ relation ผ่าน API เหตุผลคือเรามีสอง environment คือ UAT กับ production ถ้าแก้ด้วยมือทีละที่ สักวันสองที่จะไม่ตรงกันแน่นอน สคริปต์ทำให้เราทำซ้ำได้ ตรวจได้ และเก็บไว้ใน git ได้

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

ต้นทุนแฝงที่ควรรู้ก่อนเลือก

มีสองเรื่องที่ตารางเทียบฟีเจอร์มักไม่บอกครับ

เรื่องแรกคืออายุของเวอร์ชัน Smart Canteen ยังรันบน Strapi 4 ซึ่ง Strapi หยุดแก้บั๊กไปตั้งแต่ปลายเดือนตุลาคม 2025 และหยุดออก security fix ไปเมื่อปลายเดือนเมษายน 2026 การขึ้น Strapi 5 ไม่ใช่แค่กดอัปเดต มี breaking change ทั้งในโค้ดฝั่ง server และรูปแบบ response ที่แอปปลายทางเรียกใช้ ต้องวางแผนเป็นงานหนึ่งก้อน เราพูดตรง ๆ ว่าระบบของเราเองก็ยังอยู่ในสถานะนี้ครับ และข้อนี้ไม่ได้เป็นปัญหาเฉพาะของ Strapi framework ไหนที่ model อยู่ในโค้ด การขึ้นเวอร์ชันใหญ่จะแตะโค้ดของเราเสมอ

เรื่องที่สองคือไลเซนส์ Strapi Community ใช้ MIT ส่วน Directus ใช้ BSL 1.1 ซึ่งใช้บน production ได้ฟรีสำหรับองค์กรที่มี total finances ไม่เกิน 5 ล้านดอลลาร์สหรัฐ ถ้าเกินต้องซื้อไลเซนส์เชิงพาณิชย์ สำหรับเราข้อนี้ไม่เป็นปัญหา แต่ถ้าคุณทำระบบให้องค์กรขนาดใหญ่ ควรเช็คตั้งแต่ก่อนเสนอราคาครับ

เลือกยังไงดี

เราไม่อยากจบด้วยคำว่า "แล้วแต่งาน" เฉย ๆ ครับ ลองถามตัวเองตามนี้ดู

ถ้าความซับซ้อนอยู่ที่ business logic มีการคำนวณ การตรวจสอบ และ action ต่อเนื่องที่ต้องทดสอบอย่างเข้มงวด และโครงข้อมูลน่าจะนิ่งหลังขึ้นระบบ Strapi เหมาะครับ แบบเดียวกับที่ Smart Canteen ทำงานมาได้ดีจนทุกวันนี้

ถ้าความซับซ้อนอยู่ที่ตัวข้อมูล collection เพิ่มขึ้นเรื่อย ๆ คนดูแลเนื้อหาไม่ใช่ dev หรือคุณมีฐานข้อมูล SQL อยู่แล้วและอยากได้หน้า admin กับ API ครอบมันโดยไม่ต้องย้ายข้อมูล Directus เหมาะกว่าครับ

แล้วถ้างานมีทั้งสองอย่าง ให้ถามต่อว่าในสองปีข้างหน้า อะไรจะเปลี่ยนบ่อยกว่ากันระหว่าง logic กับโครงข้อมูล คำตอบนั้นมักชี้ทางได้ชัดกว่าการไล่ดูทีละฟีเจอร์

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