Acredito que essa reponsabilidade de reendenizar o gráfico deve ser totalmente d · tiagosavioli

Em resposta a Desafios do backend (qual sua responsabilidade?)

Acredito que essa reponsabilidade de reendenizar o gráfico deve ser totalmente do client (Front-end), o Back-end somente recebe a requisição como por exemplo um http://api/v1.0/generate-graph e retorna a lista de dados que deve ser reendenizada no gráfico.

Exemplo:

[
  { "nome": "Categoria A", "valor": 25 },
  { "nome": "Categoria B", "valor": 40 },
  { "nome": "Categoria C", "valor": 15 },
  { "nome": "Categoria D", "valor": 30 }
]

Pelo menos eu faria isso, afim de não sobrecarregar a api com tarefas que claramente podem se executadas pelo front-end.

zetty

11 meses atrás

Mas náo é só isso que entra. Tem vários cálculos que, por exemplo, utilizam um serviço de cálculo em C++ criada pelos engenheiros daqui. Por isso que eu queria saber como é feito nas grandes empresas. São serviços separados? O backend só deveria ser responsável unicamente em lidar com o banco de dados e queries?

tiagosavioli

Autor

11 meses atrás

Bom, se você precisa fazer vários calculos complexos, é recomendado que seja feito em um serviço separado, porque o serviço principal da sua aplicação poderá continuar lidando com várias requisições simples, enquanto sua api de calculos poderia processar os calculos e somente quando estiverem prontos serem enviados ao client.

Fazendo desta forma, evitatoms que o serviço principal sofra gargalos colocando as requisições em uma fila enquanto processa os calculos para retornalos ao client

Outra vantagem de construir com serviços separados são as otimizações, você poderá escolher a linguagem e arquitetura que melhor se encaixa as suas necessidades, com muito mais liberdade do que se fossem feitos no mesmo serviço.

Espero ter ajudado.

andrebmachado

11 meses atrás

Acredito que esse desafio que esta enfrentanta seja de integração e uma alternativa seria um serviço de mensageria como RabbitMQ por exemplo.
Dessa forma você pode manter suas aplicaçoes desacopladas com um ponto em comum para trocarem dados. Isso favorece menor curva de aprendizado porque o RabbitMQ por exemplo e bem tranquilo, na escalabilidade do sistema, e suas equipes de devs ficam indepemedentes. Logico que pra isso e importante as equipes juntas elaborar uma padrao para troca de dados.

Empresas grandes com varias solucoes investem nessa alternativa para integrar suas diversas aplicaçoes, organizar e priorizar as tarefas em filas etc..

Talvez nao seja a melhor solução para o seu cenário mas considere isso.

Obs: O RabbitMQ funciona em docker o que facilita muito levantar o ambiente

Espero ter contribuido! ;)