A tecnologia está sempre evoluindo e o Colab também! Neste artigo, o Gabriel Eloy conta como está sendo todo o processo de reconstrução e aperfeiçoamento do Colab Gov, nossa ferramenta para governos.
O Colab está reformulando vários de seus produtos, tornando-os ainda mais coesos, rápidos e seguros.
O Gov, nosso projeto voltado para uso interno nas prefeituras com o intuito de interagir com as demandas e reclamações feitas pelos cidadãos, não poderia ficar de fora disso e, durante esse artigo, explicarei as mudanças que serão realizadas, bem como seu impacto para o funcionamento do projeto.
Originalmente, o Colab Gov foi criado em um contexto diferente, tecnologicamente (principalmente), na visão do produto e nos seus próximos passos.
Esse contexto diferente levou à tomada de decisões, que embora fizessem sentido no momento em que foram feitas, levaram o projeto por caminhos difíceis de serem revertidos, tornando a tarefa de adequar o projeto antigo às novas ambições do Colab um processo lento, complicado e delicado para o time de desenvolvimento manter.
Nós percebemos que precisávamos dar alguns passos para trás, avaliar os aprendizados que tivemos com a arquitetura atual e utilizar esse conhecimento para elaborar novas soluções que tornem a experiência geral do produto melhor como um todo.
Algumas tecnologias serão substituídas por outras mais novas e mais poderosas, mas a maior mudança está na maneira como construiremos essa nova etapa do Gov.
Cada uma das mudanças propostas, foi extensivamente pensada para resolver uma dor específica causada pela arquitetura atual.
Embora algumas escolhas passadas não façam mais sentido hoje em dia, outras foram tiros muito certeiros que serão repetidos, mas com alguns "temperos" diferentes. A melhor dessas escolhas foi o framework para o front end, que foi o React, criado pelo Facebook. O React é uma biblioteca incrível, com um rico ecossistema que é amplamente utilizado.
Apesar de possuir uma curva de aprendizado inicial um pouco mais complicada do que a de outros frameworks e bibliotecas como Vue e Angular, o framework do Facebook se adequa muito melhor às nossas necessidades e visões de projeto, tornando a implementação de algumas escolhas arquiteturais tremendamente mais simples.
Mas apesar de re-apostar no react, nós decidimos que o utilizaremos com typescript ao invés de javascript, já que o typescript é uma linguagem tipada, que tornará o projeto menos suscetível à erros.
Em seu estado atual, a aplicação não nos traz segurança durante seu desenvolvimento. Isso quer dizer que muitas vezes ao fazer grandes mudanças na estrutura do projeto, a equipe de desenvolvimento despendia uma grande quantidade de tempo testando e re-testando todos os componentes que foram atingidos pelas mudanças que fizemos.
Por sorte, esse é um problema universal, e por isso existem diversas soluções já desenvolvidas para isso, além de abordagens amplamente aceitas e testadas pela comunidade em outras aplicações.
Se você está habituado(a) ao ecossistema ferramental do javascript, você muito provavelmente já ouviu falar em uma biblioteca chamada Testing Library (ou suas variações e adaptações para bibliotecas / frameworks específicos, como a react testing library, angular testing library, vue testing library etc).
A biblioteca é interessante por possuir uma série de diretrizes e opiniões fortes que guiam a direção de seu desenvolvimento, e definem como ela deve ser usada do que por qualquer outro motivo.
Seu criador, Kent C. Dodds acredita que (de maneira extremamente resumida) o número de testes geral de uma aplicação deve estar concentrando em testes de integração, já que estes são os testes com melhor custo benefício entre confiabilidade ganha (garantia de funcionamento) e custo computacional gasto para realizá-lo (uma métrica importante, já que na prática ela se traduz para quanto tempo gastaremos rodando esses testes).
Se você não sabe o que são testes de integração, nem os outros tipos comuns de testes, e como eles normalmente se distribuem numa aplicação, eu sugiro a leitura do incrível artigo da Camila Campos sobre pirâmide de testes, no qual ela explica magistralmente sobre conceitos básicos de testes de aplicações.
Entretanto, mesmo com seu custo benefício incrível, os testes de integração não são capazes de cobrir sozinhos todos os possíveis erros de uma aplicação, e é aí que os outros integrantes do "troféu de testes" entram. Contando com ferramentas de checagens estáticas de código para evitar erros mais triviais e com outros tipos de teste, como o unitário, para garantir o funcionamento de peças "individuais" da aplicação, bem como testes e2e (end to end) para garantir que a aplicação funciona como um todo pelas razões descritas acima, decidimos usar typescript como linguagem juntamente do ESlint para garantir a checagem estática do código do projeto. E para fechar, utilizaremos a Testing Library + Jest para realizar nossos testes
Atualmente, o nosso processo de descoberta de erros na aplicação é o seguinte:
Desta forma, a nossa detecção de erros fica totalmente dependente de relatos de terceiros (clientes), gerando assim alguns possíveis problemas, sendo eles:
- Um erro pode ocorrer N vezes até que ele seja finalmente reportado, possivelmente frustrando vários usuários antes de sua resolução;
- Não existem métricas sobre quantos erros de fato ocorrem, e sim de quantos erros são reportados;
- Os erros reportados possuem as informações reportadas a nós, que usualmente são insuficientes para uma reprodução efetiva do problema. Isso faz com que sempre que há um erro, seja necessária investigação adicional do time de desenvolvimento ou até, em alguns casos, diversos contatos com o cliente que reportou o problema.
Esses problemas podem ser resolvidos utilizando o Sentry, uma ferramenta de monitoramento, focada na identificação de erros. Quando bem utilizado, o Sentry traz a visibilidade de todos os erros que ocorrerem dentro do nosso projeto, com uma riqueza de detalhes muito maior do que a normalmente dada pelos usuários
Essa riqueza de detalhes permite que as mudanças deixem de ocorrer de maneira reativa, e passem a ser feitas de maneira ativa, com o time do Colab catalogando e corrigindo os erros ocorridos de uma maneira sem precedentes.
Embora existam técnicas dos mais diversos graus de requinte para a optimização de aplicações web, ela é composta por passos simples, que requerem muito cuidado e zelo em sua utilização, já que se forem aplicados na medida errada podem afetar em muito a qualidade da aplicação.
A maioria absoluta das técnicas de otimização para aplicações cai em uma das seguintes categorias:
- Deixar de realizar operações desnecessárias;
- Adiar a realização de operações não essenciais;
- Realizar operações já existentes de maneira mais rápida e eficiente.
Embora quando ditas desta maneira essas tarefas sejam triviais, realizá-las com maestria é uma tarefa tão desafiante quanto recompensadora.
Existem diversas maneiras de atingi-las, cada uma com seus prós e contras. Algumas das escolhidas por nós foram:
O cache nada mais é do que um depósito de informações que fica armazenado localmente, para que futuramente sejam acessadas desse armazenamento local e não da fonte original das informações.
Isso tende a tornar aplicações extremamente mais rápidas, mas em troca de um custo. Se a informação original muda e o cache não é atualizado, as informações da aplicação podem ficar defasadas. E é por isso que informações “cacheadas” devem ser utilizadas e atualizadas com muita parcimônia e é justamente por isso que essa abordagem será utilizada de maneira muito conservadora na nossa aplicação.
O plano de utilização do cache é validá-lo majoritariamente para aumentar a performance percebida pelo usuário por meio de uma estratégia chamada stale-while-revalidate, que em uma tradução livre significa "mostrar obsoleto enquanto revalida", que consiste basicamente em mostrar informações guardadas em cache, que podem estar desatualizadas, enquanto busca as informações novas da fonte original.
Outra novidade que tornará a experiência do novo Gov interessante, é que ele será um PWA, que é um tipo de aplicação web que possui características de aplicativo mobile. Além de ser mais rápido que uma aplicação normal e funcionar sem conexão à internet, um Progressive Web App também permite o envio de notificações push para os usuários.
Essas são algumas das mudanças e melhorias que serão trazidas para o novo projeto do Gov, que está previsto para o primeiro trimestre de 2021.
Todo o time do Colab está muito ansioso para o lançamento deste projeto e para as mudanças positivas que ele trará para os nossos usuários!
Desenvolvedor Full stack no Colab, apaixonado por dar vida a produtos que impactem a vida das pessoas e conhecer pessoas incríveis no meio do caminho. Também acredita que "Você é tão grande quanto a sua vontade de mudar o mundo".
%20(2).png)
