แนวทางการประมวลผลงานใน Elixir ที่มีอายุสิบปีกำลังได้รับความสนใจอีกครั้ง เมื่อนักพัฒนาสำรวจทางเลือกอื่นนอกเหนือจากโซลูชันหลัก การอภิปรายมุ่งเน้นไปที่การสร้าง job runner แบบกำหนดเองโดยใช้ GenStage ซึ่งเป็นเฟรมเวิร์ก producer-consumer ที่มีอยู่แล้วใน Elixir แทนที่จะพึ่พาไลบรารีที่มีชื่อเสียงเพียงอย่างเดียว
การสนทนาเน้นย้ำถึงความท้าทายที่ยังคงอยู่ในระบบนิเวศของ Elixir คือการยอมรับในตลาด แม้จะมีข้อได้เปรียบทางเทคนิค นักพัฒนายังคงเผชิญกับความต่อต้านเมื่อเสนอโซลูชันที่ใช้ Elixir ในสภาพแวดล้อมขององค์กร นักพัฒนาคนหนึ่งแบ่งปันประสบการณ์การสร้างระบบแจ้งเตือน Pub/Sub ที่ใช้ในการผลิตจริงซึ่งทำงานได้สำเร็จมาหลายปี แต่ยังคงเผชิญกับความสงสัยจากลูกค้าที่ชอบเทคโนโลยีแบบดั้งเดิมมากกว่า เช่น Java, .NET, Python หรือ PHP
องค์ประกอบสถาปัตยกรรม GenStage :
- Producer: สร้างข้อความ/งาน (UUIDs ในตัวอย่าง)
- Consumer: ประมวลผลงานที่ดึงมาจาก producers
- Supervisor: จัดการวงจรชีวิตของกระบวนการและการรีสตาร์ท
- Built-in Buffer: เก็บรายการในหน่วยความจำก่อนการประมวลผล
Oban ครองตลาดการใช้งานจริง
ในขณะที่การใช้งาน GenStage แบบกำหนดเองมีคุณค่าในการเรียนรู้ ชุมชนมีแนวโน้มไปทาง Oban อย่างมากสำหรับการใช้งานจริง ไลบรารีประมวลผลงานที่มีชื่อเสียงนี้มีทั้งเวอร์ชันโอเพนซอร์สและเวอร์ชันสำหรับมืออาชีพ โดยเวอร์ชันหลังมีฟีเจอร์ขั้นสูง เช่น workflows, rate limiting และการควบคุม concurrency อย่างไรก็ตาม นักพัฒนาบางคนแสดงความกังวลเกี่ยวกับข้อจำกัดของฟีเจอร์ในเวอร์ชันฟรี โดยเฉพาะเมื่อสร้างโปรเจกต์โอเพนซอร์สที่อาจได้ประโยชน์จากฟีเจอร์ Pro
การอภิปรายเผยให้เห็นความตึงเครียดในทางปฏิบัติระหว่างความครอบคลุมของโซลูชันเชิงพาณิชย์และความยืดหยุ่นของการใช้งานแบบกำหนดเอง ในขณะที่ Oban จัดการกับข้อกำหนดการผลิตส่วนใหญ่ได้อย่างมีประสิทธิภาพ นักพัฒนาที่สนใจในรูปแบบสถาปัตยกรรมเฉพาะหรือแบบฝึกหัดการเรียนรู้พบคุณค่าในการทำความเข้าใจกลไก GenStage ที่เป็นพื้นฐาน
การเปรียบเทียบเวอร์ชัน Oban :
- Open Source: การประมวลผลงานพื้นฐาน การจัดตารางเวลา การจัดการข้อผิดพลาด
- Pro Version: ฟีเจอร์ขั้นสูง รวมถึง workflows การจำกัดอัตรา การควบคุมการทำงานพร้อมกัน และการประสานงานระหว่าง multi-worker
โอกาสการรวม PostgreSQL
ทิศทางการพัฒนาที่น่าสนใจเกิดขึ้นรอบการประมวลผลงานที่ใช้ PostgreSQL นักพัฒนากำลังสำรวจการรวมกับส่วนขยาย PostgreSQL เช่น pgmq และ pg_cron คล้ายกับแนวทางที่ใช้โดย pgflow ทิศทางนี้สอดคล้องกับแนวโน้มที่กว้างขึ้นสู่การประมวลผลงานที่เน้นฐานข้อมูล โดยใช้ประโยชน์จากฟีเจอร์ขั้นสูงของ PostgreSQL สำหรับการจัดการคิวและการกำหนดเวลา
ผมอยากเห็นหนึ่งตัวสำหรับ Elixir ที่สร้างรอบส่วนขยาย Postgres pgmq และ pg_cron คล้ายกับสิ่งที่ pgflow กำลังทำ
แนวทาง PostgreSQL มีข้อได้เปรียบที่เป็นไปได้ในสภาพแวดล้อมที่ลงทุนอย่างหนักในโครงสร้างพื้นฐาน PostgreSQL อยู่แล้ว โดยเฉพาะที่ใช้ฟีเจอร์ realtime ของ Supabase ซึ่งขับเคลื่อนโดย Elixir และตรวจสอบ Write-Ahead Log ของ PostgreSQL
ตัวเลือกการผสานรวม PostgreSQL:
- ส่วนขยาย pgmq: ฟังก์ชันการทำงานของคิวข้อความ
- ส่วนขยาย pg_cron: ความสามารถในการจัดตารางเวลา
- แนวทาง pgflow: การประมวลผลงานที่เน้นฐานข้อมูลเป็นศูนย์กลาง
- FOR UPDATE SKIP LOCKED: การประมวลผลงานพร้อมกันด้วยการล็อกระดับแถว
คุณค่าทางการศึกษาและความเสถียรของโค้ดระยะยาว
การทบทวนโค้ด GenStage ที่มีอายุสิบปีแสดงให้เห็นความเสถียรของ Elixir และความเกี่ยวข้องที่ยั่งยืนของโมเดล concurrency ของมัน นักพัฒนาสังเกตว่าการใช้งานต้นฉบับยังคงใช้ได้ดีตลอดเวลา ซึ่งบ่งบอกว่ารูปแบบพื้นฐานของ Elixir ยังคงแข็งแกร่งและบำรุงรักษาได้ ความเสถียรนี้ตรงข้ามกับวิวัฒนาการอย่างรวดเร็วที่เห็นในสแต็กเทคโนโลยีอื่น ๆ หลายตัว
แง่มุมการศึกษาสะท้อนเป็นพิเศษกับนักพัฒนาที่เรียนรู้ความสามารถในการคำนวณแบบกระจายของ Elixir ความสามารถในการสร้างระบบประมวลผลงานที่ซับซ้อนด้วยโค้ดที่ค่อนข้างตรงไปตรงมาแสดงให้เห็นจุดแข็งของ Elixir ในแอปพลิเคชันแบบ concurrent และ distributed
การอภิปรายที่ดำเนินต่อไปสะท้อนธีมที่กว้างขึ้นในชุมชน Elixir ความเป็นเลิศทางเทคนิคควบคู่กับความท้าทายในการยอมรับ ความสมดุลระหว่างโซลูชันแบบกำหนดเองและไลบรารีที่มีชื่อเสียง และวิวัฒนาการอย่างต่อเนื่องของรูปแบบการรวม PostgreSQL เมื่อนักพัฒนายังคงสำรวจแนวทางเหล่านี้ การผสมผสานระหว่างความเสถียรที่พิสูจน์แล้วและข้อกำหนดสมัยใหม่ยังคงขับเคลื่อนนวัตกรรมในโซลูชันการประมวลผลงาน Elixir
อ้างอิง: Writing A Job Runner (in Elixir) (Again) (10 years later)