เหตุใดผู้คนจึงใช้ REST API แทน DBAL


32

ในอดีตที่ผ่านมาทั้งสอง บริษัท ฉันเคยอยู่ที่ REST API มีอยู่สำหรับการสืบค้นข้อมูลผ่านเว็บแอป กล่าวคือ แทนที่จะมีเว็บแอปทำ SQL โดยตรงจะเรียกใช้ REST API และนั่นคือ SQL และส่งคืนผลลัพธ์

คำถามของฉันคือ ... ทำไมจึงทำเช่นนี้?

ถ้ามันจะถูกเปิดเผยต่อบุคคลที่สามฉันสามารถเข้าใจได้ ดีกว่าที่จะเปิดเผย REST API ที่ จำกัด กว่า DB แบบเต็ม แต่ในทั้งสอง บริษัท นี้ไม่ได้เป็นเช่นนั้น

มีคนแนะนำฉันว่า REST API เหล่านี้ทำให้การสลับระหว่าง DBMS ง่ายขึ้น แต่นั่นไม่ใช่จุดของ abstraction layer ของฐานข้อมูล (DBAL) ใช่ไหม บางทีคุณอาจใช้ ORM เป็น DBAL ของคุณหรือคุณอาจเขียน SQL ดิบและให้ DBAL ของคุณแปลข้อมูลเฉพาะ DB ถ้าเหมาะสม (เช่นแปล LIMIT สำหรับ MySQL เป็น TOP สำหรับ MSSQL)

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


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

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

1
มีนิสัยใจคอกับการออกแบบ REST API ที่ทำให้การออกแบบโดเมนที่ซับซ้อนเป็นเรื่องยาก - นักพัฒนาส่วนใหญ่ที่ฉันพบเจอมานานหลายปีไม่สนใจเรื่องการออกแบบ พวกเขาต้องการปั่นโค้ดให้เร็วที่สุดเพื่อให้หัวหน้าของพวกเขาจะรักพวกเขาและคิดว่าพวกเขาเป็นร็อคสตาร์ เมื่อคุณรวมข้อเท็จจริงนั้นเข้ากับเทรนด์อย่าง REST คุณจะได้รับสปาเก็ตตี้ API ที่ทันสมัย ​​แต่ใช้งานไม่ได้ มันไม่มีส่วนเกี่ยวข้องกับ REST
RibaldEddie

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

1
@gbjbaanb: จุดของฉันคือเว็บเซิร์ฟเวอร์สามารถเข้าถึงข้อมูลผ่านเซิร์ฟเวอร์ส่วนที่เหลือดังนั้นหากเว็บเซิร์ฟเวอร์ถูกแฮ็กผู้โจมตีสามารถเข้าถึงข้อมูลผ่านเซิร์ฟเวอร์ส่วนที่เหลือโดยไม่ต้องแฮกเซิร์ฟเวอร์ที่เหลือ
JacquesB

คำตอบ:


28

หากคุณอนุญาตให้ไคลเอนต์เข้าถึงฐานข้อมูลโดยตรง - ซึ่งทำได้แม้กระทั่งกับเลเยอร์นามธรรมของเลเยอร์นามธรรมแล้ว:

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

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


24

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

เหตุผลที่คุณได้รับคำตอบที่ขัดแย้งกันคือความสับสนเกี่ยวกับ 'ไคลเอนต์' ในสถาปัตยกรรมของคุณ

ในสถาปัตยกรรมของคุณ (ถ้าฉันเข้าใจถูกต้อง) คุณมีเบราว์เซอร์โต้ตอบกับเว็บแอปเดียวซึ่งจะมีการโต้ตอบกับฐานข้อมูล แนะนำเลเยอร์ REST API ระหว่างเว็บแอปและฐานข้อมูลไม่มีประโยชน์ ผลประโยชน์ที่ระบุไว้ทั้งหมด (การแคชการแยกฐานข้อมูลและอื่น ๆ ) สามารถทำได้ด้วย data access layer (s) ในโค้ด

