Data oversized issue when implementing pivot table with custom api

Hello!

Thank you for reaching out to us.

As an entry point, let us explain how Flexmonster works with data when using our custom data source API.

Our custom data source API is a communication protocol that specifies in which format Flexmonster client can communicate with your server. In two words, the server would receive 4 types of requests from Flexmonster - /handshake, /fields, /members and /select.

When using a classic/compact pivot grid, the server sends only aggregated values to the browser, which reduces the browser load significantly. This way, you can control all the data processing and calculating on the server side and optimize it according to your requirements, and the client would only visualize the data you provided from the server.

From our experience, implementing custom data source API with your own server would be the best approach for the tech stack you described. You are welcome to start with checking out our introduction guide on the topic: https://www.flexmonster.com/doc/introduction-to-custom-data-source-api/.

For other performance improvements on such a large dataset, we suggest breaking down the dataset into smaller reports with pre-configured filters and slices instead of aggregating all the data into one large pivot.

Hope you will find our answer helpful.
Our team would be happy to assist you if you have any other questions about the custom data source API.

Kind regards,
Solomiia

Hello, Jhshin!

Thank you for getting back to us.

Kindly note that the provided advice to break down the dataset into smaller ones was more generic.

From our experience, there are often cases when users need only a part of the data for their analysis, and many of our clients are adding their own UI controls before loading the data into Flexmonster. The idea is that their end users can use these controls to select which data they need to see, and thus narrow down the dataset.
For example, if you have dates in your data, users can choose the desired timespan, and then you'll need to load only the current month's data, instead of all the records in the database. This approach benefits both sides - the end-users are not struggling with loads of unnecessary data, and the browser's resources are used more efficiently.

Of course, the approaches to implement such behavior may vary depending on the use case, and we have described only the general idea. If you want more case-specific advice, please provide us with more details about your use case.

Looking forward to hearing from you.

Kind regards,
Solomiia