Sequor เครื่องมือระบบอัตโนมัติเวิร์กโฟลว์ API ตัวใหม่ที่ผสมผสานการกำหนดค่า YAML เข้ากับการประมวลผล SQL ได้ดึงดูดความสนใจจากนักพัฒนา แต่ไม่ใช่เสมอไปในแง่ที่ผู้สร้างหวังไว้ แม้ว่าเครื่องมือนี้จะสัญญาว่าจะทำให้การรวมระบบ API ง่ายขึ้นโดยใช้เทคโนโลยีที่คุ้นเคย แต่การเลือกใช้ไวยากรณ์เทมเพลตของมันได้จุดประกายการถกเถียงอย่างร้อนแรงเกี่ยวกับประสบการณ์นักพัฒนาและหนี้ทางเทคนิค
รูปแบบการรวมระบบของ Sequor
- การรวบรวมข้อมูล: ดึงข้อมูลจากแอปพลิเคชันเข้าสู่คลังข้อมูล
- Reverse ETL: ส่งข้อมูลการวิเคราะห์กลับไปยังระบบปฏิบัติการ
- การเสริมข้อมูล: ปรับปรุงบันทึกข้อมูลด้วยข้อมูลจาก API ของบุคคลที่สาม
- เวิร์กโฟลว์ข้ามแอป: ทำให้กระบวนการทำงานข้ามหลายแอปพลิเคชันเป็นแบบอัตโนมัติ
ปัญหาเทมเพลต YAML
ปัญหาหลักมีจุดศูนย์กลางอยู่ที่การใช้เทมเพลต Jinja2 ของ Sequor ด้วยวงเล็บปีกกาคู่ ({{ }}) ภายในไฟล์ YAML วิธีการนี้ซึ่งใช้โดยเครื่องมือยอดนิยมอย่าง Ansible ด้วย สร้างความท้าทายในการแยกวิเคราะห์อย่างมีนัยสำคัญเพราะวงเล็บปีกกามีความหมายพิเศษใน YAML นักพัฒนาต้องใส่เครื่องหมายคำพูดในนิพจน์เทมเพลตของพวกเขาอย่างต่อเนื่อง ทำให้เกิดไวยากรณ์ที่ยุ่งเหยิงเช่น status: {{ var('order_status') }}
นักพัฒนาที่มีประสบการณ์คนหนึ่งชี้ให้เห็นความรุนแรงของการเลือกออกแบบนี้ โดยสังเกตว่ามันสร้างปัญหาเดียวกันที่ได้รบกวนผู้ใช้ Ansible มานานหลายปี สถานการณ์จะแย่ลงไปอีกเมื่อนิพจน์มีอักขระเครื่องหมายคำพูด ต้องใช้การหลบหนีที่ซับซ้อนซึ่งทำให้โค้ดอ่านและดูแลรักษายาก
Jinja2 เป็นเอนจินเทมเพลต Python ยอดนิยมที่ช่วยให้สร้างเนื้อหาแบบไดนามิกได้โดยใช้เครื่องหมายไวยากรณ์พิเศษ
การเปรียบเทียบไวยากรณ์ Template
- Sequor ปัจจุบัน:
{{ var('order_status') }}(ต้องใช้เครื่องหมายคำพูดใน YAML) - GitHub Actions:
${{ var('order_status') }}(ปลอดภัยสำหรับ YAML) - รูปแบบ ASP.Net:
<%= var('order_status') %>(ปลอดภัยสำหรับ YAML) - รูปแบบ PHP:
<?= var('order_status') ?>(ปลอดภัยสำหรับ YAML)
ทางเลือกอื่นเริ่มปรากฏขึ้น
การถกเถียงเผยให้เห็นทางเลือกอื่นที่สะอาดกว่าหลายแบบที่แพลตฟอร์มอื่นๆ ได้นำมาใช้สำเร็จ GitHub Actions ใช้ไวยากรณ์ ${{ }} ในขณะที่ระบบอื่นๆ ใช้เครื่องหมายอย่าง <%= %> หรือ <?= ?> ที่ไม่ขัดแย้งกับกฎการแยกวิเคราะห์ YAML ทางเลือกเหล่านี้ขจัดความจำเป็นในการใส่เครื่องหมายคำพูดอย่างต่อเนื่องและทำให้ไฟล์กำหนดค่าอ่านง่ายขึ้นมาก
น่าสนใจที่ Sequor ใช้วิธีการที่แตกต่างกันอยู่แล้วสำหรับตรรกะที่ซับซ้อนผ่านนิพจน์ Python ที่มีส่วนต่อท้ายพิเศษ สร้างประสบการณ์ที่ไม่สอดคล้องกันซึ่งผู้ใช้ต้องเรียนรู้ระบบเทมเพลตสองแบบที่แตกต่างกัน วิธีการคู่นี้ทำให้บางคนตั้งคำถามว่าการใช้เทมเพลต Jinja2 จำเป็นหรือไม่
ข้อกังวลเรื่องประสิทธิภาพและความสามารถในการขยายตัว
นอกเหนือจากปัญหาไวยากรณ์แล้ว นักพัฒนายังได้ยกข้อกังวลเชิงปฏิบัติเกี่ยวกับเวิร์กโฟลว์ตัวอย่างของ Sequor การสาธิตของเครื่องมือในการคำนวณเมตริกลูกค้าใหม่ทั่วทั้งชุดข้อมูลจะมีค่าใช้จ่ายสูงมากบนแพลตฟอร์มอย่าง Snowflake ซึ่งต้นทุนการคำนวณสามารถเพิ่มขึ้นอย่างรวดเร็วจนควบคุมไม่ได้
อย่างไรก็ตาม ผู้สร้าง Sequor ตอบสนองต่อข้อเสนอแนะนี้ในเชิงบวก โดยแสดงให้เห็นว่าเวิร์กโฟลว์เดียวกันสามารถปรับให้เหมาะสมสำหรับการประมวลผลแบบเพิ่มหน่วยได้อย่างไร แทนที่จะคำนวณเมตริกสำหรับลูกค้าทั้งหมดใหม่ เวอร์ชันที่ปรับปรุงแล้วจะประมวลผลเฉพาะลูกค้าที่มีการเปลี่ยนแปลงคำสั่งซื้อล่าสุดเท่านั้น ลดต้นทุนการคำนวณลงอย่างมาก
Snowflake เป็นแพลตฟอร์มข้อมูลคลาวด์ที่ผู้ใช้จ่ายตามการใช้งานการคำนวณ ทำให้การสืบค้นที่ไม่มีประสิทธิภาพมีค่าใช้จ่ายสูง
ภาพรวมใหญ่
การถกเถียงเน้นย้ำถึงความท้าทายทั่วไปในเครื่องมือนักพัฒนา: การสร้างสมดุลระหว่างความเรียบง่ายกับความยืดหยุ่น แม้ว่า Sequor จะมุ่งหมายที่จะทำให้การรวมระบบ API เข้าถึงได้สำหรับทีมที่เชี่ยวชาญ SQL โดยไม่ต้องมีความรู้ด้านการเขียนโปรแกรมเชิงลึก แต่ข้อเสนอแนะในช่วงแรกชี้ให้เห็นว่าการตัดสินใจออกแบบพื้นฐานเกี่ยวกับไวยากรณ์และการใช้เทมเพลตอาจส่งผลกระทบอย่างมีนัยสำคัญต่อการยอมรับในระยะยาว
ผู้สร้างได้แสดงความเต็มใจที่จะทำการเปลี่ยนแปลงที่ทำลายความเข้ากันได้ตามข้อเสนอแนะของชุมชน แม้กระทั่งเสนอที่จะเปลี่ยนไปใช้ไวยากรณ์ ${{ }} ที่แนะนำ การตอบสนองต่อข้อกังวลของนักพัฒนานี้อาจพิสูจน์ได้ว่ามีความสำคัญขณะที่เครื่องมือพยายามสร้างตัวเองในตลาดแพลตฟอร์มการรวมระบบที่มีการแข่งขันสูง
การถกเถียงรอบ Sequor สะท้อนคำถามที่กว้างขึ้นเกี่ยวกับวิธีที่เครื่องมือนักพัฒนาใหม่ควรจัดการกับการกำหนดค่าและการใช้เทมเพลต เมื่อแพลตฟอร์มที่ผสมผสานเทคโนโลยีหลายแบบเกิดขึ้นมากขึ้น การตัดสินใจพื้นฐานเหล่านี้ให้ถูกต้องจึงมีความสำคัญมากขึ้นสำหรับความสำเร็จในระยะยาว