แต่มีสถาปัตยกรรมอื่น ๆที่ REST API เหมาะสม:

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

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

  • หากคุณมีรหัส JavaScript ที่ดึงข้อมูลโดยตรงจากเซิร์ฟเวอร์คุณต้องมี REST API ในทุกกรณี


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

@satich: ฉันไม่เข้าใจว่าสิ่งที่คุณถามคุณจะเฉพาะเจาะจงมากขึ้น? คุณกำลังถามถึงจุดเดียวของความล้มเหลวที่มีหรือไม่มีระดับ REST หรือไม่?
JacquesB

เลเยอร์พิเศษสามารถใช้งานได้หากคุณมีแอปสื่อสารมากกว่าหนึ่งแอป
Ewan

@Ewan: ใช่นี่คือสิ่งที่ฉันพูดในสัญลักษณ์แรก
JacquesB

1
@JacquesB สมมติว่าเว็บแอปหลายตัวใช้ฐานข้อมูลร่วมกัน แต่ไม่ใช่ข้อมูลเดียวกันนั่นคือแต่ละการดำเนินการ CRUD กับชุดข้อมูลแยกต่างหากภายในฐานข้อมูลนั้นโดยทั่วไปจะไม่มีการแบ่งปันข้อมูลในความหมายที่แท้จริง ดังนั้นการวางแอพไว้เบื้องหลังเฟรมเวิร์กการคงอยู่ของ Restful ไม่สมเหตุสมผล (หรือสมมติว่า DB ให้ระดับการทำงานพร้อมกันที่ดีในคิวรี) ยิ่งกว่านั้นเฟรมเวิร์กนั้นจะไม่เป็นคอขวดหรือเป็นจุดเดียวของความล้มเหลวสำหรับแอปพลิเคชันเว็บจำนวนมากที่มีการโต้ตอบผ่านมัน
sactiw

12

คำเตือน: โพสต์ใหญ่ความคิดเห็นบางส่วนคลุมเครือ 'ทำในสิ่งที่ดีที่สุดสำหรับคุณ' ข้อสรุป

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

ความเป็นอิสระของแพลตฟอร์ม & การบำรุงรักษา

หากคุณมีฐานข้อมูลและคุณเขียนไลบรารี Python เพื่อโต้ตอบกับฐานข้อมูลนั้นและทุกคนก็ดึงเข้าไปในห้องสมุดนั้นเพื่อโต้ตอบกับฐานข้อมูลนั่นยอดเยี่ยมมาก แต่สมมุติว่าคุณต้องเขียนแอพมือถือทันใดนั้นแอพมือถือนั้นก็ต้องคุยกับฐานข้อมูลด้วย และวิศวกร iOS ของคุณไม่ใช้ Python และวิศวกร Android ของคุณไม่ใช้ Python บางทีพวก iOS ต้องการใช้ภาษาของ Apple และวิศวกร Android ต้องการใช้ Java ถ้าอย่างนั้นคุณจะเขียนและดูแลรักษา data access library ของคุณใน 3 ภาษา บางที iOS และ Android devs ตัดสินใจที่จะใช้บางอย่างเช่น Xamarin เพื่อเพิ่มรหัสที่พวกเขาสามารถแบ่งปันได้สูงสุด สมบูรณ์แบบยกเว้นคุณอาจจะต้องย้ายพอร์ตไลบรารีการเข้าถึงข้อมูลไปยัง. NET แล้ว บริษัท ของคุณเพิ่งซื้อ บริษัท อื่นที่ ' เว็บแอปพลิเคชั่นเป็นผลิตภัณฑ์ที่แตกต่างกัน แต่เกี่ยวข้องกันและธุรกิจต้องการรวมข้อมูลบางส่วนจากแพลตฟอร์ม บริษัท ของคุณเข้ากับแพลตฟอร์มของ บริษัท ย่อยที่ได้มาใหม่ มีเพียงปัญหาเดียว: บริษัท ย่อยเริ่มต้นแล้วและตัดสินใจที่จะเขียนใบสมัครจำนวนมากใน Dart นอกจากนี้ไม่ว่าจะด้วยเหตุผลใด (เหตุผลที่อาจอยู่นอกเหนือการควบคุมของคุณ) ทีมงานมือถือที่เป็นนักบินของ Xamarin ตัดสินใจว่ามันไม่ได้มีไว้สำหรับพวกเขาและพวกเขาต้องการใช้เครื่องมือและภาษาเฉพาะสำหรับอุปกรณ์พกพาที่พวกเขาจะพัฒนา แต่ในขณะที่คุณอยู่ในช่วงนั้นทีมงานของคุณได้ส่งมอบห้องสมุดการเข้าถึงข้อมูลส่วนใหญ่ของคุณใน. NET และทีมอื่นใน บริษัท กำลังเขียนข้อมูลการรวม Salesforce ที่บ้าคลั่งและตัดสินใจทำสิ่งนั้นใน. NET ตั้งแต่นั้นมา เป็นห้องสมุดการเข้าถึงข้อมูลสำหรับแล้ว

