Gerando relatórios complexos, a saga!
Já trabalhei com diferentes tipos de geração de relatórios, simples e extensos, complexos porém curtos e os mais devastadores: complexos e extensos. num contexto de desenvolvimento web, onde o usuário possa querer imprimir por algum motivo todos os dados gerados, qual o limite do bom senso?
O que é ideal para o usuário de um Erp web? quantos registros ele quer ver em tela? a paginação pode interferir na impressão desses registros? Qual o indicador para que este relatório seja processado de forma paralela?
Posso passar a considerar: “Se não dá timeout tá bom” ou até mesmo: “Na média isso funciona para todo mundo”. Neste contexto, comecei a rabiscar algumas alternativas para geração de relatórios complexos, provavelmente existem soluções melhores (pois não investiguei a fundo e este é um problema rotineiro), porém juntei alguns estudos de AWS, e cheguei em uma possível solução:
Minha ideia com esta proposta inicial de arquitetura é explorar cada ponto e conseguir responder o porquê de cada coisa, avaliando preço, alta disponibilidade e escalabilidade. Um texto explorando cada possibilidade talvez. Posso explorar a azure também. Acredito que o imutável nessa proposta é a necessidade do relatório e possivelmente o banco SQL (Poderia ser SQL Server ou MySql) pois pensando em aplicações convencionais a maioria lida com bancos relacionais.
A lógica geral tem 3 partes: Client solicita a geração desse relatório, ele é processado e o resultado em JSON é armazenado em uma base NoSql (neste momento mongo, porém poderia ser um Cassandra, ou talvez um elasticSeach?) e o Client é avisado via email que o relatório já está pronto para ser acessado. Nesse contexto o usuário poderia fazer uma busca simples no banco, trazendo todos seus relatórios já gerados.
A aplicação cliente está em angular porque sim, poderia ser qualquer outra.
Neste contexto, a solicitação do cliente por um novo relatório, faz a chamada de uma api rest que aciona um AWS Lambda, este Lambda adiciona a solicitação em uma fila utilizando o AWS SQS e esta fila aciona um segundo lambda que busca os dados necessários no banco de dados relacional e armazena os dados processados no banco de dados NoSql para quando solicitado pelo Client este seja retornado por meio de um terceiro lambda.
Uma limitação já de cara desta proposta é o tempo de processamento do relatório, pois caso ele precise de mais de 15 minutos para ser gerado, as configurações do lambda não suportariam (https://docs.aws.amazon.com/whitepapers/latest/serverless-architectures-lambda/timeout.html)
Abordarei inicialmente a configuração do API Gataway + Lambda + SQS, possivelmente em duas partes, uma avaliando as estratégias outra mostrando um pouco do resultado.
Tecnologias Citadas:
AWS Api Gataway
https://aws.amazon.com/pt/api-gateway/
AWS Lambda
https://aws.amazon.com/pt/lambda/
AWS SQS
https://aws.amazon.com/pt/sqs/
PostgreSQL
https://www.postgresql.org/
MongoDB
https://www.mongodb.com/
.Net 5
https://dotnet.microsoft.com/
Angular
https://angular.io/
