Home United States USA — software How to Design a Flexible Solution for Custom Dashboards and Reports

How to Design a Flexible Solution for Custom Dashboards and Reports

173
0
SHARE

No matter how vast the solution you provide to your clients, there are always custom requirements. This article reviews custom dashboards and reports.
Join the DZone community and get the full member experience. Trying to build a solution that is simple, fast, scalable, highly available, yet flexible to handle custom requests from your clients? Looking for a solution that can serve a group of customers or can dedicatedly be deployed for a single customer in a multi-tenant environment? This post is for you. No matter how vast or fine the solution you provide to your clients, there are always custom requirements. Some requests can be fulfilled with small tweaks but others can take a big effort and a complete development cycle. For a SaaS solution, these requests are very common and always a challenging task. Dashboards and Reports are the most common areas for these types of requests where every customer needs data that make more sense to them and in the format, they understand better. We have tried a few solutions over the years to deliver Dashboards and Reports, but they were never up to the expectations. It all started a few years back when we published the first solution. It was implemented using Java, MySQL, JavaScript, and elycharts (an open-source javascript charting library). The publisher was sending the data on two different services, which were processing and storing the data in MySQL tables. For every dashboard and report, data was being fetched from MySQL (yeah, even for the live data we used MySQL as a queue). Both independent dashboard and reporting applications were serving the data that ‘we’ think makes sense to the customers but the solution has multiple drawbacks and limitations. The major ones are — To overcome the challenges we tried integrating with a third-party UI provider for dashboards. We also made some changes around data sources, data categorization, data polling, etc. To solve data discrepancy, we divided the data into two categories live vs delayed. Earlier we were trying to present the whole data on dashboards as soon as possible and to do that, we were managing a different data source for dashboards and putting a heavy read load on it.

Continue reading...