Pattern: Page-Based Decomposition (แพตเทิร์น: Page-Based Decomposition)

ใน page-based decomposition UI ของเราถูกแยกออกเป็นหน้าเว็บหลายหน้า โดยแต่ละกลุ่มของหน้าสามารถให้บริการจากไมโครเซอร์วิสที่แตกต่างกันได้ ใน Figure 14-4 เราจะเห็นตัวอย่างของแพตเทิร์นนี้สำหรับ MusicCorp คำขอสำหรับหน้าใน /albums/ จะถูก route ตรงไปยัง microservice Albums ซึ่งจัดการการให้บริการหน้าเหล่านั้น และเราก็ทำแบบเดียวกันกับ /artists/ มีการนำทาง (navigation) ร่วมกันเพื่อเชื่อมหน้าเหล่านี้เข้าด้วยกัน ไมโครเซอร์วิสเหล่านี้อาจดึงข้อมูลที่จำเป็นในการสร้างหน้าเหล่านี้ เช่น การดึงระดับสต็อกจาก microservice Inventory เพื่อแสดงบน UI ว่ามีสินค้าใดอยู่ในสต็อกบ้าง

bms2 1404

Figure 14-4. ส่วนติดต่อผู้ใช้ประกอบด้วยหลายหน้า โดยกลุ่มหน้าที่ต่างกันให้บริการจากไมโครเซอร์วิสที่ต่างกัน

ด้วยโมเดลนี้ ทีมที่เป็นเจ้าของ microservice Albums จะสามารถ render UI แบบ end to end ได้ทั้งหมด ทำให้ทีมนั้นเข้าใจได้ง่ายว่าการเปลี่ยนแปลงของตนจะส่งผลต่อผู้ใช้อย่างไร

The Web (เว็บ)

ก่อนที่จะมี single-page app เรามีเว็บ การโต้ตอบของเรากับเว็บนั้นอิงจากการเข้าไปที่ URL และคลิกลิงก์ต่างๆ ที่ทำให้หน้าใหม่ถูกโหลดเข้ามาในเบราว์เซอร์ของเรา เบราว์เซอร์ของเราถูกสร้างขึ้นมาเพื่อรองรับการนำทางไปมาระหว่างหน้าเหล่านี้ พร้อมกับ bookmark สำหรับจดจำหน้าที่สนใจ และปุ่มย้อนกลับกับไปข้างหน้าสำหรับกลับไปดูหน้าที่เคยเข้าชม พวกคุณทุกคนอาจกำลังกลอกตาแล้วคิดว่า "แหงอยู่แล้ว ผมรู้ว่าเว็บทำงานยังไง!" แต่นี่คือสไตล์ของส่วนติดต่อผู้ใช้ที่ดูเหมือนจะเลิกเป็นที่นิยมไปแล้ว ความเรียบง่ายของมันเป็นสิ่งที่ผมคิดถึงเมื่อเห็น implementation ของ UI บนเว็บในปัจจุบัน เราสูญเสียอะไรไปมากจากการสมมติโดยอัตโนมัติว่า UI บนเว็บต้องหมายถึง single-page app

ในแง่ของการรับมือกับไคลเอนต์ประเภทต่างๆ ไม่มีอะไรมาขวางไม่ให้หน้าปรับสิ่งที่แสดงตามลักษณะของอุปกรณ์ที่ร้องขอหน้านั้นได้ แนวคิดของ progressive enhancement (หรือ graceful degradation) น่าจะเป็นที่เข้าใจกันดีอยู่แล้วในตอนนี้

ความเรียบง่ายของ page-based decomposition ในแง่ของการ implement ทางเทคนิคเป็นจุดที่น่าสนใจมากในที่นี้ คุณไม่จำเป็นต้องมี JavaScript หวือหวาใดๆ รันอยู่ในเบราว์เซอร์ และไม่ต้องใช้ iFrame ที่มีปัญหา ผู้ใช้แค่คลิกลิงก์ แล้วก็มีการร้องขอหน้าใหม่

Where to Use It (ควรใช้ที่ไหน)

มีประโยชน์ทั้งกับแนวทาง monolithic frontend หรือ micro frontend page-based decomposition จะเป็นตัวเลือกเริ่มต้นของผมสำหรับการแยกส่วนติดต่อผู้ใช้ หากส่วนติดต่อผู้ใช้ของผมเป็นเว็บไซต์ หน้าเว็บในฐานะหน่วยของการแยกส่วนเป็นแนวคิดหลักของเว็บโดยรวมมากจนกลายเป็นเทคนิคที่เรียบง่ายและชัดเจนสำหรับการแยกส่วนติดต่อผู้ใช้บนเว็บขนาดใหญ่

ผมคิดว่าปัญหาคือในความรีบเร่งที่จะใช้เทคโนโลยี single-page application ส่วนติดต่อผู้ใช้แบบนี้กำลังกลายเป็นของหายากมากขึ้นเรื่อยๆ จนถึงขนาดที่ประสบการณ์ผู้ใช้ที่ในความเห็นของผมน่าจะเหมาะกับ implementation แบบเว็บไซต์มากกว่า กลับถูกยัดเยียดให้กลายเป็น single-page application 4 แน่นอนว่าคุณสามารถผสมผสาน page-based decomposition กับแพตเทิร์นอื่นๆ ที่เราคุยกันไปได้ ผมอาจมีหน้าที่มี widget อยู่ในนั้น ตัวอย่างเช่น สิ่งที่เราจะดูกันต่อไป