Using client-side reports or server-side reports?

Question

When do we use client-side reports and when do we use server-side reports?

What reporting is best practice (client / server)?

This applies to SSRS reports.

Answer 1

Well ... the client side report that you use, if you have something like a winforms client that you cannot guarantee, will have constant access to the data source. It may have a set of client-side cached data that you need to report about, even if the connection to the server is unavailable.

Server-side reports that you will use in a scenario where you need to simplify the distribution and deployment of reports, because you simply deploy reports in one place and anyone can access them. This leads to the fact that a connection to the server is always required.

Answer 2

Client-side reports are also convenient when you have a client collecting data from a wide variety of sources. We have an internal corporate application that calls internal services for obtaining data from financial statements, as well as our separate production database and combines them into a single data set, which it passes to the ReportViewer control.

From an aesthetic point of view, it’s nice to integrate the report into the application so that the user does not feel that he is leaving the application to print or export application data.

Answer 3

Customer Site Report

If one of the following values ​​is true, you must use the client site report:

• If you have data only on the client, and not on the network or on the server. This mainly applies to desktop applications.
• No server (home systems).

Server Report

If one of the following values ​​is true, you should use the site’s site report:

• The data is on the server or in a static place on the network.
• You have only thin clients.
• Reporting should be planned.
• The cost of a license for one server is less than for many desktop installations.
• Report templates are shared and can change frequently.

Answer 4

It depends on what you call the "server" in this case. Since you mention SSRS, I assume that you are considering the database (SQL Server) as a server.

It all depends on the structure of the application and the project and the requirements. If you have a database that also contains business logic (storage procedures), and you just want to query the data and display / export it, then SSRS is convenient.

However, if you have a web application with your persistence level (database) that simply stores information and ensures information consistency, but then your business logic, for example, is in a web API (for example, a RESTful API project) that requests / supports database data (CRUD) and adds some logic, and then replies to HTTP requests with the requested results / information (i.e.: with JSON) to a rich interface, then I would add client-side reporting functions (front end) with , for example, the Javascript library executed in a browser that can display the extracted data in any way, it can export it to DOC, Excel, Email, etc.

Separation of problems for a typical web application:

• Database level for storing information and ensuring consistency
• business level (Back end RESTful API) to do all smart things on resources, computing, authentication, authorization for each HTTP request.
• Rich interface (Javascript + HTML + CSS) for user interaction and request / display information on the internal server. As part of the problem of displaying information, this interface will also generate reports.