กองธุรกรรมสมัยใหม่

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

อันที่จริงแล้ว ฐานข้อมูลธุรกรรม (โดยทั่วไปเรียกว่า OLTP — ย่อมาจากการประมวลผลธุรกรรมออนไลน์ — ฐานข้อมูล) เป็นศูนย์กลางของการพัฒนาแอปพลิเคชัน ซึ่งเมื่อเวลาผ่านไป ฐานข้อมูลจะใช้ฟังก์ชันของแอปพลิเคชันมากขึ้นเรื่อยๆ อย่างไรก็ตาม ไมโครเซอร์วิสและสถาปัตยกรรมแอปพลิเคชันสมัยใหม่อื่นๆ ได้นำความซับซ้อนใหม่ๆ มาใช้ในการออกแบบแอปพลิเคชัน: นักพัฒนาจำเป็นต้องจัดการข้อมูลในบริการต่างๆ และรับประกันความสอดคล้องระหว่างบริการเหล่านั้น ซึ่งบังคับให้พวกเขาสร้างกลไกการซิงโครไนซ์ข้อมูลและการประมวลผลที่ซับซ้อนภายในองค์กร 

ดังนั้น ในฐานะที่เป็นอุตสาหกรรม เราเห็นการรับรู้ที่เพิ่มขึ้นว่าการรับประกันการทำธุรกรรมเป็นสิ่งที่จำเป็นนอกเหนือไปจากรูปแบบเดิม เรากำลังเห็น การเกิดขึ้นของระบบที่ขยายการรับประกันการทำธุรกรรมที่แข็งแกร่งนอกเหนือจากฐานข้อมูลไปยังแอพที่กระจายอยู่. 

เราได้ติดตามโซลูชันเหล่านี้ในช่วงไม่กี่ปีที่ผ่านมา โดยทั่วไปแล้ว พวกเขามุ่งมั่นที่จะอนุญาตให้มีการจัดการธุรกรรมของรัฐในแอปแบบกระจายขนาดใหญ่ โดยไม่ต้องสร้างความท้าทายในการปรับขนาดและในขณะเดียวกันก็จัดเตรียมสภาพแวดล้อมการเขียนโปรแกรมที่ทันสมัย 

เราพบว่าโซลูชันเหล่านี้แบ่งออกเป็นสองประเภทอย่างคร่าว ๆ ประเภทหนึ่งคือ การจัดเวิร์กโฟลว์. สิ่งนี้รับประกันโดยทั่วไปว่าบล็อกของโค้ดจะทำงานจนเสร็จ แม้ว่าจะเผชิญกับความล้มเหลวก็ตาม ดังนั้นจึงสามารถใช้เพื่อวัตถุประสงค์ในการจัดการเครื่องสถานะแบบกระจายตามที่กำหนดโดยปราศจากความสับสน ประเภทที่สองคือ ฐานข้อมูล + เวิร์กโฟลว์ซึ่งขยายการออกแบบฐานข้อมูล OLTP แบบดั้งเดิม ทำให้สามารถใช้รหัสตามอำเภอใจเพื่อวัตถุประสงค์เดียวกันได้ 

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

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

การทำธุรกรรม การรับประกัน และแอพที่ทันสมัย 

เวอร์ชันคร่าวๆ คือ: มีชุดของงาน — ธุรกรรม — ที่คุณต้องการทำทั้งหมดหรือไม่ทำเลย สิ่งใดก็ตามที่อยู่ระหว่าง (ทำไปแล้วบางส่วน) จะจบลงในสถานะที่เสียหาย รับประกันยากครับ สิ่งใด ในระบบกระจาย แต่ฐานข้อมูลทำได้ดีกับการทำธุรกรรม ดังนั้นวิธีที่ง่ายที่สุดในการจัดการกับการรับประกันในหลาย ๆ ระบบคือการทำธุรกรรมส่วนใหญ่และปล่อยให้ฐานข้อมูลจัดการ

