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

ฉันกำลังสร้างเว็บแอปพลิเคชันธุรกิจใหม่และฉันต้องการบรรลุ:

• ใช้เทคโนโลยีที่ดีที่สุดจากอาณาจักรที่เกี่ยวข้อง ฉันต้องการกรอบแบ็กเอนด์ที่เชื่อถือได้ด้วย ORM ที่มั่นคง และฉันต้องการเฟรมเวิร์ก SPA (แอปพลิเคชันหน้าเดียว) ที่ทันสมัยที่สุดด้วยการใช้คุณสมบัติ HTML และ Javascript ล่าสุดสำหรับแอปพลิเคชันส่วนหน้า
• เปิดเผยเอนทิตีแบ็กเอนด์และบริการธุรกิจสำหรับการใช้งานจากแอพพลิเคชั่นประเภทต่าง ๆ เช่นเว็บแอพพลิเคชั่นมือถือ (Android) และประเภทอื่น ๆ (อุปกรณ์สมาร์ทเป็นต้น)

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

การแยกดังกล่าวไม่ใช่โซลูชันการออกแบบที่ชัดเจนเนื่องจากเทคโนโลยีเว็บแอปพลิเคชันจำนวนมากได้รวมเลเยอร์มุมมองไว้ซึ่งแอปพลิเคชันฝั่งเซิร์ฟเวอร์จะควบคุมการสร้างมุมมองมากขึ้นหรือน้อยลงและจัดการการตอบสนองจากมุมมองบางส่วน layer, Java JSF / Facelets จะบันทึกสถานะของส่วนประกอบบนเซิร์ฟเวอร์อย่างสมบูรณ์) ดังนั้น - มีเทคโนโลยีมากมายที่เสนอการมีเพศสัมพันธ์ที่แข็งแกร่งมากขึ้นและให้สัญญาว่าจะพัฒนาได้เร็วขึ้นและมีเส้นทางการเดินทางที่เป็นมาตรฐานมากขึ้น ดังนั้น - ฉันต้องระวังเมื่อเริ่มใช้เทคโนโลยีในลักษณะที่ไม่ได้ใช้กันอย่างแพร่หลาย

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

ปัจจุบันเทคโนโลยีที่ฉันเลือกคือแบ็กเอนด์ Java / Spring และ Angular2 / Web Components / Polymer สำหรับส่วนหน้า - หากฉันได้รับอนุญาตให้พูดสิ่งนี้ แต่นั่นไม่เกี่ยวข้องกับคำถามนี้เพราะคำถามนี้เกี่ยวกับการออกแบบทั่วไปและไม่เกี่ยวกับการเลือกใช้เทคโนโลยีคอนกรีต?

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

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

SPA มาพร้อมกับปัญหาเล็กน้อยที่เกี่ยวข้อง นี่เป็นเพียงไม่กี่ที่ปรากฏในใจของฉันตอนนี้:

• ส่วนใหญ่เป็นจาวาสคริปต์ ข้อผิดพลาดหนึ่งในส่วนของแอปพลิเคชันของคุณอาจทำให้ส่วนอื่น ๆ ของแอปพลิเคชันไม่ทำงานเนื่องจากข้อผิดพลาดของ Javascript นั้น ด้วยหน้าที่ให้บริการจากเซิร์ฟเวอร์ (SpringMVC, PHP, ฯลฯ ) คุณจะโหลดซ้ำส่วนใหม่
• ธ ไม่จำเป็นต้องบังคับ แต่บ่อยครั้งที่แบ็คเอนด์อยู่ในชื่อโดเมนที่แตกต่างจากฟรอนต์เอนด์ ดังนั้นตอนนี้คุณต้องจัดการกับปัญหาความปลอดภัยของเบราว์เซอร์
• SEO คุณต้องการสิ่งนี้หรือไม่? ไซต์ของคุณเป็นสาธารณะหรือไม่ Google สามารถเข้าใจ Javascript และพยายามใช้ประโยชน์จากไซต์ของคุณ แต่โดยทั่วไปคุณสามารถควบคุมบอทและหวังว่าจะดีที่สุด การควบคุมกลับอาจหมายถึงการต้องพึ่งพาในเครื่องมืออื่น ๆ เช่นPhantomJS
• แอปพลิเคชั่นแยกส่วนหน้าหมายถึงโปรเจ็กต์แยกต่างหาก, ท่อการใช้งาน, เครื่องมือพิเศษ, ฯลฯ ;
• การรักษาความปลอดภัยทำได้ยากกว่าเมื่อรหัสทั้งหมดอยู่บนไคลเอนต์

แน่นอนว่ามีข้อดีของสปาเช่นกัน:

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

ดังนั้นสิ่งนี้คือมีข้อดีและข้อเสียของทั้งสองวิธี (SPA เทียบกับหน้าเซิร์ฟเวอร์) ใช้เวลาสักครู่ในการค้นคว้าทั้งสองตัวเลือกแล้วเลือกตามสถานการณ์ของคุณ

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

ปกติกับคำเตือน

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

ดังนั้นสถาปัตยกรรม 'ปกติ' อาจจะ:

database
business logic services (dll)
api exposing business logic
server side website exposing viewmodels and functionality via json rest endpoints
client side javascript implementing ui

ตอนนี้ถ้าคุณมีเว็บแอปพลิเคชั่นเพียงตัวเดียวคุณสามารถตัดเลเยอร์ 'api เปิดเผยตรรกะทางธุรกิจ' และเพียงแค่มีเว็บโค้ดฝั่งเซิร์ฟเวอร์เรียกตรรกะทางธุรกิจโดยตรง

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

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

นอกจากนี้การมีจาวาสคริปต์จะเรียกโฮสต์เดียวกับที่ให้บริการจากหมายความว่าคุณไม่ต้องยุ่งกับ cors