คำขอขนาดเล็กจำนวนมากเทียบกับคำขอขนาดใหญ่จำนวนน้อย (การออกแบบ API)

ฉันกำลังทำงานในโครงการกับองค์กรดังต่อไปนี้:

• ไคลเอ็นต์ - รับข้อมูลจากเซิร์ฟเวอร์หลักผ่าน REST api
• เซิร์ฟเวอร์ - ร้องขอข้อมูลจากเซิร์ฟเวอร์อื่น ๆ ผ่าน API ของบุคคลที่สาม
• API ของบุคคลที่สาม - บริการอยู่นอกเหนือการควบคุมของฉันที่ให้ข้อมูลกับเซิร์ฟเวอร์ (Reddit, Hackernews, Quora ฯลฯ )

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

อาหารตามสั่ง

ในวิธีการนี้ฉันจะมีจุดสิ้นสุด 3 จุดแยกกันบนเซิร์ฟเวอร์ของฉัน: รายการหนึ่งเพื่อรับรายการรายการหนึ่งรายการเพื่อรับเนื้อหาหลักสำหรับรายการและอีกรายการหนึ่งเพื่อรับการตอบกลับของรายการ

• ข้อดี: ฉันไม่เคยขอมากกว่าที่ต้องการการร้องขอควรมีขนาดเล็กดังนั้นโดยทั่วไปพวกเขาควรจะเร็วกว่า
• ข้อด้อย: ฉันต้องขอจำนวนมาก หลังจากเลือกรายการจากรายการผู้ใช้อาจต้องรอก่อนเห็นเนื้อหาหลักจากนั้นรออีกนานเพื่อดูการตอบกลับ

แคชฝั่งเซิร์ฟเวอร์

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

• ข้อดี: ยังใช้งานง่ายในฝั่งไคลเอ็นต์ แต่ไม่มีปัญหาเวลาในการตอบสนอง
• ข้อด้อย: ฝั่งเซิร์ฟเวอร์มีส่วนเกี่ยวข้องมากกว่าเล็กน้อยและการโทรครั้งแรกอาจใช้เวลานานมาก

แคชฝั่งไคลเอ็นต์

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

• ข้อดี: การติดตั้งเซิร์ฟเวอร์ที่ง่ายดายรวดเร็วมากหลังจากการโทรครั้งแรก
• ข้อด้อย: การโทรครั้งแรกจะช้ามากการใช้งานฝั่งไคลเอ็นต์ที่ซับซ้อนมากขึ้น

ฉันไม่แน่ใจว่าวิธีใดดีที่สุดหรือบางทีฉันอาจขาดวิธีแก้ปัญหาที่ชัดเจน คำแนะนำใด ๆ ที่จะได้รับการชื่นชมอย่างมาก!

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

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

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

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

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

ตามข้อมูลที่คุณให้เท่านั้นตัวเลือก 1 เนื่องจาก

• ด้วยการร้องขอของลูกค้าเดียวคุณจะผสมแอปเปิ้ลและส้มและตะกร้าผลไม้อาจมีขนาดใหญ่มาก

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

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

ฉันจะ (เกือบ) ตัวเลือกส่วนลด 3. การเลือกระหว่าง 1 และ 2 ขึ้นอยู่กับสองสิ่ง:

• (A) ผลลัพธ์ของการดึงหนึ่งครั้งมีขนาดใหญ่เพียงใด
• (B) รายละเอียดของผลลัพธ์ที่ลูกค้า / ผู้ใช้มักจะใช้ในเซสชันนั้น

ง่ายต่อการตัดสินใจถ้า A และ B เป็นสุดขั้ว:

• ถ้า A ใหญ่และ B เล็กให้เลือกตัวเลือก 1 (A la Carte) อย่างแน่นอน
• หาก A มีขนาดเล็กและ B มีขนาดใหญ่ให้ไปที่ 2 (แคชฝั่งเซิร์ฟเวอร์) หรือแม้แต่ 3 (แคชฝั่งไคลเอ็นต์)

สำหรับรูปแบบ A / B อื่น ๆ (ใหญ่ / เล็ก) คุณจะต้องใช้ดุลยพินิจ ฉันมักจะให้จุดปลายทั้งหยาบและละเอียดเพื่อรองรับกรณีการใช้งานที่แตกต่างจากลูกค้าที่แตกต่างกัน

เช่นเคยในการเขียนโปรแกรมมันขึ้นอยู่กับ

ดังนั้นคำถามที่แท้จริงคือ: สิ่งที่คุณควรพิจารณาเมื่อตัดสินใจ A / B / C หรือการรวมกันของทั้งสาม?

ฉันจะบอกว่าปัจจัยการเลือกปฏิบัติที่แท้จริงคือรายละเอียดการใช้งาน API ของบุคคลที่สามที่คุณใช้ไป ตัวอย่างเช่นคุณควรพิจารณา: พวกมันเร็วหรือช้าหรือไม่ ข้อมูลเปลี่ยนแปลงบ่อยและไม่คาดคิดหรือไม่? พวกเขา "ช่างพูด" หรือพักผ่อน?

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

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

ตัวเลือกที่ 3 ฉันจะพิจารณาเฉพาะในกรณีที่ข้อมูลไม่มาก แต่ในกรณีนั้นแม้แต่ตัวเลือกที่ 1 หรือ 2 ก็สามารถใช้งานได้และคุณใช้ตรรกะบนเซิร์ฟเวอร์มากขึ้นดังนั้นฉันจะติด 1 หรือ 2

แค่ 2c ของฉัน