แอพสมัยใหม่เป็นระบบกระจายขนาดใหญ่ที่มีผู้ใช้จำนวนมากทำสิ่งต่างๆ มากมาย ดังนั้นแม้การรักษาสถานะแอปให้สอดคล้องกัน (เช่น การติดตามว่าผู้ใช้รายใดอยู่ในขั้นตอนการชำระเงิน) ก็กลายเป็นปัญหาการทำธุรกรรมแบบกระจาย ในสถาปัตยกรรมเสาหินแบบดั้งเดิม การจัดการธุรกรรมโดยใช้ SQL กับฐานข้อมูล OLTP ค่อนข้างมีประสิทธิภาพ แต่ในโลกใหม่ที่ซับซ้อนของไมโครเซอร์วิสที่มีการโต้ตอบผ่าน API ระดับสูงกว่า (เช่น REST หรือ gRPC) ความต้องการในการทำธุรกรรมได้กระจายไปโดยธรรมชาติ 

อย่างไรก็ตาม หลายบริษัทที่มุ่งสู่ไมโครเซอร์วิสยังไม่ได้ทำอะไรมากนักเพื่อขยายการรับประกันการทำธุรกรรมที่แข็งแกร่งนอกเหนือจากฐานข้อมูล และในทางปฏิบัติก็คือ เกือบตลอดเวลา ตกลง. แต่เมื่อแอปพลิเคชันขยายขนาด ความไม่สอดคล้องกันของข้อมูลก็เพิ่มขึ้น เช่นเดียวกับข้อผิดพลาดที่ตามมาและข้อผิดพลาดที่ไม่ได้กระทบยอดในข้อมูลทางธุรกิจ ซึ่งแน่นอนว่าอาจเป็นปัญหาอย่างมาก สิ่งนี้บังคับให้นักพัฒนาแอปพลิเคชันต้องรับมือกับสถานการณ์ความล้มเหลวและกลยุทธ์การแก้ไขข้อขัดแย้งในวงกว้าง และเพื่อให้มั่นใจถึงความสอดคล้องของสถานะด้วยการสร้างกลยุทธ์ของตนเองผ่านรูปแบบสถาปัตยกรรมที่แตกต่างกัน