ดังนั้นตอนนี้เนื่องจากเหตุการณ์ที่เกิดขึ้นจริงคุณจึงมีไลบรารีการเข้าถึงข้อมูลของคุณที่เขียนใน Python, .NET, Swift, Java และ Dart พวกเขาไม่ได้ดีอย่างที่คุณต้องการ คุณไม่สามารถใช้ ORM ได้อย่างมีประสิทธิภาพตามที่คุณต้องการเนื่องจากแต่ละภาษามีเครื่องมือ ORM ที่แตกต่างกันดังนั้นคุณต้องเขียนโค้ดเพิ่มเติมมากกว่าที่คุณต้องการ และคุณไม่สามารถอุทิศเวลาให้กับแต่ละชาติได้มากเท่าที่คุณต้องการเพราะมี 5 แห่ง และห้องสมุดรุ่น Dart มีขนดกโดยเฉพาะอย่างยิ่งเพราะคุณต้องทำสิ่งที่ทำธุรกรรมของคุณเองสำหรับห้องสมุดเพราะห้องสมุดและการสนับสนุนไม่ได้อยู่ที่นั่นจริงๆ คุณพยายามทำกรณีที่เป็นเช่นนี้แอปพลิเคชัน Dart ควรมีฟังก์ชั่นอ่านอย่างเดียวสำหรับฐานข้อมูลของคุณ แต่ธุรกิจได้ตัดสินใจแล้วว่าคุณสมบัติใด ๆ ที่พวกเขาวางแผนไว้นั้นคุ้มค่ากับความพยายามพิเศษ และปรากฎว่ามีข้อผิดพลาดในตรรกะการตรวจสอบความถูกต้องบางอย่างที่มีอยู่ในสาขาทั้งหมดของไลบรารีการเข้าถึงข้อมูลของคุณ ตอนนี้คุณต้องเขียนการทดสอบและรหัสเพื่อแก้ไขข้อผิดพลาดนี้ในไลบรารีทั้งหมดเหล่านี้รับการตรวจสอบโค้ดสำหรับการเปลี่ยนแปลงทั้งหมดของไลบรารีเหล่านี้รับ QA ในไลบรารีทั้งหมดเหล่านี้และเผยแพร่การเปลี่ยนแปลงของคุณไปยังระบบทั้งหมดโดยใช้ ห้องสมุดเหล่านี้ ในขณะเดียวกันลูกค้าของคุณก็ไม่พอใจและถูกพาไปที่ Twitter โดยรวมกลุ่มของความหยาบคายที่คุณไม่เคยคาดคิดมาก่อนและสามารถตั้งเป้าหมายไว้ที่ผลิตภัณฑ์เรือธงของ บริษัท ของคุณ และเจ้าของผลิตภัณฑ์ตัดสินใจที่จะไม่เข้าใจเกี่ยวกับสถานการณ์เลย

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

