Executando verificação de segurança...
4

o que vai no front, o que vai no back?

esses dias me deparei com um certo questionamento enquanto desenvolvia um projeto de estudo, se trata de um gerenciador de finanças pessoais, bem simples, que de início possui somente a finalidade de registrar os seus gastos. acontece que eu precisava adicionar três abas para mostrar os gastos separados por tipo: a primeira aba mostra todos os gastos, a segunda mostra as que foram classificadas como fixo e a terceira mostra as que foram classificadas como variável.

a partir daí comecei a ter uma discussão interna: onde eu iria escrever essa lógica?

no início pensei em escrever no front, tendo em vista que, uma vez já feito a requisição no servidor e com os dados no cliente, a única coisa que eu precisaria fazer seria criar uma função que separasse os gastos de acordo com o tipo. mas aí começou a surgir as dúvidas, já que se tratava de uma regra de negócio, não seria melhor adicionar essa lógica no back? deixar o front com as manipulações de exibição? além disso, manipular elementos no DOM é bem complicado e se não for bem feito, pode gerar linhas e linhas de código. vale ressaltar também que precisamos levar em consideração variáveis como o público que vai usar o app e os dispositivos nas quais ele vai rodar, pois salvar os dados no cache do cliente seria um tiro no pé já que consumiria espaço e processamento do computador do usuário. o pensamento sempre deve ser em entregar uma solução performática e otimizada para os usuários, e ficar alocando espaço na memória do cliente talvez não seja a melhor opção.

obviamente, existe o outro lado em que encher o back de endpoints pode te causar uma dor de cabeça devido a perda de clareza, duplicação de código, escabilidade ruim, problemas de segurança e por aí vai. o bom é utilizar endpoints genéricos e parâmetros de query (algo que, inclusive, preciso corrigir no meu código). além disso, disparar várias requisições para o servidor pode ser um prejuízo financeiro dependendo do serviço utilizado (amazon, azure, google).

por isso é essencial ter uma visão holística do projeto e um planejamento bem estruturado, os primeiros passos são fundamentais para as decisões que serão tomadas posteriormente.

e você, o que acha disso? quais soluções você tomaria em um projeto de grande escala e uma de pequena escala? se faltou alguma coisa, algo para abordar, comenta aí e vamos trocar ideia!

Carregando publicação patrocinada...
1

Front: apenas visualização, Back: Todo o resto.

existe o outro lado em que encher o back de endpoints pode te causar uma dor de cabeça devido a perda de clareza, duplicação de código, escabilidade ruim, problemas de segurança e por aí vai.

Quanto mais genérico for seu endpoint mais parâmetros ele vai ter que aceitar, mais casos de uso ele vai ter que suportar, mais complexo ele vai ficar, a lógica é exatamente o contrário.

Quando mais específico for o endpoint mais fácil vai ser a manutenção, mais leve vai ser o processamento.

Essa história de fazer um endpoint com GraphQL para escalabilidade não tem nada a ver com performance, tem a ver com hora de desenvolvimento, quando as features precisavam ser lançadas o mais rápido possível.

GraphQL serve muito bem para contexto de redes sociais onde os dados podem ter as estruturas mais variadas possíveis, e o sistema tem que se adaptar a novas variações de forma muito rápida.

Um app de controle de gastos vai ter essa complexidade e variação toda?


não seria melhor adicionar essa lógica no back? deixar o front com as manipulações de exibição?

Aqui a pergunta é: De quantos dados estamos falando?

Se for poucos: separa no front

Agora se for muitos dados teria que trazer do back só o necessário, paginado e, no mínimo, com uma rolagem infinita, onde os dados são carregados conforme o necessário.

1

Quanto mais genérico for seu endpoint mais parâmetros ele vai ter que aceitar, mais casos de uso ele vai ter que suportar, mais complexo ele vai ficar, a lógica é exatamente o contrário.

entendi o seu ponto. acho que dá pra levantar umas hipóteses. por exemplo, eu pretendo criar novas features futuramente: jogo todas elas no back? eu levantei um ponto relacionado a clareza da API, o que você acha disso? acredito que colocar vários endpoints também é adicionar mais uma camada de complexidade ao código já que existe a chance de ficar confusa para quem consome.

eu só quero levantar essa discussão para entender a opinião de quem vê o post, porque acho muito interessante. no final do dia, tudo vai depender da complexidade do projeto. valeu pelo o comentário!

1

eu pretendo criar novas features futuramente: jogo todas elas no back? eu levantei um ponto relacionado a clareza da API, o que você acha disso?

Não tenho como responder essas dúvidas sem ver como seu projeto está estruturado. Isso é realmente uma dúvida que depende do contexto.

acredito que colocar vários endpoints também é adicionar mais uma camada de complexidade ao código já que existe a chance de ficar confusa para quem consome.

Aqui tem que haver uma separação, você está fazendo uma API pública para todos usarem, ou uma API privada para seu APP usar?

São coisas totalmente diferentes que devem ser arquitetadas de formas diferentes

Se for uma API privada, só para seu app usar, temos um pouco mais liberdade de aumentar a quantidade de endpoints para coisas extremamente específicas. 99% dos endpoints das apis dos meus apps só são chamadas em um único lugar.

1
1

Iai, tudo bom?

Interessante os pontos que levantou, acredito que na minha visão seria mesclar tudo que vc indagou até o momento e fazer caching.

Explicando melhor meu pensamento, se eu entendi bem, o problema gira em torno das classificações dos gastos, então você poderia fazer um endpoint no backend que retorna esses dados e adicionar um query para filtrar como vc deseja e a depender da variação desses dados fazer um caching do lado do servidor, outra possibilidade seria construir o mesmo endpoint e fazer o caching do lado do cliente, caso não queria utilizar muito recursos do usuário você faz caching dos dados que são de fato relevante pro cliente, talvez gastos de uma semana ou um mês.

Enfim, otimos pontos para discussão, queria escrever mais coisa, mas a pausa do trabalho ta acabando hehe.

1