นักพัฒนา Node.js ทุกคนต้องเจอกับปัญหาเดิมๆ ไม่ช้าก็เร็ว เมื่อผู้ใช้คลิกปุ่ม ตัวจัดการเส้นทาง (route handler) ของคุณเริ่มประมวลผลงานหนักๆ และคำขอ HTTP ก็ค้างอยู่ตรงนั้น คุณอาจกำลังส่งอีเมลแบบเป็นชุด (batched emails), ซิงค์ข้อมูลไปยัง CRM ของบุคคลที่สาม หรือกำลังสร้างรายงาน PDF เบราว์เซอร์หมุนค้าง แอปมือถือหมดเวลา (timeout) ผู้ใช้เริ่มไม่พอใจ และเซิร์ฟเวอร์ของคุณก็เสียช่องทางการเชื่อมต่อ (connection slots) ที่ไม่ควรจะเสียไป วิธีแก้ไขคือการย้ายงานเหล่านั้นออกจากเส้นทางการรับคำขอ (request path) ไปไว้ในคิวงานเบื้องหลัง (background job queue) ที่มี Redis เป็นตัวสนับสนุน ในระบบนิเวศของ Node.js มีไลบรารีสองตัวที่ครองพื้นที่นี้อยู่ นั่นคือ Bull และ BullMQ การเลือกระหว่างสองตัวนี้ไม่ใช่เรื่องของการหาผู้ชนะ แต่เป็นเรื่องของการทำความเข้าใจว่าโปรเจกต์ของคุณอยู่ในจุดไหนและกำลังจะมุ่งหน้าไปทางใด
เครื่องมือหลักดั้งเดิม
Bull เป็นมาตรฐานสำหรับการประมวลผลเบื้องหลังของ Node.js มานานหลายปี มันมีความเสถียร ผ่านการทดสอบมาอย่างโชกโชน และใช้งานอยู่ในแอปพลิเคชันระดับโปรดักชันจำนวนมหาศาล หากคุณต้องการตั้งเวลาทำงานไว้ทำภายหลัง, ลองนำเข้าข้อมูลที่ล้มเหลวใหม่อัตโนมัติ หรือกำหนดลำดับความสำคัญที่เข้มงวดเพื่อให้ payment webhooks ทำงานก่อนการส่งจดหมายข่าว Bull สามารถจัดการได้โดยไม่มีปัญหา API ของมันเป็นรูปแบบ callback-oriented ซึ่งหมายความว่ามันเข้ากับโค้ดฐานเดิม (codebases) ได้ดี ในยุคที่ promises ยังเป็นเรื่องใหม่ ทีมที่ใช้งาน Bull มานานย่อมรู้ดีว่าจะต้องเจอกับอะไร ไลบรารีนี้เก็บสถานะไว้ใน Redis ดังนั้นหากกระบวนการ Node ของคุณเริ่มทำงานใหม่ งานต่างๆ ก็ยังคงอยู่ ความน่าเชื่อถือนี้เองคือเหตุผลที่หลายธุรกิจไม่รู้สึกถึงความจำเป็นที่จะต้องไปแตะต้องระบบที่ทำงานได้ดีอยู่แล้ว
สิ่งที่ BullMQ เปลี่ยนแปลง
BullMQ คือผู้สืบทอด มันถูกสร้างขึ้นใหม่ทั้งหมดด้วย TypeScript และโครงสร้างทั้งหมดถูกออกแบบมาเพื่อ async/await หากคุณใช้เวลาไม่กี่ปีที่ผ่านมาในการเขียนโค้ด Node.js สมัยใหม่ คุณจะรู้สึกคุ้นเคยกับไวยากรณ์ (syntax) ของมันทันที แต่ความแตกต่างนั้นลึกซึ้งกว่าแค่เรื่องการกำหนดประเภทข้อมูล (type definitions) และการต่อสาย promise BullMQ บังคับให้มีการแยกส่วนที่ชัดเจนระหว่าง queues และ workers ใน Bull ตัว queue มักจะทำหน้าที่เป็นตัวรัน worker ไปด้วยในตัว แต่ใน BullMQ คุณจะกำหนด queue ในไฟล์หนึ่งและ worker ในอีกไฟล์หนึ่ง การแยกส่วนนี้สะท้อนถึงวิธีการขยายระบบ (scale) ในระดับโปรดักชันจริงๆ คุณสามารถปรับใช้ (deploy) กลุ่มของ worker containers เพื่อประมวลผลงานเพียงอย่างเดียว ในขณะที่ API servers ของคุณทำหน้าที่เพียงแค่เพิ่มงานลงใน queue เท่านั้น สถาปัตยกรรมจะยังคงอ่านง่ายแม้ระบบจะเติบโตขึ้น
ฟีเจอร์ที่สร้างความได้เปรียบ
จุดที่ BullMQ นำหน้าอย่างแท้จริงคือฟังก์ชันการทำงานที่ Bull ไม่มีให้ โดยมีสามส่วนสำคัญที่ส่งผลต่อการใช้งานจริง
Job Flows
เวิร์กโฟลว์ที่ซับซ้อนมักจะไม่สามารถบรรจุอยู่ในฟังก์ชันเบื้องหลังเพียงฟังก์ชันเดียวได้ ลองจินตนาการว่าคุณกำลังสร้าง pipeline สำหรับประมวลผลรูปภาพ ผู้ใช้อัปโหลดรูปภาพต้นฉบับ และ backend ของคุณต้องสร้างรูปย่อ (thumbnail), สร้างตัวอย่างภาพแบบบีบอัด, รันการสแกน OCR และจากนั้นจึงแจ้งเตือน frontend ว่าทุกอย่างพร้อมแล้ว หากใช้ Bull คุณอาจจะต้องยัดขั้นตอนทั้งหมดเหล่านั้นลงใน handler ขนาดใหญ่ที่เปราะบางเพียงตัวเดียว BullMQ นำเสนอ job flows ซึ่งช่วยให้คุณสามารถเชื่อมโยงงานที่เป็น parent และ child เข้าด้วยกันได้อย่างชัดเจน คุณสามารถกำหนดความสัมพันธ์ (dependencies) เพื่อให้ขั้นตอนการแจ้งเตือนทำงานหลังจากที่ทั้งงาน thumbnail และ OCR สำเร็จแล้วเท่านั้น หาก OCR ล้มเหลว คุณสามารถลองใหม่เฉพาะส่วนนั้นได้โดยไม่ต้องประมวลผล thumbnail ซ้ำอีกครั้ง ตรรกะจะกลายเป็นแบบ modular, ตรวจสอบได้ (observable) และดีบั๊กได้ง่ายขึ้นมากเมื่อมีบางอย่างพังตอนตีสาม
Group Rate Limiting
หากคุณรันแอปพลิเคชัน SaaS แบบ multi-tenant คุณอาจเคยกังวลว่าลูกค้าเพียงรายเดียวจะส่งงานมาถล่ม workers ของคุณ ลูกค้าเพียงรายเดียวอาจส่งงาน export เข้าคิวเป็นหมื่นงานจนทำให้คนอื่นใช้งานไม่ได้ BullMQ เพิ่มระบบ group rate limiting ซึ่งช่วยให้คุณจำกัดความเร็ว (throttle) การประมวลผลตามราย tenant หรือตาม API key ได้ ตัวอย่างเช่น คุณอาจอนุญาตให้ Tenant A เรียกใช้งาน external API ได้ 50 ครั้งต่อนาที ในขณะที่ Tenant B ก็จะมีโควตา (bucket) ของตัวเองแยกกันอย่างเป็นอิสระ คิวจะเคารพขีดจำกัดเหล่านี้ในระดับ global ทั่วทุก worker instances ไม่ใช่แค่เฉพาะเครื่องใดเครื่องหนึ่ง นี่คือวาล์วนิรภัยที่คุณอาจไม่เห็นความสำคัญจนกว่าจะถึงเวลาที่จำเป็นต้องใช้มันจริงๆ
รูปแบบการใช้งานที่ทันสมัย
BullMQ ตัดรูปแบบ callback แบบเก่าทิ้งไปและหันมาใช้ API ที่ทันสมัย การจัดการข้อผิดพลาด (error handling) เป็นไปตามรูปแบบ promise มาตรฐาน การกำหนดประเภทข้อมูล TypeScript เป็นฟีเจอร์หลัก (first-class) ไม่ใช่สิ่งที่ถูกเพิ่มเข้ามาภายหลังจากแพ็กเกจของชุมชน หากคุณกำลังเริ่มโปรเจกต์ใหม่ (greenfield project) ประสบการณ์ของนักพัฒนา (developer experience) จะราบรื่นขึ้นอย่างเห็นได้
ข้อดีในเชิงปฏิบัติอย่างหนึ่งของการตัดสินใจนี้คือเรื่องโครงสร้างพื้นฐาน (infrastructure) ทั้ง Bull และ BullMQ เก็บสถานะของงาน (job state), metadata และกำหนดการ (schedules) ไว้ใน Redis แม้จะใช้โครงสร้างคีย์ภายในที่แตกต่างกัน แต่เทคโนโลยีเบื้องหลังนั้นเหมือนกันทุกประการ หากคุณใช้งาน Redis สำหรับ Bull อยู่แล้ว คุณไม่จำเป็นต้องเปลี่ยนฐานข้อมูลใหม่หรือต้องคิดเรื่อง deployment topology ใหม่เพื่อเปลี่ยนมาใช้ BullMQ ความท้าทายในการย้ายระบบ (migration) อยู่ที่โค้ดของแอปพลิเคชัน ไม่ใช่ที่ค่าใช้จ่ายเซิร์ฟเวอร์
ความเป็นจริงของการย้ายระบบ
อย่างไรก็ตาม การเปลี่ยนจาก Bull ไปเป็น BullMQ ไม่ใช่การแทนที่แบบสลับเปลี่ยนได้ทันที (drop-in replacement) การเรียกใช้ API เปลี่ยนไป ชื่อของ event ก็ต่างกันออกไป วิธีที่คุณกำหนด processor และจัดการ concurrency นั้นถูกเขียนขึ้นใหม่มากพอที่คุณจะต้องเข้าไปแก้ไขทุกไฟล์ที่มีการติดต่อกับ queue ที่สำคัญกว่านั้น คุณไม่สามารถแค่สลับสวิตช์แล้วหวังว่างานเก่าๆ จะไปทำงานต่อจนจบในระบบใหม่ได้ คุณต้องเคลียร์งาน (drain) ใน Bull queue เดิมให้หมดก่อนที่จะเริ่มรัน BullMQ workers บน Redis instance เดียวกัน มิฉะนั้น คุณอาจเสี่ยงต่อการที่รูปแบบข้อมูลสองแบบที่ต่างกันจะเกิดการชนกัน (collide) ใน keyspace เดียวกัน ควรวางแผนช่วงเวลาปิดปรับปรุง (maintenance window) หรือการทำ blue-green cutover มันต้องใช้ความพยายามอย่างจริงจัง และความพยายามนั้นต้องคุ้มค่ากับสิ่งที่ได้รับ
ควรเลือกทางไหนดี
หากการตั้งค่า Bull ปัจจุบันของคุณยังทำงานได้ราบรื่นดีโดยไม่มีปัญหา ก็ปล่อยมันไว้แบบนั้นเถอะ ความเสถียรนั้นมีค่า Background queue คือโครงสร้างพื้นฐาน ไม่ใช่เครื่องประดับตามแฟชั่น แต่ถ้าทีมของคุณกำลังประสบปัญหาด้านสถาปัตยกรรม เพราะต้องการใช้งาน parent-child workflows หรือการจำกัด rate limit แบบ per-tenant อย่างเร่งด่วน การย้ายระบบก็ถือว่าสมเหตุสมผล การแยกส่วนความรับผิดชอบ (separation of concerns) ที่ชัดเจนกว่าและ API ที่ทันสมัยกว่า จะช่วยตอบแทนความพยายามที่คุณลงไปในระยะยาว
สำหรับโปรเจกต์ใหม่ การตัดสินใจนั้นง่ายกว่ามาก เริ่มต้นด้วย BullMQ เลย เพราะมีการอัปเดตอย่างสม่ำเสมอ รองรับมาตรฐาน JavaScript ปัจจุบันได้ทันที และให้พื้นที่ในการสร้าง job flows ที่ซับซ้อนได้โดยไม่ต้องกังวลว่า library จะรองรับไม่ไหวภายในหกเดือน คุณจะได้ไม่ต้องสร้างหนี้ทางเทคนิค (technical debt) บน API ที่ผู้ดูแลได้ก้าวข้ามไปแล้ว
บทสรุปที่แท้จริง
Job queue มีไว้เพื่อให้ HTTP response ของคุณทำงานได้รวดเร็วและทำให้ผู้ใช้งานไม่ต้องรอนาน Bull ยังคงทำหน้าที่นั้นได้อย่างยอดเยี่ยม ส่วน BullMQ ทำหน้าที่นั้นด้วยโครงสร้างที่สอดคล้องกับวิธีการสร้างและขยายขนาด (scale) ของแอปพลิเคชัน Node.js สมัยใหม่ คำถามไม่ใช่ว่า library ไหนดีกว่ากันหากพิจารณาแยกกันโดดๆ แต่มันคือคำถามที่ว่า ความลำบากที่คุณเจออยู่ในปัจจุบันนั้นคุ้มค่ากับการย้ายระบบหรือไม่ และโปรเจกต์ถัดไปของคุณควรค่าแก่การมีรากฐานที่จะไม่ต้องถูกเปลี่ยนใหม่ก่อนการระดมทุนรอบหน้าหรือการเปิดตัวผลิตภัณฑ์หรือไม่