交互式数据可视化也需要后端思维

人们赞美错了数据可视化的层级。

他们注意到流畅的动画和精致的地图，却没注意到让这些视觉效果成为可能的幕后工作。他们看不见清洗杂乱数据的摄取任务，也看不见保持 API 高速运行的缓存策略。

那些看不见的工作才是真正的产品。

如果你构建的是数据密集型体验，前端仅仅是一个渲染器。真正的工程挑战发生在“上游”。你必须决定什么样的数据结构会到达浏览器，以及到达的数据量是多少。

如果你想让你的可视化在真实流量下生存，你需要“后端优先”的设计。否则，你只是在一条不稳定的路径上，套了一个漂亮的动画层，然后交付了一个 Demo。

许多可视化技术栈之所以失败，是因为 API 与存储模型过于接近。后端发送原始记录，而前端被迫进行数据清洗、聚合和分组。这在开发阶段感觉很快，但在生产环境中代价高昂，因为每个用户都要承担数据清洗的成本。

你的后端应该提供一个回放模型（playback model），而不是原始日志。

当后端承担了繁重的工作时，一切都会得到改善：

• CPU 计算任务从浏览器中移出。
• 行为变得易于测试。
• 可缓存性提高。
• 系统变得可预测。

可视化是一个专门的消费者。它需要快速访问和较小的有效载荷（payload）。不要强迫它使用与管理仪表板或数据导出相同的 API。要为它提供专门的后端契约（backend contract）。

一个专业的流水线应该完成五件事：

• 验证源记录以拒绝错误数据。
• 规范化时区和单位等结构。
• 推导回放分段，而非原始行。
• 为不同的缩放级别创建多种分辨率。
• 标记版本，防止过期数据混入。

不要再把有效载荷大小视为前端问题。这是一个 API 契约问题。如果你的服务器发送了过多的数据，交互体验永远不会感到流畅。

一个强大的 API 会发送尽可能小且真实的视图。它通过时间、区域和细节级别来限制请求。

按环形结构构建你的系统：

• 第一环通过概览提供方位感。
• 第二环提供用于拖动（scrubbing）和缩放的交互。
• 第三环提供用于深入查看实体细节的检查功能。

不要只追踪运行时间（uptime）。要追踪有效载荷大小、缓存命中率和数据新鲜度。最重要的是，验证你处理后的产物是否仍然符合现实。

一个派生出的可视化是一个数据产品。它需要验证，而不仅仅是渲染。

构建后端时，要假设前端是一个版本化数据产品的回放客户端。只有这样，你构建的系统才能在发布后经受住考验。

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