{"id":35241,"date":"2026-02-16T17:17:35","date_gmt":"2026-02-16T17:17:35","guid":{"rendered":"https:\/\/streamhub.co.uk\/?p=35241"},"modified":"2026-02-17T16:36:31","modified_gmt":"2026-02-17T16:36:31","slug":"architecting-scalable-chart-modules-in-streamhub-analytics","status":"publish","type":"post","link":"https:\/\/streamhub.co.uk\/architecting-scalable-chart-modules-in-streamhub-analytics\/","title":{"rendered":"Architecting Scalable Chart Modules in Streamhub Analytics: Part I"},"content":{"rendered":"Reading Time: <\/span> 4<\/span> minutes<\/span><\/span>

[et_pb_section fb_built=”1″ _builder_version=”4.16″ da_disable_devices=”off|off|off” global_colors_info=”{}” da_is_popup=”off” da_exit_intent=”off” da_has_close=”on” da_alt_close=”off” da_dark_close=”off” da_not_modal=”on” da_is_singular=”off” da_with_loader=”off” da_has_shadow=”on”][et_pb_row _builder_version=”4.16″ background_size=”initial” background_position=”top_left” background_repeat=”repeat” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.16″ custom_padding=”|||” global_colors_info=”{}” custom_padding__hover=”|||”][et_pb_text admin_label=”Text” _builder_version=”4.27.0″ background_size=”initial” background_position=”top_left” background_repeat=”repeat” global_colors_info=”{}”]<\/p>\n

Problem Space & Design Goals<\/strong><\/h2>\n

In modern web applications, data visualisation is a critical component that requires flexibility, maintainability, and extensibility. When building a charting system, supporting multiple chart types across heterogeneous rendering requirements quickly becomes an architectural challenge.<\/p>\n

In our case, the system needed to support 15+ chart types that users could dynamically add to dashboards. Each chart could be powered by different charting libraries, and although the API responses were consistent, each library expected the input data in its own specific format. What initially seemed like a UI concern soon revealed itself to be a deeper issue involving data transformation, extensibility, and long-term maintainability.<\/p>\n

This post, focuses on the challenges<\/strong> we faced and explains the architectural direction we chose. In the next posts we’ll see how we addressed them with a small set of design patterns.<\/p>\n

\n

 <\/p>\n

Technical Context\u00a0<\/strong><\/h2>\n

Our Analytics product<\/a> is built using Angular as the primary frontend framework. For visualisation, we support multiple libraries depending on the widget type, including AG<\/span><\/span><\/span> Grid for tabular data and Highcharts for basic chart-based visualisations, along with a few custom-rendered charts.<\/p>\n

While the API responses remain consistent, each library imposes its own expectations on how data should be structured. This divergence in data contracts across libraries became a central factor in shaping the overall architecture.<\/p>\n

\n

\u00a0<\/h2>\n

 <\/p>\n

The Core Mismatch: Same Data, Different Library <\/strong><\/h2>\n

Expectations<\/strong><\/h2>\n

One of the key challenges was that different visualisation components required the same dataset to be shaped differently.<\/p>\n

For example, consider a dataset fetched from a consistent API:<\/p>\n

[ <\/span><\/span><\/code><\/span><\/p>\n

\u00a0 \u00a0 {\"device\": \"android\", \"views\": 12,000},<\/span><\/span><\/code><\/span><\/p>\n

\u00a0 \u00a0 { \"device\": \"iphone\", \"views\": 15,000 }<\/span><\/span><\/code><\/span><\/p>\n

]<\/span><\/span><\/code><\/span><\/code><\/span><\/p>\n

\u00a0<\/pre>\n
A data-grid widget powered by ag<\/span>-Grid expects a flat row-based structure:<\/p>\n
rowData = [ <\/span><\/span><\/code><\/span><\/p>\n
\u00a0 \u00a0 {\"device\": \"android\", \"views\": 12,000},<\/span><\/span><\/code><\/span><\/p>\n
\u00a0 \u00a0 { \"device\": \"iphone\", \"views\": 15,000 }<\/span><\/span><\/code><\/span><\/p>\n
]<\/span><\/span><\/code><\/span>;<\/span><\/span><\/code><\/p>\n
However, a bar chart rendered using Highcharts expects a categorized structure:<\/p>\n
\n
\n
series =<\/span> [<\/span><\/span><\/code><\/span>{<\/span><\/span><\/code><\/span><\/p>\n
\u00a0 \u00a0 name:<\/span> \"views\"<\/span>,<\/span><\/span><\/code><\/span><\/p>\n
\u00a0 \u00a0 data:<\/span> [12000<\/span>, 15000<\/span>]<\/span><\/span><\/code><\/span><\/p>\n
}];<\/span><\/span><\/code><\/span><\/p>\n
categories =<\/span> [<\/span>\"android\"<\/span>,<\/span> \"iphone\"<\/span>]<\/span>;<\/span><\/span><\/code><\/p>\n
<\/code><\/p>\n
The underlying API data remains consistent, but each library requires a distinct transformation. As the number of supported chart types and libraries grows, this transformation layer becomes a central architectural concern rather than a simple formatting step.<\/p>\n
 <\/p>\n<\/div>\n<\/div>\n
\u00a0<\/h2>\n
Why Naive Approaches Break Down<\/strong><\/h2>\n
A typical early implementation often resembles this:<\/p>\n
\n
\n
switch<\/span> (<\/span>chartType)<\/span> { <\/span><\/span><\/code><\/span><\/p>\n
\u00a0 \u00a0 case<\/span> 'bar'<\/span>:<\/span> return<\/span> transformToHighchartsBar<\/span>(data);<\/span><\/span><\/code><\/span><\/p>\n
\u00a0 \u00a0 case<\/span> 'grid'<\/span>:<\/span> return<\/span> transformToAgGridRows<\/span>(data);<\/span><\/span><\/code><\/span><\/p>\n
\u00a0 \u00a0 case<\/span> 'line'<\/span>:<\/span> return<\/span> transformToHighchartsLine<\/span>(data);<\/span><\/span><\/code><\/span><\/p>\n
}<\/span><\/span><\/code><\/span><\/p>\n
<\/code><\/p>\n
<\/code><\/p>\n<\/div>\n<\/div>\n
In practice, this switch<\/code> statement and the corresponding transformation logic lived inside a single class responsible for orchestrating chart rendering. Over time, this class accumulated multiple responsibilities:<\/p>\n