Relatorios(Reports) em Aplicações SPA - Angular, VueJS, React

[abalad]

Venho nesse tópico abrir uma pesquisa de como vocês utilizam/criam relatórios em aplicações SPA.

• Quais Tecnologias utilizar ?
• Servidor de report ou apenas execução e conversão para PDF ?
• Criação de relatórios customizados pelo cliente ?

[willycamargo]

O que quer dizer exatamenet com reports? Qual o seu problema especificamente ?

Talvez a issue #345 possa ajudar

[abalad]

@willycamargo Reports seria relatórios de dados.

Exemplo: Você precisa tirar uma listagem de todas as vendas apresentar esses dados em formato de tabela de linhas e colunas, porem passando parâmetros de filtros (Periodo de vendas, Vendedor, etc)

[willycamargo]

Compreendi, @abalad . Então a issue #345 realmente pode te ajudar um pouco.

Tive uma experiência muito boa trabalhando nesse tipo de solução no MoskitCRM (inclusive bem parecida com o exemplo que você citou de vendas). Desenvolvemos muitos relatórios lá e todos eles possuem filtros que podem ser personalizáveis pelo usuário.

No geral a lógica é "simples":

1. Aplicação faz request para servidor do "Relatório X" com os "parâmetros Y".

2. Servidor retorna JSON no response.

3. Aplicação renderiza os charts e tabelas no browser utilizando os dados retornados pelo servidor.

• No front nós usamos MithrilJS (poderia ser qualquer outra lib frontend, React, Vue, Angular, etc).
• Para os gráficos utilizamos D3.js
• O backend está utilizando Grails

Acho que a tecnologia mais importante nesse caso é o D3.js. Tanto o MithrilJS quanto o Grails são ferramentas que não são tão relevantes para resolver esse problema em específico, então utilizar outra lib frontend ou outro framework no backend não iria influenciar tanto.

[kivervinicius]

@abalad uma boa solução caso tenha experiência em Java, seria montar os relatórios utilizando JasperReports (OpenSource) e fazer as chamadas utilizando um WebService para prover os relatórios. É o que utilizamos hoje a muitos anos mas utilizando Delphi e ReportBuilder.

[abalad]

Willy então a ideia foi basicamente isso mesmo. Porem me vem a dúvida... por se tratar de relatórios vai ser normal massas de dados gigantescas, com esse cenário Surge mais 2 dúvidas.

• Não seria um problema para o front renderizar toda essa massa de dados?
• Não seria melhor o servidor retornar um arquivo PDF já com o relatório pronto?

[feijaoguida]

O problema de o servidor gerar o PDF é que é "um" só servidor gerando várias requisições dos usuários, o que pode trazer alguma degradação para o seu servidor. Se você gerar no Front, ele é responsável por tratar os dados enviados pelo server.

[abalad]

kivervinicius Nesse caso ele retornara relatórios jah pronto em PDF? E teria também um Server report para gerar esses relatórios?

[willycamargo]

@abalad sobre suas dúvidas:

Não seria um problema para o front renderizar toda essa massa de dados?

Não foi um problema para nós. Os relatórios são bem específicos e a parte mais pesada esta no processamento disso do lado do servidor. O front está lidando muito bem com essa massa de dados. Mas claro que isso depende de qual vai ser essa quantidade de dados.

Não seria melhor o servidor retornar um arquivo PDF já com o relatório pronto?

Acredito que isso depende mais do tipo de problema que você quer resolver. Nós temos uma funcionalidade onde o usuário pode filtrar e depois exportar todos os dados filtrados em CSV e, a partir disso, gerar seus relatórios mais complexos por conta própria. Os relatórios gerados diretamente no sistema são visuais (gráficos) e não disponibilizados em PDF para o usuário (claro que ele pode imprimir a página se preferir).

[kivervinicius]

@abalad isso mesmo, ele já retorna ou um stream ou um pdf já pronto. Toda a regra de negócio teria que estar na sua aplicação server. E sua api somente consumir. No nosso caso temos diversas aplicações em diversas linguagens e isso unifica a geração de relatório...