Quando o Front-end e o Back-end Trabalham em Conjunto e a Aparição do DevOps

Fala, Dev. Já pensou em criar uma aplicação completa?

Na hora do desenvolvimento, pode ser difícil pensar em tudo que envolve.

Por isso, vou te mostrar um pouco do que ocorre.

Geralmente, temos um responsável pelo front-end, para criar a parte que o usuário irá interagir. Assim como, teremos um responsável pelo back-end, que implementará a lógica do negócio, com o armazenamento de dados, segurança, restrição de acesso e mais.

Entretanto, quando falamos de validação... podemos pensar em evitar problemas desde o usuário final, a interação com o front-end, até o último processo de manipulação dos dados no back-end.

Por isso, imagine um site de cadastro com vários campos... nome, idade, sexo... será que o processo de validação só deve ocorrer no back-end? Será que devemos confiar apenas nesta parte e aceitar toda solicitação sem validar os mesmos dados ?

Por isso, temos as etapas de validação. O front-end pode nos ajudar, fazendo um processo simples de validação nos campos, mas não vejo como algo necessariamente obrigatório, para a função de front.

Validando os campos no front-end, aceleramos o tempo de resposta e a correção dos dados. Caso o contrário, o usuário precisará esperar a solicitação chegar no back-end, para que haja a primeira validação e assim, solicitar a correção dos dados preenchidos.

O back-end precisa validar os dados preenchidos, no momento da requisição, para disponibilizá-los a parte do código que interage com a lógica do negócio. Assim como, a validação também precisa acontecer no momento do armazenamento de dados, no banco de dados, e também, nos momentos de atualização e remoção dos mesmos.

Quando o programador é Full Stack e o projeto é todo seu, então, fica mais fácil de criar todos os processos de validação. Mas, quando a divisão de tarefas vai uma parte para o back-end e uma para o front-end, podemos pensar dessa forma (validar no front-end, para auxiliar o back-end).

Mas, qual o resultado disso? Se a validação já aconteceu no front-end, logicamente, haverá menos validações/comparações no back-end, pois com os campos preenchidos corretamente, as estruturas condicionais passam mais rápido nos testes e já retornam a resposta desejada.

Mas, por que um front-end iria se preocupar a fazer tal validação? A parte dele não é apenas criar a parte que o usuário irá interagir, tal como, o html, css, javascript, reactjs/angular para pegar as informações dos campos e requisitar respostas via consumo de API?

Realmente, criar o front-end pode ser um trabalho grande, a depender da aplicação... mas, saber fazer validações mínimas no front-end, pode ser um diferencial para a velocidade de resposta da aplicação (otimização).

Mas, independente de ter uma validação no front-end ou não, o back-end tem que prever situações, criar as lógicas e garantir o bom funcionamento da aplicação, retornando respostas úteis, para o front-end.

Depois de ter essa visão, hoje em dia, lembro-me de situações em que utilizei sistemas de prestadores, que no front-end aparecia uma mensagem de erro SQL. Na época, não entendia o motivo, de um erro SQL aparecer no front-end, pois, só queria utilizar um sistema que funcionasse e que os demais usuários conseguissem utilizar sem problemas.

Esses erros chegavam até mim, por na época, eu ser a ponto de ligação entre os usuários do sistema e os prestadores.

Mas, hoje, está bem claro. Não havia validação no front-end em tais sistemas. Essa reposta de erro SQL, poderia ser reescrita pelo front-end de uma forma mais amigável. Mas, como não é obrigação do front-end saber banco de dados, como o front-end iria escrever de forma mais amigável?

Logo, o back-end precisaria tratar melhor as respostas que são repassadas ao front-end.

Hoje, percebo que se no front-end, tivesse uma simples validação de campo, identificando que possui um texto acima de 255 caracteres, e já retornasse ao usuário que o texto não pode ser maior que isso, ou evitasse que o texto fosse adicionado caso chegasse nesse limite, não haveria a necessidade de uma requisição http ser feita, e então, na lógica do back-end, o conteúdo chegar até o banco de dados, para identificar tal erro, simplesmente, pelo tamanho do campo da tabela do banco de dados ser 255 caracteres, e então, ser retornado em forma de mensagem não tratada, um erro SQL, para o front-end, que por sua vez, só a apresenta na tela.

Logo, o que o usuário vê? Um monte de letras estranhas, escritas em inglês, marcadas com uma tarja vermelha, sem saber o que fazer, e por isso, o serviço ficar inoperante.

O que o usuário poderia fazer para corrigir se visse uma mensagem amigável? Apagar alguns caracteres e deixar o conteúdo do texto mais objetivo, com menos de 255 caracteres. Muito louco né?! rsrs

Hoje, quando penso nisso, só consigo imaginar que as duas equipes não interagiam bem, a ponto de testar e ver resultados assim. Sendo necessário que o usuário final, veja o erro, tire uma foto, acione o suporte, que por sua vez aciona a equipe de desenvolvimento, para atualizar um sistema em produção.

A depender da empresa e da forma como o sistema esteja hospedado, seria preciso parar a aplicação, deixar todo o sistema inoperante, para subir a atualização da nova versão da aplicação.

Quando a empresa tem uma equipe de boa, com um DevOps, a nova atualização se torna parte de um container, que pode ser gerado com o Docker, que pode ser orquestrado por uma tecnologia, tal como a Kubernets.

Sendo assim, a atualização sobe e o usuário nem perecebe. A aplicação não precisa parar, o sistema fica operante, recebe as atualizações e todo mundo fica feliz.

Bem louco, mas real.

Por isso, temos um conflito... que para funcionar corretamente, podemos garantir que a nossa parte seja feita da melhor forma. Tal como, tratar as mensagens de erro da melhor forma, para que seja útil para o front-end, já pensando como seria se elas chegasse no usuário final.

Entretanto, só tenho essa visão por saber como funciona os três lados (back, front e devops) e o que acontece por baixo dos panos da aplicação.

Se a empresa não tiver uma equipe bem estruturada, a aplicação sairá do ar em vários momentos. Se tiver, será mais fluida as atualizações.

Se a equipe não interagir bem, serão mais erros a serem tratados em produção, e isso, não é algo desejável, pois pode gerar prejuízos para o cliente. Imagine perder uma venda de um produto, por o campo e-mail não possuir um @. Loucura né?!

Mas, já vi sistemas perderem vendas ou terem as suas aplicações paradas, gerando mais perda de vendas, por erros que poderiam ser evitados.

Testes unitários, testes de carga, cenários caóticos, são ótimos para gerar boas reflexões na hora do desenvolvimento, interação com os colegas de trabalho, e gerar uma solução tecnológica robusta e de valor.

E você, já viu algum erro desse tipo em alguma aplicação?

Hoje é engraçado de pensar no assunto, mas aposto que a galera do suporte, front-end e back-end não achavam isso, quando recebiam os chamados com os prints.

Ps.: Não é uma critica, pois sabemos que cada categoria possui as suas responsabilidades. Só achei interessante o caso, e devido as experiências atuais, comecei a pensar no assunto.

Espero que gostem da visão.