การทำ Data Visualization แบบโต้ตอบได้ จำเป็นต้องใช้กระบวนการคิดแบบ Backend ด้วยเช่นกัน

ผู้คนมักจะชื่นชม Data Visualization ผิดจุด

พวกเขาสังเกตเห็นแอนิเมชันที่ลื่นไหลและแผนที่ที่ดูสวยงาม แต่พวกเขามองไม่เห็นงานเบื้องหลังที่ทำให้ภาพเหล่านั้นเกิดขึ้นได้ พวกเขาไม่เห็นงานด้าน Ingestion ที่คอยทำความสะอาดข้อมูลที่ยุ่งเหยิง หรือกลยุทธ์การทำ Cache ที่ช่วยให้ API ทำงานได้อย่างรวดเร็ว

งานที่มองไม่เห็นเหล่านั้นต่างหากคือผลิตภัณฑ์ที่แท้จริง

หากคุณกำลังสร้างประสบการณ์ที่เน้นข้อมูลจำนวนมาก Frontend เป็นเพียงแค่ตัวแสดงผล (Renderer) เท่านั้น ความท้าทายทางวิศวกรรมที่แท้จริงเกิดขึ้นที่ต้นน้ำ (Upstream) คุณต้องตัดสินใจว่ารูปแบบข้อมูล (Data shape) แบบไหนที่จะส่งไปถึงเบราว์เซอร์ และจะส่งไปในปริมาณเท่าใด

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

Visualization Stack หลายตัวล้มเหลวเพราะ API นั้นใกล้เคียงกับโมเดลการจัดเก็บข้อมูล (Storage model) มากเกินไป Backend ส่งข้อมูลดิบ (Raw records) ออกมา และ Frontend ถูกบังคับให้ต้องทำความสะอาด จัดกลุ่ม (Aggregate) และจัดหมวดหมู่ข้อมูลเอง ซึ่งอาจจะดูเหมือนเร็วในช่วงการพัฒนา แต่จะกลายเป็นภาระมหาศาลในขั้นตอน Production เพราะผู้ใช้ทุกคนต้องแบกรับต้นทุนในการทำความสะอาดข้อมูล

Backend ของคุณควรส่งมอบ Playback model ไม่ใช่แค่ Raw log

เมื่อ Backend เป็นผู้จัดการงานหนัก ทุกอย่างจะดีขึ้น:

  • ภาระงานของ CPU จะย้ายออกจากเบราว์เซอร์
  • พฤติกรรมของระบบทดสอบได้ง่ายขึ้น
  • ความสามารถในการทำ Cache ดีขึ้น
  • ระบบมีความคาดเดาได้ (Predictable)

Visualization คือ Consumer เฉพาะทาง มันต้องการการเข้าถึงที่รวดเร็วและ Payload ขนาดเล็ก อย่าบังคับให้มันใช้ API เดียวกับ Admin dashboard หรือการ Export ข้อมูล แต่ควรให้ Backend contract ที่ออกแบบมาเพื่อมันโดยเฉพาะ

Pipeline ระดับมืออาชีพควรทำ 5 อย่างนี้:

  • Validate ข้อมูลต้นทางเพื่อปฏิเสธข้อมูลที่ผิดพลาด
  • Normalize โครงสร้างข้อมูล เช่น Time zone และหน่วยวัดต่างๆ
  • สร้าง Playback segments แทนที่จะส่งข้อมูลเป็นแถว (Raw rows)
  • สร้างความละเอียดหลายระดับ (Multiple resolutions) สำหรับระดับการซูมที่ต่างกัน
  • ทำเครื่องหมายเวอร์ชัน (Stamp revisions) เพื่อป้องกันไม่ให้ข้อมูลที่ล้าสมัยมาปะปนกัน

เลิกมองว่าขนาดของ Payload เป็นปัญหาของ Frontend เพราะมันคือปัญหาของ API contract หากเซิร์ฟเวอร์ของคุณส่งข้อมูลมากเกินไป การโต้ตอบ (Interaction) จะไม่มีวันรู้สึกว่ารวดเร็วได้เลย

API ที่แข็งแกร่งจะส่งข้อมูลที่เป็นมุมมองที่เล็กที่สุดเท่าที่เป็นไปได้และถูกต้องที่สุด โดยจำกัดขอบเขตของ Request ตามเวลา, ภูมิภาค และระดับความละเอียด

สร้างระบบของคุณเป็นชั้นๆ (Rings):

  • ชั้นแรกให้ทิศทาง (Orientation) ผ่านภาพรวม (Overview)
  • ชั้นที่สองให้การโต้ตอบสำหรับการเลื่อนดู (Scrubbing) และการซูม
  • ชั้นที่สามให้การตรวจสอบ (Inspection) รายละเอียดเชิงลึกของ Entity

อย่าติดตามแค่ Uptime แต่ให้ติดตามขนาด Payload, อัตรา Cache hit และความสดใหม่ของข้อมูล (Data freshness) และที่สำคัญที่สุดคือ ต้องตรวจสอบว่าข้อมูลที่ผ่านการประมวลผลแล้ว (Processed artifacts) ยังคงตรงกับความเป็นจริง

Visualization ที่ได้จากการประมวลผลคือผลิตภัณฑ์ข้อมูล (Data product) มันต้องการการตรวจสอบความถูกต้อง (Validation) ไม่ใช่แค่การแสดงผล (Rendering)

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

Source: https://dev.to/saqueib/interactive-data-visualizations-need-backend-thinking-too-5bk0