ประโยชน์ของการใช้เซิร์ฟเวอร์ API และ UI แยกต่างหากสำหรับเว็บแอปพลิเคชัน

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

คำขอโทษของฉันถ้าด้านล่างยาวหน่อยฉันแค่อยากจะลองวาดภาพที่ดีว่าระบบคืออะไรก่อนที่ฉันจะถามคำถาม :)

• วิธีการติดตั้งระบบคือเรามีเว็บแอปพลิเคชั่นหลักหนึ่งตัว (asp.net, AngularJS) ซึ่งส่วนใหญ่จะรวบรวมข้อมูลจากบริการอื่น ๆ ดังนั้นโดยทั่วไปมันเป็นโฮสต์สำหรับแอปพลิเคชัน AngularJS มีตัวควบคุม MVC หนึ่งตัวที่บูตด้านไคลเอนต์จากนั้นตัวควบคุมอื่น ๆ คือตัวควบคุม WebAPI

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

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

• ด้วยข้อยกเว้นเดียว WebAPIs เหล่านี้จะไม่ถูกใช้โดยส่วนอื่น ๆ ขององค์กรของเรา

• ในที่สุด WebAPIs เหล่านี้ก็ยังเรียกใช้บริการ "back end" อีกชุดซึ่งโดยทั่วไปจะเป็นบริการ asmx หรือ wcf แบบดั้งเดิมที่ตบอยู่ด้านบนของระบบ ERP และร้านค้าข้อมูล (ซึ่งเราไม่สามารถควบคุมได้)

• ตรรกะทางธุรกิจส่วนใหญ่ของแอปพลิเคชันของเราอยู่ใน WebApis เหล่านี้เช่นการแปลงข้อมูลแบบดั้งเดิมรวมเข้าด้วยกันดำเนินการกฎทางธุรกิจซึ่งเป็นประเภทปกติ

สิ่งที่ฉันสับสนคือประโยชน์ที่เป็นไปได้ที่จะมีการแยกระหว่าง WebApplication และ WebAPIs ที่ให้บริการนั้น เนื่องจากไม่มีใครใช้มันฉันไม่เห็นประโยชน์การปรับขนาดได้ (เช่นไม่มีจุดในการใส่ในกล่อง API อีก 4 กล่องเพื่อจัดการกับโหลดที่เพิ่มขึ้นเนื่องจากการโหลดที่เพิ่มขึ้นบนเซิร์ฟเวอร์ API ต้องหมายความว่ามีการโหลดที่เพิ่มขึ้นบนเว็บเซิร์ฟเวอร์ - ดังนั้นจะต้องมีอัตราส่วน 1: 1 ของเว็บเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์ Api)

• ฉันยังไม่เห็นประโยชน์ใด ๆ เลยที่ต้องทำการเรียกเบราว์เซอร์ HTTP พิเศษ => HTTP => WebApp => HTTP => WebAPI => HTTP => บริการแบ็คเอนด์ (การโทร HTTP นั้นระหว่าง WebApp และ WebAPI คือปัญหาของฉัน)

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

• การปรับใช้ที่ชาญฉลาดหมายความว่าเราจะมี 8 "สแต็กเต็ม" กล่องเว็บซึ่งตรงข้ามกับ 4 + 4

ประโยชน์ที่ฉันเห็นของวิธีการใหม่คือ

• เพิ่มประสิทธิภาพเนื่องจากมีหนึ่งรอบน้อยกว่าของการทำให้เป็นอนุกรม / deserialisation ระหว่างเว็บแอปพลิเคชันและเซิร์ฟเวอร์ WebAPI
• ตันของรหัสที่สามารถลบได้ (เช่นไม่จำเป็นต้องบำรุงรักษา / ทดสอบ) ในแง่ของ DTOs และผู้ทำแผนที่ในขอบเขตขาออกและขาเข้าของ Web Application และเซิร์ฟเวอร์ WebApi ตามลำดับ
• ความสามารถที่ดีกว่าในการสร้างการทดสอบการรวมอัตโนมัติที่มีความหมายเพราะฉันสามารถล้อเลียนบริการแบ็คเอนด์และหลีกเลี่ยงความยุ่งเหยิงรอบการกระโดด HTTP ระดับกลาง

ดังนั้นคำถามคือ: ฉันผิดหรือเปล่า? ฉันพลาด "เวทมนต์" พื้นฐานของการแยก WebApplication และ WebAPI กล่องออกจากกันหรือไม่?

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

และสิ่งที่ฉันจะสูญเสียในแง่ของผลประโยชน์ถ้าฉันจะจัดระเบียบระบบใหม่เพื่อการตั้งค่าที่ฉันเสนอ?

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

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

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

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

ฉันคิดว่าไม่มีคำตอบที่ถูก / ผิดที่นี่ คุณเคยถามเพื่อนร่วมงานเกี่ยวกับจุดประสงค์ของสถาปัตยกรรมนี้หรือไม่?

จากวิธีที่ฉันเข้าใจคำอธิบายของคุณ " WebAPI " ในสถาปัตยกรรมของคุณทำหน้าที่เป็นมิดเดิ้ลที่สร้างขึ้นด้วยตนเอง ตอนนี้คุณสามารถวิจัยข้อดีของการใช้ Middleware โดยทั่วไป Webapp ของคุณจะไม่จำเป็นต้องนำมาใช้ถ้าคุณเปลี่ยนระบบ BackOffice (ตราบใดที่ส่วนต่อประสานWebAPIยังคงเหมือนเดิม)

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

โดยทั่วไปแล้ว Layer Architecture ได้รับการพิจารณาในปัจจุบันว่าเป็น: Pattern และ Anti-Pattern (ดู: Lasagna-Code ) หากคุณมีเพียง 1 ระบบที่ไม่มีแผนที่จะขยายเพิ่มเติมในอีกไม่กี่ปีข้างหน้าฉันจะถือว่านี่เป็นรูปแบบการต่อต้าน แต่ woudl นี้เป็นผู้ตัดสิน taff ที่ไม่สมจริงเพราะฉันไม่รู้สถานการณ์ / สถานการณ์ที่แน่นอน :)