FlowSynx เครื่องมือจัดการเวิร์กโฟลว์ใหม่ที่พัฒนาด้วย .NET ได้เปิดตัวพร้อมสัญญาว่าจะมีระบบอัตโนมัติแบบ declarative และสถาปัตยกรรมที่ขับเคลื่อนด้วย plugin อย่างไรก็ตาม โปรเจกต์นี้กำลังเผชิญกับการต่อต้านจากนักพัฒนาที่ตั้งคำถามเกี่ยวกับการเลือกใช้การออกแบบและเสนอความกังวลด้านความปลอดภัยเกี่ยวกับการนำไปใช้งาน
การกำหนดค่า JSON ทำให้นักพัฒนาสงสัย
การวิพากษ์วิจารณ์ที่โดดเด่นที่สุดมุ่งเน้นไปที่การตัดสินใจของ FlowSynx ในการใช้ไฟล์ JSON สำหรับการกำหนดค่าเวิร์กโฟลว์ นักพัฒนาหลายคนได้แสดงความไม่พอใจต่อแนวทางนี้ โดยตั้งคำถามว่าใครคือกลุ่มเป้าหมายที่แท้จริง ความกังวลเกิดขึ้นจากข้อเท็จจริงที่ว่านักพัฒนามักจะชอบทำงานกับภาษาโปรแกรมมิ่งที่คุ้นเคย เช่น C# ในขณะที่ผู้ใช้ทางธุรกิจและ data engineer มักต้องการอินเทอร์เฟซแบบกราฟิกสำหรับการออกแบบเวิร์กโฟลว์
ปฏิกิริยาของนักพัฒนาคนหนึ่งค่อนข้างน่าสนใจ โดยอธิบายว่าพวกเขาเสียความสนใจทันทีหลังจากเห็นตัวอย่างที่เต็มไปด้วย JSON สิ่งนี้เน้นย้ำถึงความท้าทายพื้นฐานในเครื่องมือจัดการเวิร์กโฟลว์ - การหาสมดุลที่เหมาะสมระหว่างความยืดหยุ่นทางเทคนิคและการออกแบบที่เป็นมิตรกับผู้ใช้
ข้อกังวลของนักพัฒนาที่ระบุได้:
- การกำหนดค่า JSON แทนที่จะเป็นโค้ด C หรือส่วนติดต่อแบบกราฟิก
- ข้อมูลลับแบบข้อความธรรมดาในตัวอย่าง workflows
- รูปแบบการกำหนดค่า .NET ที่ไม่ได้มาตรฐาน
- ปัญหาคุณภาพเอกสารและข้อผิดพลาดในการพิมพ์
- การกำหนดตำแหน่งกลุ่มเป้าหมายที่ไม่ชัดเจน
- การแข่งขันกับเครื่องมือที่มีอยู่แล้วเช่น Workflow Core
ช่องโหว่ด้านความปลอดภัยในโค้ดตัวอย่าง
ความกังวลด้านความปลอดภัยที่สำคัญเกิดขึ้นเมื่อสมาชิกชุมชนค้นพบข้อมูลลับแบบ plain text ในเวิร์กโฟลว์ตัวอย่างของโปรเจกต์ ตัวอย่างแสดงข้อมูลที่ละเอียดอ่อน เช่น รหัสผ่านและ API key ที่เก็บไว้โดยตรงในไฟล์กำหนดค่า JSON ซึ่งขัดต่อแนวปฏิบัติด้านความปลอดภัยพื้นฐาน แม้ว่าผู้สนับสนุนบางคนจะโต้แย้งว่าระบบกำหนดค่าของ .NET อนุญาตให้ override ด้วย environment variable ในการใช้งานจริง แต่นักวิจารณ์ชี้ให้เห็นว่าโครงสร้าง JSON นี้ดูเหมือนจะไม่ปฏิบัติตามรูปแบบการกำหนดค่า .NET มาตรฐาน
สิ่งนี้ดูไม่เหมือนการกำหนดค่า .net มาตรฐาน (appsettings.json) สำหรับฉัน มันดูเหมือน json serialization แบบง่าย ๆ ของ object มากกว่า
ปัญหาความปลอดภัยกลายเป็นเรื่องที่มีปัญหามากขึ้นเพราะ workflow object เหล่านี้มีแนวโน้มที่จะถูกจัดการเป็นส่วนหนึ่งของโครงสร้างข้อมูลที่ใหญ่กว่า ทำให้ยากต่อการนำการจัดการข้อมูลลับที่เหมาะสมมาใช้โดยใช้ configuration builder ในตัวของ .NET
การวางตำแหน่งเทียบกับเครื่องมือที่มีชื่อเสียง
FlowSynx วางตำแหน่งตัวเองเป็นทางเลือกแทนเครื่องมือจัดการเวิร์กโฟลว์ยอดนิยม เช่น Apache Airflow แต่สำหรับระบบนิเวศ .NET โปรเจกต์เน้นย้ำถึงสถาปัตยกรรม plugin-first และความสามารถข้ามแพลตฟอร์ม อย่างไรก็ตาม สมาชิกชุมชนบางคนได้สังเกตว่าโซลูชัน .NET ที่มีอยู่แล้ว เช่น Workflow Core ให้ฟังก์ชันการทำงานที่คล้ายกับ Airflow อยู่แล้ว
การออกแบบ micro-kernel ของโปรเจกต์และการเน้นย้ำความเป็นโมดูลาร์แสดงให้เห็นความหวังสำหรับสถานการณ์องค์กรที่การปรับแต่งเป็นสิ่งสำคัญ ฟีเจอร์ต่าง ๆ เช่น การอนุมัติ Human-in-the-Loop และกลยุทธ์การจัดการข้อผิดพลาดที่ยืดหยุ่น แสดงให้เห็นการพิจารณาอย่างรอบคอบของความต้องการเวิร์กโฟลว์ในโลกแห่งความเป็นจริง
คุณสมบัติหลักของ FlowSynx :
- ความสามารถในการขยายแบบปลั๊กอินด้วยสถาปัตยกรรม micro-kernel
- การทำงานข้ามแพลตฟอร์ม ( Windows , Linux , macOS )
- รองรับการทำ containerization ด้วย Docker
- การกำหนด workflow แบบ DAG โดยใช้ JSON หรือ DSL
- อินเทอร์เฟซ CLI , SDK , REST API และ Web UI
- รองรับการยืนยันตัวตน ( OAuth2 , OpenID Connect )
- ความสามารถในการอนุมัติแบบ Human-in-the-Loop
- การจัดการข้อผิดพลาดที่ปรับแต่งได้พร้อมกลยุทธ์การลองใหม่
ปัญหาเอกสารและการขัดเกลา
นอกเหนือจากความกังวลเกี่ยวกับฟังก์ชันการทำงานหลักแล้ว ผู้ใช้ได้ระบุปัญหาคุณภาพพื้นฐาน รวมถึงข้อผิดพลาดในการพิมพ์ในเอกสาร ปัญหาที่ดูเหมือนเล็กน้อยเหล่านี้มีส่วนทำให้เกิดความประทับใจโดยรวมว่าโปรเจกต์อาจถูกเร่งออกสู่ตลาดโดยไม่ได้ให้ความสนใจกับรายละเอียดอย่างเพียงพอ
การรวมกันของความกังวลด้านความปลอดภัย การเลือกใช้การออกแบบที่น่าสงสัย และปัญหาเอกสาร ชี้ให้เห็นว่า FlowSynx อาจต้องการการปรับปรุงอย่างมีนัยสำคัญก่อนที่จะสามารถแข่งขันได้อย่างมีประสิทธิภาพกับโซลูชันการจัดการเวิร์กโฟลว์ที่มีชื่อเสียง แม้ว่าสถาปัตยกรรมพื้นฐานจะแสดงศักยภาพ แต่การแก้ไขความกังวลของนักพัฒนาเกี่ยวกับการใช้งานและความปลอดภัยจะเป็นสิ่งสำคัญสำหรับการได้รับการยอมรับในวงกว้างในชุมชน .NET
อ้างอิง: FlowSynx: Orchestrate Declarative, Plugin-Driven DAG Workflows on .NET