DEV Community

Discussion on: How to build an efficient user-facing dashboard?

Collapse
 
jjude profile image
Joseph Jude

I have not built b2b dashboards, but designed and built multiple dashboards for CXO level officers. These dashboards have to query silo systems with voluminous and in-transit data. Without knowing more details, here are my comments:

  • separate transaction and analytic data (if possible even put them into different dbs). This gives you flexibility to optimize each differently.
  • separate real-time, near-real-time, and delayed info. Unless otherwise it is a monitoring system, you don't need real-time dashboards. Almost 80% of dashboards can show delayed info (a hour old/week old); another 10 - 15% types of dashboard can live with near-real-time (10 min old data). This in itself will help you avoid lot of headache regarding compute, optimization, and truthfulness of data.
  • limit computation to one side. In one of the dashboard project, we started with computing certain values in the client side (browser), then we had to add mobile apps, and few other display points. Because of the way we designed, we had to replicate this compute in these devices. It was a pain. We had to rewrite to bring all compute to a single location. I prefer to do it in db, but if you are sure all traffic will go through application, you can do it in app too. [I don't know your use case. We assumed all traffic will go through the app and built logic in app; but as soon as the marketing department knew there is an analytic db, they threw in a report builder on top of the db and started building reports. This lead to questions of "truthfulness of data" since data we showed via app and the data they saw via reports were different].

Hope these give you some pointers to chew. If you need some specific discussions, don't hesitate to ask.