Pattern: Monolithic Frontend (แพตเทิร์น: Monolithic Frontend)
แพตเทิร์น monolithic frontend อธิบายสถาปัตยกรรมที่ state และพฤติกรรมทั้งหมดของ UI ถูกกำหนดอยู่ใน UI เอง โดยมีการเรียก backing microservice เพื่อดึงข้อมูลหรือทำงานที่จำเป็น Figure 14-3 แสดงตัวอย่างของแพตเทิร์นนี้ หน้าจอของเราต้องการแสดงข้อมูลเกี่ยวกับอัลบั้มและรายการเพลงในอัลบั้มนั้น UI จึงส่งคำขอไปดึงข้อมูลนี้จาก microservice Album เรายังแสดงข้อมูลโปรโมชันล่าสุดโดยขอข้อมูลจาก microservice Promotions ในตัวอย่างนี้ ไมโครเซอร์วิสของเราส่งคืนข้อมูลแบบ JSON ที่ UI ใช้อัปเดตข้อมูลที่แสดงอยู่
Figure 14-3. หน้าจอรายละเอียด Album ของเราดึงข้อมูลจาก downstream microservice เพื่อ render UI
โมเดลนี้เป็นโมเดลที่พบได้บ่อยที่สุดสำหรับคนที่สร้าง single-page application แบบ monolithic ซึ่งมักมีทีม frontend เฉพาะทางเป็นผู้สร้าง ความต้องการของไมโครเซอร์วิสของเรานั้นค่อนข้างตรงไปตรงมา นั่นคือแค่ต้องแบ่งปันข้อมูลในรูปแบบที่ UI สามารถตีความได้ง่าย ในกรณีของ UI บนเว็บ นี่หมายความว่าไมโครเซอร์วิสของเราน่าจะต้องส่งข้อมูลในรูปแบบข้อความ ซึ่ง JSON เป็นตัวเลือกที่เป็นไปได้มากที่สุด UI จะต้องสร้าง component ต่างๆ ที่ประกอบกันเป็น interface โดยจัดการเรื่อง synchronization ของ state และอื่นๆ กับฝั่ง backend การใช้ binary protocol สำหรับการสื่อสารระหว่างเซอร์วิสจะยากขึ้นสำหรับไคลเอนต์บนเว็บ แต่ก็อาจใช้ได้ดีกับอุปกรณ์มือถือแบบ native หรือแอปพลิเคชันเดสก์ท็อปแบบ "thick"
When to Use It (เมื่อไรควรใช้)
แนวทางนี้ก็มีข้อเสียอยู่บ้าง ประการแรก โดยธรรมชาติของการเป็น monolithic entity มันสามารถเป็นตัวผลักดัน (หรือถูกผลักดันโดย) ทีม frontend เฉพาะทาง การให้หลายทีมแบ่งความรับผิดชอบใน monolithic frontend นี้ร่วมกันอาจเป็นเรื่องท้าทาย เพราะมีจุดที่แย่งชิงกันหลายจุด ประการที่สอง เรามีความสามารถน้อยมากในการปรับแต่ง response ให้เหมาะกับอุปกรณ์แต่ละประเภท ถ้าใช้เทคโนโลยีเว็บ เราสามารถเปลี่ยน layout ของหน้าจอให้เหมาะกับข้อจำกัดของอุปกรณ์ที่แตกต่างกันได้ แต่นั่นไม่ได้หมายความว่าจะเปลี่ยนการเรียกไปยัง microservice ที่รองรับได้ด้วย ไคลเอนต์มือถือของผมอาจแสดงได้แค่ 10 field ของ order แต่ถ้า microservice ดึงข้อมูลกลับมาทั้งหมด 100 field ของ order เราก็จะได้ข้อมูลที่ไม่จำเป็นมาด้วย วิธีแก้ปัญหาหนึ่งคือให้ UI ระบุว่าต้องการ field ไหนตอนที่ส่งคำขอ แต่นั่นก็สมมติว่า microservice ที่รองรับแต่ละตัวต้องรองรับรูปแบบการโต้ตอบนี้ด้วย ใน “GraphQL” เราจะดูว่าการใช้ backend for frontend pattern ร่วมกับ GraphQL ช่วยแก้ปัญหานี้ได้อย่างไร
จริงๆ แล้วแพตเทิร์นนี้ทำงานได้ดีที่สุดเมื่อคุณ ต้องการ ให้ implementation และพฤติกรรมทั้งหมดของ UI อยู่ใน deployable unit เดียว สำหรับทีมเดียวที่พัฒนาทั้ง frontend และไมโครเซอร์วิสที่รองรับทั้งหมด นั่นอาจใช้ได้ดี ส่วนตัวผมคิดว่าถ้าคุณมีมากกว่าหนึ่งทีมที่ทำงานกับซอฟต์แวร์ของคุณ คุณควรต่อต้านแรงกระตุ้นนั้น เพราะมันอาจทำให้คุณเผลอไถลไปสู่สถาปัตยกรรมแบบเลเยอร์พร้อมกับไซโลองค์กรที่ตามมา แต่ถ้าคุณไม่สามารถหลีกเลี่ยงสถาปัตยกรรมแบบเลเยอร์และโครงสร้างองค์กรที่สอดคล้องกันได้ นี่ก็น่าจะเป็นแพตเทิร์นที่คุณจะต้องใช้ในที่สุด