คำจำกัดความ ข้อมูลธุรกิจ (“ข้อมูล”) หมายถึงข้อมูลที่มีความสำคัญต่อธุรกิจซึ่งโดยปกติจะจัดเก็บไว้ในฐานข้อมูล OLTP เพื่อการคงอยู่และการประมวลผล (เช่น ข้อมูลโปรไฟล์ผู้ใช้ เช่น ชื่อ ที่อยู่ คะแนนเครดิต เป็นต้น) สถานะแอปพลิเคชัน หมายถึงสถานะปัจจุบันของระบบ สถานะของแอปพลิเคชันถูกกำหนดโดยค่าที่จัดเก็บไว้ในระบบจัดเก็บข้อมูล และขั้นตอนใดที่โปรแกรมดำเนินการอยู่ในเครื่องสถานะจำกัด (เช่น สถานะของคำสั่งซื้อ เช่น "ได้รับคำสั่งซื้อแล้ว" "ตรวจสอบสินค้าคงคลัง" "ตรวจสอบเครดิตแล้ว ,” “ส่งแล้ว”, “ส่งคืน”). ตรรกะทางธุรกิจ หมายถึงส่วนของโปรแกรมที่เกี่ยวข้องกับวิธีการทำงานของแอปพลิเคชันจริงหรือสิ่งที่แอปพลิเคชันทำ แทนที่จะเป็นรายละเอียดการดำเนินการ (เช่น “หาก user_income > $100K & credit_score >650 ⇒ allocation_approved = TRUE”)

สำหรับวัตถุประสงค์ของการสนทนานี้ สิ่งสำคัญคือต้องแยกแยะสถานะของแอปพลิเคชันและข้อมูลทางธุรกิจ ตัวอย่างเช่น การทราบว่าลูกค้าป้อนบัตรเครดิตแต่ยังไม่ได้ชำระเงินถือเป็นสถานะการสมัคร ข้อมูลสำหรับบัตรเครดิตและรายการในตะกร้าแอปพลิเคชันเป็นข้อมูลทางธุรกิจ 

ในโฟลว์ทั่วไป คำขอจะมาจากส่วนหน้า ได้รับการตรวจสอบสิทธิ์ จากนั้นจะถูกส่งผ่านเกตเวย์ API หรือ GraphQL ไปยังจุดสิ้นสุดที่เกี่ยวข้อง 

ขณะนี้จุดสิ้นสุด API เดียวนั้นต้องประสานไมโครเซอร์วิสนับสิบหรือร้อยเพื่อส่งมอบธุรกรรมทางธุรกิจให้กับลูกค้าปลายทาง นี่คือที่ที่นักพัฒนามักจะรวมทุกอย่างไว้ในบล็อกลอจิกทางธุรกิจ จากนั้นใช้การรวมกันของคิว แคช และกลไกการลองใหม่ด้วยรหัสด้วยมือเพื่อรับข้อมูลไปยังฐานข้อมูล ซึ่งหวังว่าจะเป็นการทำธุรกรรมเต็มรูปแบบ

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

การเพิ่มขึ้นของสแต็คทรานแซคชันที่เน้นเวิร์กโฟลว์เป็นศูนย์กลางและฐานข้อมูลเป็นศูนย์กลาง

ตกลง ดังนั้นธุรกรรมจึงมีความสำคัญ LAMP บนฐานข้อมูลไม่เพียงพอสำหรับขนาด และก้อนขนขนาดใหญ่ของคิวและการลองใหม่ก็เปราะบางเกินไป เพื่อจัดการกับสิ่งนี้ ในช่วงไม่กี่ปีที่ผ่านมา เราได้เห็นการเกิดขึ้นของโซลูชันใหม่ๆ ที่นำหลักเหตุผลกลับมาสู่ตรรกะของธุรกรรม สามารถจัดประเภทคร่าวๆ ได้ว่าเป็นวิธีการที่เน้นเวิร์กโฟลว์เป็นศูนย์กลางหรือวิธีการที่เน้นฐานข้อมูลเป็นศูนย์กลาง

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

ไดอะแกรมด้านล่างแสดงภาพร่างคร่าวๆ ของวิธีการใช้แนวทางเวิร์กโฟลว์และ/หรือฐานข้อมูลเป็นศูนย์กลางในแอปพลิเคชัน Javascript/Typescript โดยสมมติว่ามีการใช้งานทั้งสองอย่าง แม้ว่าพวกเขาจะเป็นชิ้นส่วนที่แตกต่างของสถาปัตยกรรมนี้ในปัจจุบัน แต่เราได้เห็นสัญญาณเริ่มต้นของแนวโน้มที่ฐานข้อมูลรวมคุณสมบัติเวิร์กโฟลว์ และเวิร์กโฟลว์เริ่มใช้พื้นที่เก็บข้อมูลที่ทนทาน การผสานความสามารถนี้บ่งชี้ว่าเส้นแบ่งระหว่างสองวิธีนั้นพร่ามัวและแตกต่างน้อยลงในสถาปัตยกรรมสมัยใหม่ 

รายละเอียดวิธีการที่เน้นเวิร์กโฟลว์เป็นศูนย์กลาง 

เวิร์กโฟลว์เป็นเพียงบล็อกของโค้ดที่ดำเนินการตามเหตุการณ์หรือตัวจับเวลาที่พัฒนาเครื่องสถานะของแอปพลิเคชัน เวิร์กโฟลว์การทำธุรกรรมช่วยให้มั่นใจถึงการเรียกใช้โค้ดด้วยการรับประกันที่รัดกุม ป้องกันสถานะบางส่วนหรือที่ไม่ได้ตั้งใจในแอปพลิเคชัน นักพัฒนาเขียนตรรกะ และเอ็นจินเวิร์กโฟลว์จะจัดการธุรกรรม การกลายพันธุ์ และการกลายพันธุ์ เอ็นจิ้นเวิร์กโฟลว์ที่แตกต่างกันทำให้เกิดการแลกเปลี่ยนที่แตกต่างกันในแง่ของจำนวนรายละเอียดธุรกรรมที่นักพัฒนาเปิดเผย 

ดังตัวอย่าง ด้านล่างนี้คือการแสดงภาพเวิร์กโฟลว์การเช็คเอาท์ที่ทำงานบน Orkes (Conductor): 

มี สองแนวทางคร่าวๆ โดยกลไกเวิร์กโฟลว์ได้รับแรงฉุด ในหนึ่งเดียว (พิมพ์โดย Temporal.io) นักพัฒนาเขียนโค้ดโดยใช้ภาษาโปรแกรมแบ็คเอนด์มาตรฐาน (เช่น Go หรือ Java) และ ระบบจะทำให้แน่ใจว่ารหัสทำงานจนจบแม้ในยามที่ล้มเหลว ในโมเดลนี้ สแต็กการเรียกใช้โปรแกรมจะยังคงอยู่แม้ว่าโค้ดจะรอให้การเรียกบล็อกดำเนินการให้เสร็จสิ้น (เช่น อ่านหรือเขียน) ในการดำเนินการนี้ รันไทม์ของภาษาจะถูกปรับเปลี่ยนเพื่อป้องกันการเรียกใช้รหัสบางส่วนในระหว่างที่ล้มเหลว ข้อดีของวิธีนี้คือนักพัฒนาสามารถเขียนด้วยภาษาที่คุ้นเคยและแก้ไขจุดบกพร่องได้อย่างง่ายดายด้วย call stack ที่คงไว้ เราเห็นวิธีการนี้เป็นที่นิยมมากที่สุดกับทีมแบ็คเอนด์ที่เกี่ยวข้องกับแอพขนาดใหญ่และซับซ้อน 

ข้อเสียคือมักต้องใช้การรวมระบบและรหัส wrapper จำนวนมากเพื่อแสดงอินเทอร์เฟซที่มีประโยชน์และปลอดภัยต่อนักพัฒนาแอปพลิเคชัน ข้อเสียอีกประการหนึ่งคือมันต้องใช้เลเยอร์การประมวลผลแบบกำหนดเองแทนที่จะใช้ภาษาเปล่า และมีกรณีขอบที่การดำเนินการจะแตกต่างจากรันไทม์ของภาษาดั้งเดิม ดังนั้น ในขณะที่นักพัฒนาสามารถใช้ภาษาที่พวกเขาคุ้นเคย พวกเขายังต้องเข้าใจว่าระบบพื้นฐานนั้นทำงานอย่างไร  

อีกวิธีหนึ่งซึ่งเป็นที่นิยมมากกว่าสำหรับนักพัฒนาแอปพลิเคชัน (โดยเฉพาะ Typescript/Javascript) คือสำหรับกลไกเวิร์กโฟลว์ในการ ทำหน้าที่เป็นผู้จัดเตรียมฟังก์ชัน async (เช่น Ingest, Defer และ Trigger) ในโมเดลนี้ เหตุการณ์หรือฟังก์ชันของบุคคลที่สามจะถูกส่งตรงไปยังกลไกเวิร์กโฟลว์ ซึ่งจะส่งลอจิกที่ลงทะเบียนโดยโปรแกรมเมอร์แอปพลิเคชัน ซึ่งจะต้องคืนการควบคุมเมื่อจำเป็นต้องบล็อกฟังก์ชัน async อื่น ข้อดีคือนี่เป็นวิธีการรวมเข้ากับโปรแกรมที่มีน้ำหนักเบากว่ามาก นอกจากนี้ยังบังคับให้มีโครงสร้างเพียงพอในโค้ดที่ทีมที่ทำงานอยู่สามารถเข้าใจได้ง่ายขึ้น อย่างไรก็ตาม วิธีการนี้อาจแก้ไขจุดบกพร่องได้ยากขึ้นหากไม่มีการสนับสนุนด้านเครื่องมือ ดังนั้นการแก้ไขจุดบกพร่องจึงมีแนวโน้มที่จะเป็นเฉพาะแพลตฟอร์ม

เอ็นจิ้นเวิร์กโฟลว์มีประสิทธิภาพเป็นพิเศษโดยอนุญาตให้แอปที่มีอยู่ค่อยๆ ปรับใช้ สามารถนำไปใช้ทีละน้อยกับเวิร์กโฟลว์บางอย่างโดยใช้พื้นที่น้อยที่สุด ที่กล่าวว่าข้อบกพร่องที่ใหญ่ที่สุดสองประการของเอ็นจิ้นเวิร์กโฟลว์เกิดจากการที่พวกมันไม่ได้ขยายเข้าไปในฐานข้อมูล ด้วยเหตุนี้ จึงไม่มีแหล่งข้อมูลเดียวที่สามารถสืบค้นได้ทั่วทั้งสถานะแอปพลิเคชันและข้อมูลทางธุรกิจ นอกจากนี้ ความหมายของทรานแซกชันโดยทั่วไปจะแตกต่างจากความหมายของฐานข้อมูล ทำให้นักพัฒนาแอปพลิเคชันต้องจัดการกับเงื่อนไขขอบ 

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

รายละเอียดวิธีการที่เน้นฐานข้อมูลเป็นศูนย์กลาง 

แนวทางที่เน้นฐานข้อมูลเริ่มต้นด้วยฐานข้อมูล แต่ขยายเพื่อรองรับการเรียกใช้รหัสตามอำเภอใจเพื่อให้เวิร์กโฟลว์ควบคู่ไปกับการจัดการข้อมูล พวกเขาทำสิ่งนี้โดยมอบการควบคุมให้กับโปรแกรมเมอร์ ดังนั้นพวกเขาสามารถทำการตัดสินใจที่ชัดเจนเกี่ยวกับการกลายพันธุ์ ธุรกรรม และความไม่แน่นอนสำหรับการบล็อกโค้ดปกติ โดยหลักแล้วคือการเปิดเผยความหมายของ OLTP โดยตรง โปรแกรมเมอร์มีหน้าที่รับผิดชอบในการรักษาตรรกะทางธุรกิจและข้อมูลทางธุรกิจแยกจากสถานะแอปพลิเคชัน 

แท้จริงแล้วมุมมองฐานข้อมูลล้วนคือสถานะของแอปพลิเคชันสามารถรับมาจากข้อมูลทางธุรกิจได้เสมอ โดยปกติจะทำโดยการจัดเก็บสถานะของแอปพลิเคชันเป็นชุดของธุรกรรมที่แก้ไขข้อมูลทางธุรกิจในฐานข้อมูล ง่ายที่สุดที่จะคิดว่านี่เป็นฐานข้อมูลที่สามารถเรียกใช้บล็อกของโค้ดที่มีการรับประกันที่แข็งแกร่งเช่นเดียวกับระบบเวิร์กโฟลว์ที่อธิบายไว้ข้างต้น 

ภายในเราเรียกสิ่งนี้ว่า แพลตฟอร์มธุรกรรมลอจิกแอปพลิเคชัน (ALTP) เข้าใกล้เพราะท้ายที่สุดแล้วมันจะขยายธุรกรรม OLTP ไปสู่แอปพลิเคชัน แต่สิ่งที่ทำให้ ALTP มีลักษณะเฉพาะจริงๆ ก็คือ สำหรับแอป Greenfield นั้น สามารถกลบเกลื่อนความจำเป็นที่นักพัฒนาแอปต้องจัดการโครงสร้างพื้นฐานส่วนหลังได้โดยตรง  

จากเลนส์ ALTP วิธีการที่ใช้บ่อยที่สุดเริ่มต้นจาก Firebase ซึ่งมี บริการเต็มรูปแบบ“ ประสบการณ์แบ็คเอนด์” รวมถึงการตรวจสอบสิทธิ์ ที่เก็บข้อมูล ฐานข้อมูล และอื่นๆ Firebase และผู้เข้ามาล่าสุด เช่น Supabase ยังคงเป็นแพลตฟอร์มยอดนิยมสำหรับโครงการกรีนฟิลด์ และในขณะที่พวกเขามักจะซื่อสัตย์ต่อรูท OLTP ของพวกเขา — และไม่สนับสนุนการเรียกใช้โค้ดโดยอำเภอใจสำหรับฟังก์ชันแบ็คเอนด์ของทรานแซคชัน — Supabase เริ่มเพิ่มการรองรับสำหรับเวิร์กโฟลว์แล้ว

อย่างไรก็ตาม ข้อเสนอ ALTP รุ่นต่อไป เช่น Convex อนุญาตให้ดำเนินการรหัสโดยอำเภอใจเป็นธุรกรรมควบคู่ไปกับฐานข้อมูล ข้อเสนอเหล่านี้อนุญาตให้เขียนโค้ดที่สอดคล้องกับธุรกรรมทั้งหมดในภาษาปกติ (เช่น Javascript/Typescript) ซึ่งโค้ดบล็อกเดียวสามารถอ่าน เขียน และเปลี่ยนแปลงข้อมูล ทั้งสถานะแอปพลิเคชันและข้อมูลทางธุรกิจ ในแง่หนึ่ง มันทำให้นักพัฒนามีแหล่งความจริงที่สามารถสืบค้นได้แหล่งเดียว และให้เวิร์กโฟลว์พื้นฐาน เช่น การสมัครรับข้อมูล 

ALTP แก้ปัญหาเอ็นจิ้นเวิร์กโฟลว์ที่มีปัญหาในการถูกแยกออกจากฐานข้อมูล แต่ด้วยเหตุนี้ ผู้ใช้จึงต้องพึ่งพาข้อเสนอฐานข้อมูลมากกว่า OLTP มาตรฐานเพื่อให้ได้รับประโยชน์ ด้วยเหตุนี้ เราจึงเห็นทีมใช้ ALTP สำหรับแอป Greenfield เป็นหลัก แทนที่จะรวมเข้ากับแบ็กเอนด์ที่ซับซ้อนที่มีอยู่

แผนภาพด้านบนเป็นการรวมโอเปอเรเตอร์จำนวนมากที่เราพูดคุยด้วย บางคนจะใช้เครื่องมือเวิร์กโฟลว์ บางคนจะใช้วิธีฐานข้อมูลเป็นศูนย์กลาง แต่หลายคนจะใช้ทั้งสองอย่าง — โดยเฉพาะอย่างยิ่งเมื่อพวกเขาเพิ่งเริ่มนำเวิร์กโฟลว์มาใช้ ผู้ใช้เอ็นจิ้นเวิร์กโฟลว์ในปัจจุบันมักจะเป็นทีมแบ็คเอนด์ที่ต้องจัดการกับแอปพลิเคชันขนาดใหญ่และซับซ้อน แม้ว่าเราจะเห็นทีมฟูลสแต็กจำนวนมากนำพวกเขาไปใช้ก็ตาม โซลูชัน Back-end-as-a-service มีแนวโน้มที่จะเป็นมิตรกับนักพัฒนาแอปพลิเคชันมากกว่า และมักจะใช้กันมากกว่าเมื่อแอพขับเคลื่อนการเลือกเทคโนโลยี 

การบรรจบกัน

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

ตัวอย่างเช่น พิจารณากลไกเวิร์กโฟลว์ที่ใช้เพื่อติดตามเครื่องสถานะสำหรับกระบวนการชำระเงินของผู้ใช้ และผู้ใช้รายนั้นกำลังเพิ่มสินค้าลงในรถเข็น โดยทั่วไปแล้ว เอ็นจินเวิร์กโฟลว์ทำให้มั่นใจได้ว่าขั้นตอนโค้ดจะทำงานแม้ในกรณีที่เกิดความล้มเหลว อย่างไรก็ตาม อาจมีบางกรณีที่เครื่องยนต์จำเป็นต้องรันขั้นตอนที่กำหนดอีกครั้งในระหว่างที่เกิดความล้มเหลว เนื่องจากไม่แน่ใจว่าขั้นตอนนั้นเสร็จสมบูรณ์สมบูรณ์หรือไม่ หากขั้นตอนนั้นเกี่ยวข้องกับการเขียนข้อมูลธุรกิจลงในฐานข้อมูลแบบดั้งเดิม (ในกรณีนี้คือรายการในรถเข็น) และฐานข้อมูลไม่ทราบถึงการลองทำซ้ำซ้ำ จะกลายเป็นรายการที่ซ้ำกัน 

มีสองวิธีในการจัดการกับสิ่งนี้ วิธีหนึ่งคือการส่งปัญหาไปยังผู้พัฒนาแอปพลิเคชัน ซึ่งจะใช้ nonce ที่ระบบเวิร์กโฟลว์ให้มาเพื่อให้แน่ใจว่ามีการเขียนเพียงรายการเดียว แต่นั่นถือว่านักพัฒนาเข้าใจถึง idempotency ซึ่งเป็นเรื่องยากที่จะทำให้ถูกต้อง และสิ่งนี้เป็นการลบล้างความมหัศจรรย์ของการมีระบบเวิร์กโฟลว์ อีกวิธีหนึ่งคือการผูกเอ็นจินเวิร์กโฟลว์เข้ากับฐานข้อมูลที่รับรู้ถึงความหมายของทรานแซกชันของเวิร์กโฟลว์ สิ่งนี้ยังไม่เกิดขึ้น แต่ก็ไม่ยากที่จะเชื่อว่าจะเกิดขึ้น 

ในทางกลับกัน แนวทางที่ใช้ฐานข้อมูลเป็นศูนย์กลางตระหนักดีว่าเวิร์กโฟลว์ทั่วไปมีประโยชน์มากสำหรับนักพัฒนาแอปพลิเคชัน ดังนั้นเราจึงเริ่มเห็นฐานข้อมูล (เช่น Convex) ซึ่งสนับสนุนฟังก์ชันฐานข้อมูลแบบดั้งเดิม เช่น เคียวรี การกลายพันธุ์ ดัชนี ฯลฯ ใช้ฟังก์ชันต่างๆ เช่น การตั้งเวลาและการสมัครรับข้อมูล สิ่งเหล่านี้ช่วยให้สามารถใช้เป็นเครื่องมือเวิร์กโฟลว์ได้ นั่นคืออนุญาตให้ดำเนินการบล็อกรหัสโดยอำเภอใจพร้อมการรับประกันที่เข้มงวด 

ดังที่เอียน ลิฟวิงสโตน (ผู้ให้ข้อเสนอแนะเกี่ยวกับงานชิ้นนี้) กล่าวไว้ว่า “เป็นคลาสสิก 'คุณนำตรรกะของแอปพลิเคชันไปยังฐานข้อมูลหรือฐานข้อมูลไปยังตรรกะของแอปพลิเคชันหรือไม่' เล่นอีกครั้ง … คราวนี้เกิดจากการทำลายเสาหิน” มีการแบ่งขั้วกันมานานหลายทศวรรษ เป็นที่ชัดเจนว่าโมเดลทั้งสองจะคงอยู่ต่อไปในระยะสั้น ยังไม่ชัดเจนมากนักว่าจะยังคงเป็นกรณีนี้ในระยะยาว 

ขอขอบคุณเป็นพิเศษสำหรับ Charly Poly (Defer), Dan Farrelly (Innest), David Khourshid (Stately), Ian Livingstone (Cape Security), Enes Akar (Upstash), James Cowling (Convex), Jamie Turner (Convex), Paul Copplestone (Supabase ), Sam Lambert (PlanetScale), Tony Holdstock-Brown (Innest), Matt Aitken (Trigger) สำหรับรีวิวโพสต์นี้และให้ข้อเสนอแนะ นอกจากนี้ ขอขอบคุณ Benjamin Hindman (Reboot), Fredrik Björk (Grafbase), Glauber Costa (Chiselstrike), Guillaume Salles (Liveblocks), Maxim Fateev (Temporal), Steven Fabre (Liveblocks) และ Viren Baraiya (Orkes) ที่ช่วยเราด้วย วิจัย.

• เนื้อหาที่ขับเคลื่อนด้วย SEO และการเผยแพร่ประชาสัมพันธ์ รับการขยายวันนี้
• เพลโตบล็อคเชน Web3 Metaverse ข่าวกรอง ขยายความรู้. เข้าถึงได้ที่นี่.
• การสร้างอนาคตโดย Adryenn Ashley เข้าถึงได้ที่นี่.
• ที่มา: https://a16z.com/2023/04/14/the-modern-transactional-stack/