インタラクティブなデータ可視化には、バックエンドの思考も必要だ

人々は、データ可視化の誤ったレイヤーを称賛している。

滑らかなアニメーションや洗練された地図には気づく。しかし、それらのビジュアルを可能にしている目に見えない作業には気づかない。汚れたデータをクレンジングするインジェクション・ジョブや、APIを高速に保つキャッシュ戦略は見えていないのだ。

その目に見えない作業こそが、実際のプロダクトである。

データ集約型の体験を構築する場合、フロントエンドは単なるレンダラーに過ぎない。真のエンジニアリングの課題は、上流工程で発生する。ブラウザにどのようなデータ形状を届けるか、そしてどれだけの量を届けるかを決定しなければならない。

可視化を実際のトラフィックに耐えうるものにしたいのであれば、「バックエンド・ファースト」な設計が必要だ。それがなければ、不安定な経路の上に綺麗なアニメーション層を乗せただけのデモをリリースしているに過ぎない。

多くの可視化スタックが失敗するのは、APIがストレージモデルに近すぎるからだ。バックエンドが生のレコードを送信し、フロントエンドがデータのクレンジング、集計、グルーピングを強制される。これは開発中は高速に感じられるが、本番環境では、ユーザー一人ひとりがデータクレンジングのコストを支払うことになるため、非常に高コストになる。

バックエンドは生のログではなく、再生モデル（playback model）を提供すべきである。

バックエンドが重い処理を引き受ければ、すべてが改善する：

• CPU負荷がブラウザから切り離される。
• 振る舞いのテストが容易になる。
• キャッシュ効率が向上する。
• システムの予測可能性が高まる。

可視化は「特化したコンシューマー（消費者）」である。高速なアクセスと小さなペイロードが必要だ。管理ダッシュボードやデータエクスポートと同じAPIを強制してはならない。専用のバックエンド・コントラクト（契約）を与えてほしい。

プロフェッショナルなパイプラインは、以下の5つのことを行うべきである：

• ソースレコードを検証し、不正なデータを拒否する。
• タイムゾーンや単位などの構造を正規化する。
• 生の行ではなく、再生セグメントを派生させる。
• さまざまなズームレベルに合わせて、複数の解像度を作成する。
• 古いデータが混ざらないよう、リビジョンを刻印する。

ペイロードのサイズをフロントエンドの問題として扱うのはやめよう。それはAPIコントラクトの問題だ。サーバーが大量のデータを送信すれば、インタラクションが高速に感じられることは決してない。

強固なAPIは、可能な限り最小限かつ真実に基づいたビューを送信する。時間、地域、詳細レベルによってリクエストを制限するのだ。

システムを「リング」構造で構築せよ：

• 第1のリングは、概要を通じて全体像（orientation）を提供する。
• 第2のリングは、スクラブ（scrubbing）やズームのためのインタラクションを提供する。
• 第3のリングは、エンティティの詳細を深く調査するためのインスペクション（inspection）を提供する。

アップタイム（稼働時間）だけを追跡してはいけない。ペイロードサイズ、キャッシュヒット率、データの鮮度を追跡せよ。そして最も重要なのは、処理されたアーティファクトが依然として現実と一致しているかを検証することだ。

派生した可視化は「データプロダクト」である。単なるレンダリングではなく、検証が必要なのだ。

フロントエンドが「バージョン管理されたデータプロダクトの再生クライアント」であるかのようにバックエンドを構築せよ。それこそが、リリース後も耐えうるシステムを構築する方法である。

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