TLDR; ง่ายกว่าในการรวมศูนย์ตรรกะการเข้าถึงข้อมูลและรักษาไคลเอ็นต์ HTTP ที่บางมากกว่าเพื่อกระจายตรรกะการเข้าถึงข้อมูลไปยังแต่ละแอปพลิเคชันที่ต้องการเข้าถึงข้อมูล ในความเป็นจริงไคลเอนต์ HTTP ของคุณอาจถูกสร้างขึ้นจาก meta-data ในระบบขนาดใหญ่ REST API ช่วยให้คุณรักษารหัสน้อยลง

ประสิทธิภาพและความยืดหยุ่น

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

นอกจากนี้เลเยอร์ HTTP ของ REST API ของคุณยังให้กลไกการแคชที่มีค่าอื่น เซิร์ฟเวอร์สำหรับ REST API ของคุณสามารถวางส่วนหัวแคชไว้บนการตอบสนองของพวกเขาและการตอบสนองเหล่านี้สามารถแคชที่เลเยอร์เครือข่ายซึ่งปรับขนาดได้ดีเป็นพิเศษ ในการตั้งค่าขนาดเล็กที่มีเซิร์ฟเวอร์หนึ่งหรือสองเครื่องทางออกที่ดีที่สุดของคุณคือการใช้แคชหน่วยความจำในแอปพลิเคชันเมื่อพูดถึงฐานข้อมูล แต่ในแพลตฟอร์มขนาดใหญ่ที่มีแอปพลิเคชันจำนวนมากที่ทำงานบนเซิร์ฟเวอร์จำนวนมาก เครือข่ายเพื่อจัดการกับแคชของคุณเพราะเมื่อกำหนดค่าบางอย่างเช่น squid หรือ varnish หรือ nginx สามารถปรับขนาดให้อยู่ในระดับบ้าบนฮาร์ดแวร์ที่ค่อนข้างเล็ก คำขอนับร้อยนับพันหรือล้านต่อวินาทีของปริมาณงานมีราคาถูกกว่ามากที่จะทำจากแคช HTTP กว่าจากแอพพลิเคชันเซิร์ฟเวอร์หรือฐานข้อมูล

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

TLDR; ปรับแต่งขนาดและแคชการเข้าถึงข้อมูลของคุณได้ง่ายขึ้นเมื่อมันเป็นสิ่งที่เกิดขึ้นภายในบริการเว็บเดียวโดยเฉพาะเมื่อมันเป็นสิ่งที่เกิดขึ้นในแอพพลิเคชั่นที่หลากหลายโดยใช้ภาษาและเทคโนโลยีที่แตกต่างกัน

ความคิดสุดท้าย

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

นอกจากนี้หาก REST API กำลังได้รับการแก้ไขข้อบกพร่องอาจเป็นไปได้ว่ามีบางอย่างผิดปกติหรือหายไปในภาพนั้น ฉันไม่เชื่อว่าการมีชั้น abstraction ที่เพิ่มเข้ามานั้นทำให้การดีบักนั้นยากขึ้น เมื่อฉันทำงานกับระบบ n-tier ที่มีขนาดใหญ่ฉันต้องการตรวจสอบให้แน่ใจว่าฉันมีบริบทการบันทึกแบบกระจาย บางทีเมื่อผู้ใช้เริ่มต้นคำขอสร้าง GUID สำหรับคำขอนั้นและบันทึกชื่อผู้ใช้ของผู้ใช้นั้นและคำขอที่พวกเขาทำ จากนั้นส่ง GUID นั้นขณะที่แอปพลิเคชันของคุณพูดคุยกับระบบอื่น ด้วยการรวมบันทึกและการจัดทำดัชนีที่เหมาะสมคุณสามารถสืบค้นทั้งแพลตฟอร์มของคุณสำหรับผู้ใช้ที่รายงานปัญหาและมองเห็นการกระทำทั้งหมดของพวกเขาและพวกเขาไหลผ่านระบบเพื่อระบุว่าสิ่งใดผิดพลาดอย่างรวดเร็ว อีกครั้งมันเป็นสถาปัตยกรรมที่ซับซ้อนกว่า

แหล่งที่มา: http://alistair.cockburn.us/Hexagonal+ar Architecture https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing


