Why did we decide to move all our reports preparation from In-Browser(client-side) to node server?

Photo by Bernd Klutsch on Unsplash

At fleetx.io we generate lots of reports for our customers. We provide these reports in different formats like CSV, Excel, and Pdf and we even customize these reports according to our client’s requirements.

For example Job Reports — job performance report, waiting job report, job summary report, etc. Vehicle Reports — cost report, fuel report, running report, driver behavior report, night driving report, etc Trips/History report- movement report, history report, timeline report, speed violation report, trip b/w sites report, stoppage report, etc. There are lots of other reports.we generate 100’s of these different types of reports.

Initially, we were preparing all of these reports in the browser only. And we have been doing this for a long time until we started facing many performance issues and few other usability complications.

side note: we maintain a node server for serving our react app and many other tasks like preparing reports and triggering other web-hooks.

So what were the issues we were facing in preparing reports at client-side(in-browser)

1. Since the javascript engine is single-threaded it means it does one task at a time. if we are doing all the computations to prepare a report in the browser, it will freeze the UI and the user won’t be able to do any interaction until report preparation is done. But on the server, we can run multiple nodes and can take advantage of node clustering(in case of node server)
2. Sometimes few reports need more computational power and memory so we can’t rely on user machines for that since the user’s device might not have enough memory or CPU power to do that. But servers are under our control we can increase CPU power or memory as required.
3. If a user wants the report but not immediately, the user might want it at some point later, so we might need to do scheduling of reports, that can’t be done in the browser. But at the server, it can be done easily.
4. We have seen a few errors caused by Blob size limitations( since we were using URL.createObjectURL(blob)). Download fails because the generated report size is more than the browser limited size. If we generate reports at the server we could just email them.
5. Even email servers/clients also impose a limit on the attached files or download files size. for example, Gmail limits to ~25MB. To solve that problem we upload the reports to the s3 bucket email the link to the user.

In a nutshell, at the server, we have a whole lot of options and more power to support big reports, and report scheduling is easy.

Found this useful? have a look these articles

Lean UX for the next generation fleet management startup — fleetx

Replacing react life cycle methods with react hooks

Is Spread Operator Always a Good Choice(In the Context of Performance) ??