คำตอบที่ดีมากคุ้มค่าที่จะอ่าน ขอบคุณที่สละเวลาเขียนคำตอบที่ยอดเยี่ยมนี้!
โดมินิ

6

หากฉันเข้าใจอย่างถูกต้องว่า DBAL คืออะไรคำตอบคือส่วนต่อประสาน REST อนุญาตให้คุณใช้ภาษาใดก็ได้สำหรับลูกค้าในขณะที่ DBAL เป็นไลบรารีที่อนุญาตให้คุณใช้ภาษาเดียวกับลูกค้า

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

ในแง่นามธรรมมากขึ้นคุณเองกำลังตอบคำถาม:

ดังนั้นจึงเป็นการเพิ่มชั้นของการอ้อมที่ทำให้กระบวนการวินิจฉัยช้าลง

... เนื่องจากมีคำพังเพยที่มีชื่อเสียงที่กล่าวว่า: "ปัญหาทั้งหมดในวิทยาการคอมพิวเตอร์สามารถแก้ไขได้โดยการอ้อมอีกระดับหนึ่ง" :)


6

เพียงเพราะคุณอยู่ใน บริษัท เดียวกันไม่ได้หมายความว่าคุณควรเปิดเผยทุกอย่างให้ทุกคน REST API เป็นวิธีการกำหนดความสัมพันธ์ระหว่างผู้บริโภค / ผู้ให้บริการที่ จำกัด ระหว่างทีมใน บริษัท โดยมีสัญญาที่ชัดเจน Amazon เป็นผู้บุกเบิกในรูปแบบขององค์กรนี้

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


3

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


ฉันไม่ได้แนะนำการสืบค้นฐานข้อมูลนั้น == REST แน่นอนว่า REST นั้นมีความสามารถมากกว่าเป็นเลเยอร์นามธรรมของเลเยอร์นามธรรม แต่ในอดีตที่ผ่านมาทั้งสอง บริษัท ที่ฉันทำงานให้นั่นคือทั้งหมดที่มันเป็น - เลเยอร์นามธรรมที่เป็นเลเยอร์ มันไม่ได้ทำอะไรอื่น ๆกว่าแปลร้องขอ HTTP แบบสอบถาม DB และถ้านั่นคือทั้งหมดที่คุณทำมันดูเหมือนว่าฉันจะได้รับการบริการที่ดีขึ้นจาก DBAL สำหรับฉันแล้วดูเหมือนว่าเหตุผลเดียวที่บางคนใช้ REST ในสมัยนี้ก็เพราะมันเป็นเทรนด์ - ไม่ใช่เพราะมันเป็นทางออกที่ดีที่สุดสำหรับงานในมือ
neubert

@neubert DBAL ทำงานโดยตรงผ่านทางอินเทอร์เน็ตเช่นเดียวกับ REST หรือไม่
Rob

แน่ใจ คุณสามารถบอก MySQL ให้ใช้ที่อยู่ IP / ชื่อโดเมน / พอร์ตที่เป็นของคอมพิวเตอร์เครื่องอื่นบนอินเทอร์เน็ต คุณสามารถใช้ SSH tunneling (ฉันเชื่อว่า) รับรองความถูกต้อง SSL ด้วย งาน DBMS อื่น ๆ น่าจะคล้ายกัน
neubert

@neubert: ในกรณีนั้น REST API นั้นเป็น DBAL ใช่ไหม?
RemcoGerlich

2
@RemcoGerlich - แน่นอน แต่การใช้ REST API เป็น DBAL ของคุณอาจเพิ่มเลเยอร์กลางที่ไม่จำเป็นและขัดขวางการวินิจฉัยปัญหา ฉันหมายความว่าถ้าคุณจะใช้คำจำกัดความที่กว้างเพียงพอของ DBAL คุณสามารถพิจารณา Google SERP ให้เป็น DBAL ได้ คุณเพียงแค่ต้องแยก HTML เพื่อให้ได้ข้อมูลที่ใส่เลขหน้าจากเซิร์ฟเวอร์ของ Google ...
Neubert
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.