DEV Community: Tino Tech | Blog de tecnologia do Tino

Do clique à estratégia: como usamos o Snowplow Analytics para emitir e capturar eventos de clique

Diana Regina — Thu, 05 Sep 2024 04:06:12 +0000

Descubra como utilizamos o Snowplow, uma ferramenta de rastreamento de sites e aplicações para tomar melhores decisões de negocio e produto aqui no Tino.

O Snowplow Analytics é uma ferramenta open source destinada a coleta, armazenamento e analise de dados em sites e aplicativos, disponível tanto para linguagens do frontend como backend.

Conseguimos gerar uma série de eventos para monitoramento de click, acesso a página, envio de formulário, entre outros. O snowplow faz um enriquecimento desses eventos disponibilizando dados como data e hora de coleta, tipo do dispositivo, cookies, IP e geolocalização.

Esses dados podem ser enviados para uma data warehouse como a Amazon Redshift ou Google BigQuery para uma analise mais detalhada, sendo possível realizar integrações com outras ferramentas como o Excel ou Looker Studio para divulgar esses dados em forma de relatório ou dashboard e gerar insights sobre o negocio.

Porque o Snowplow Analytics impulsiona nosso business

O Tino é um meio de pagamento pro B2B que está buscando seu product marketing fit, ou seja, está buscando desenvolver um produto que atenda às necessidades e desejos dos clientes-alvo, e ter dados para entender o comportamento, otimizar fluxos, melhorar o produto e identificar oportunidades de mercado é essencial nesse processo.

Um exemplo de como usamos o snowplow foi na edição de notas fiscais dos pedidos feitos pelos lojistas para fornecedores pagos via Tino. Foi desenvolvido um fake door, uma técnica utilizada para entender o interesse dos usuários por uma determinada feature, e utilizamos os eventos de click do snowplow para metrificar esse interesse.

Após a coleta e analise dos eventos, foi possível validar a hipótese de que os clientes tinham interesse em ter essa funcionalidade e por tanto, foi implementada no produto.

Configuração e emissão dos eventos (quick tutorial)

1. Instalação das dependências

O primeiro passo é instalar a dependência do snowplow:

pnpm add @snowplow/browser-tracker

Depois, instale o plugin para emissão de eventos de clique:

pnpm add @snowplow/browser-plugin-button-click-tracking

2. Configuração do evento

Nessa etapa chamamos o tracker do snowplow com newTracker() chamando 3 parâmetros correspondentes ao id do tracker, a URL do site que será monitorado e as configurações. Dentre elas o id da aplicação e um array de plugins, que levará o plugin para trackear todos os botões da aplicação.

import { newTracker } from "@snowplow/browser-tracker";
import { enableButtonClickTracking, enableButtonClickTracking } from '@snowplow/browser-plugin-button-click-tracking';

newTracker('sp1', '{{collector_url}}', {
   appId: 'my-app-id',
   plugins: [ ButtonClickTrackingPlugin() ],
});

enableButtonClickTracking();

Por padrão, o snowplow vai considerar o texto do elemento como identificador do evento. Essa prática é ruim porque o monitoramento se torna muito sensível a uma mudança de UI. Se mudarmos o texto para “Baixar Nota Fiscal” por exemplo, o identificador do evento será alterado.

Uma prática interessante para evitar essa problema de mudança é usar o parâmetro data-sp-button-label, que funciona como uma especie de id para o snowplow nomear os eventos de clique a partir dele e não do texto.

<button data-sp-button-label="download-nf">Baixar NF</button>

Parceria entre produto, engenharia e analytics

A preocupação com o monitoramento do produto é algo que temos como premissa aqui no Tino, por tanto, é um trabalho feito a várias mãos entre o time de produto, engenharia e dados. Partimos da nossa principal métrica para avaliar o crescimento da empresa, o TPV, que corresponde ao valor total das transações processadas, isto é, quanto mais se paga com o Tino, maior é esse valor.

Temos metas de TPV a serem batidas todos os semestres e o papel de produto é pensar em quais alavancas podem aumentá-lo. Um exemplo de alavanca seria aumentar a quantidade de compras pagas usando Tino, porém existem casos onde as pessoas abrem o checkout mas fecham sem finalizar.

A partir dessa dor precisamos entender, são pessoas que precisaram passar por um cadastro antes? A forma de pagamento oferecida não é adequada? Ela não tem limite suficiente? Para responder essas perguntas, precisamos de dados.

Cabe a engenharia ajudar o time de produto a entender quais métricas/eventos já temos para responder essas perguntas e se não, o que precisamos fazer para responde-las. Dado que temos o monitoramento funcionado, o time de dados faz a extração dos dados, que junto do time de produto poderá gerar dashboards e relatórios para gerar insights para responder aquelas perguntas.

Obrigada por chegar ao final da leitura! Espero que esse artigo tenha contribuído para o seu conhecimento sobre Snowplow. Caso tenha algum feedback ou queria contar como sua empresa monitora seus produtos, por favor coloque nos comentários :)

Se você deseja fazer parte do time que busca fazer com que empreender seja uma missão menos impossível, vem pro Tino!

Referências:

O impacto das PWAs no desenvolvimento de apps

Gabriel Teodoro — Wed, 31 Jul 2024 14:51:09 +0000

Progressive Web Apps (PWAs) têm se destacado como uma abordagem poderosa para combinar as melhores características das aplicações web e das aplicações móveis nativas. Com a capacidade de oferecer uma experiência de usuário rápida, confiável e engajadora, as PWAs são uma escolha popular para muitos desenvolvedores que buscam alcançar um público amplo, independentemente do dispositivo ou plataforma.

O que são PWAs?

Progressive Web Apps são aplicações web que utilizam tecnologias modernas para proporcionar uma experiência nativa aos usuários. Elas são:

Progressivas: Funcionam para todos os usuários, independentemente do navegador escolhido, pois são construídas com aprimoramento progressivo como princípio fundamental.
Responsivas: Adaptam-se a diferentes tamanhos de tela e dispositivos, oferecendo uma experiência consistente e otimizada.
Conectadas: Utilizam Service Workers para funcionar offline ou em conexões de rede instáveis.
Seguras: Servidas via HTTPS para garantir que o conteúdo não seja interceptado e manipulado.
Engajadoras: Podem ser instaladas diretamente no dispositivo do usuário, permitindo acesso rápido e direto, sem necessidade de passar pela loja de aplicativos.

Benefícios das PWAs

Desenvolver PWAs oferece diversas vantagens, incluindo:

Acessibilidade: Ampliam o alcance da aplicação para uma base de usuários mais ampla, incluindo dispositivos com conexões de internet mais lentas.
Economia de espaço: Não ocupam espaço significativo no dispositivo do usuário, como as aplicações nativas.
Atualizações automáticas: As atualizações são aplicadas automaticamente, proporcionando uma experiência sempre atualizada.
SEO amigável: São facilmente indexáveis por mecanismos de busca, melhorando a visibilidade online da aplicação.

Tecnologias e Práticas Recomendadas

Para desenvolver uma PWA eficaz, é importante considerar:

Manifesto Web: Criação de um manifesto web (manifest.json) para descrever a aplicação, incluindo nome, ícone, cores temáticas e outras informações relevantes para a instalação na tela inicial dos dispositivos móveis.
Service Workers: Implementação de Service Workers para gerenciar o cache e oferecer funcionalidade offline.
Responsividade: Garantia de que a aplicação seja totalmente responsiva, utilizando media queries e técnicas de design responsivo.
Segurança: Garantia de que a aplicação seja servida via HTTPS para proteger os dados dos usuários e garantir a integridade das informações.

Como usamos no Tino esse recurso?

Tinhamos aqui no Tino uma dúvida sobre o interesse do usuário a baixar ou utilizar algum aplicativo, utilizamos o PWA como um recurso rápido e barato para experimentar essa hipótese.

Primeiro implementamos as configurações mínimas para o PWA funcionar e com uma boa experiência para instalação, infelizmente somente para android é possível criar uma experiência mais fluida onde um botão na tela permite executar o processo de instalar o App.

Algumas semanas depois mais de 30% dos nossos acessos já eram através do PWA instalado no celular dos nossos usuários, comprovando assim um forte interesse a adoção e uso de um App, guiando nossas escolhas de produto por impacto e valor gerado.

Conclusão

Desenvolver aplicações PWA permite aos desenvolvedores oferecer uma experiência de usuário de alta qualidade que combina o melhor das aplicações web e nativas. Ao adotar as melhores práticas e tecnologias modernas, é possível criar PWAs que não apenas atendem, mas superam as expectativas dos usuários em termos de desempenho, confiabilidade e usabilidade.

Este caminho de desenvolvimento não apenas melhora a acessibilidade e a experiência do usuário, mas também simplifica o processo de distribuição e manutenção da aplicação em diferentes plataformas e dispositivos.

Design System e Tokens no Tino

Robson Mathias — Wed, 17 Jul 2024 19:07:42 +0000

Imagine a seguinte situação: uma engenheira e um designer estão construindo uma aplicação juntos. A desenvolvedora pergunta:

— Qual vai ser a cor e fonte do botão?

Em resposta o Designer diz:

— É a mesma da Brand, #FF7A00 e a fonte pode ser a Inter…

Basicamente é isso que vai acontecer se não utilizarem algum nome que sirva de referência para as duas pessoas. Essas referências chamam-se Design Tokens.

O que é um Design Token?

É uma Variável semântica de estilo, um termo atribuído pela Meiuca Design.

Variável — Que pode ser variado ou mudado; mudável — Definição por Michaelis

Semântica — O significado dos vocábulos, por oposição à sua forma — Definição por Michaelis

Agora imagine novamente a situação proposta anterior:

A desenvolvedora pergunta:

— Qual vai ser a cor e fonte do botão?

Em resposta o Designer diz:

É a mesma da Brand, PalettePrimaryMain e a fonte pode ser a FontFamilyDefault.

Agora até mesmo para quem não é uma pessoa desenvolvedora, as definições fazem sentido, basta um conhecimento básico de inglês.

No que isso ajuda exatamente?

Basicamente na organização e escalabilidade de times. Aqui no Tino, queremos facilitar a vida dos Designers e Desenvolvedores. Quanto maior o nosso time fica, mais componentes criamos. Os Design Tokens permitem que alteremos propriedades dos nossos elementos de uma forma mais rápida, além de facilitar a comunicação entre as pessoas.

Os Design Tokens podem ser declarados de várias formas: JSON, folha de estilos, XML e etc. Nós optamos por utilizar um recurso de composição dinâmica que nos permite exportar para qualquer formato que nosso produto precisa — só esse processo já vale um post a parte sobre como funciona e como construímos esse ecossistema!

Regras e composições de Design Tokens

Para ajudar com a semântica, criamos uma estrutura que ajuda a compor melhor os nomes dos nossos tokens. Essa estrutura segue uma hierarquia e ordem que deve ser respeitada. Ela é composta por seis definições:

Grupo — Componente — Categoria — Variante — Propriedade — Estado

Essas definições são colocadas como um guia para ajudar a compor os nomes. Não é preciso preencher todos esses requisitos, somente Grupo e Variante são obrigatórios.

Vamos entender melhor cada item dessa estrutura:

Grupo — Identificador principal que agrupa um conjunto de elementos da mesma família, exemplo: (Button, Typography, Label etc.)

Componente — Elemento que possui um ecossistema complexo, que possui comportamento e filhos, como (ButtonOutline, LabelOutline).

Categoria — Modelo de um componente. Um componente pode possuir mais de um modo de exibir comportamento, como (ButtonOutlinePrimary, LabelOutlineSecondary).

Variante — Ao pensar em variante, pensamos em uma interação direta aplicada ao componente que faz variar seu estilo, como (Hovered, Pressed, Disabled).

Propriedade — Um componente pode possuir propriedades relacionadas, como (Icon, Label, Text, Item).

Estado — É a parte mais baixa da definição, muitas vezes relacionada ao valor ou situação do elemento naquele momento, (Color, Size, LetterSpace, Margin).

Acordos e definições

Como garantir que os designers e desenvolvedores criem novos Design Tokens sem fugir de nomes e estruturas similares aos demais? A solução para isso foi adotarmos acordos para garantir que criaremos no mesmo formato. Vamos listar alguns exemplos:

Valores de escalas

Breakpoints (T-shirt format alias): xl, lg, md, sm, xs.
Size (T-shirt format): XSmall, Small, Large, XLarge, 2XLarge, etc… .
Colors (Bounded Scale): 50 ,100, 150, …900, A100, A200, A400, A700.
Main colors (Terms): Light, Main, Dark, ContrastText.
Elevations, Shadows(Intervals): 0, 1, 2, 3…

Escrita

Escrever verbos no passado.
Evitar nomes compostos.
Não utilizar valores numéricos em Grupo.

Construindo componentes com Design Tokens

Um componente é composto por design tokens. Para facilitar a leitura chamaremos apenas de tokens. Durante a composição do Design System identificamos que muitos componentes possuem tokens similares. Para garantir a consistência desses tokens, decidimos aplicar um padrão de herança, onde permitimos que cada componente possua tokens customizados, mas qualquer outro token que seja igual, precisa fazer referência de uma mesma fonte que chamamos de Foundation. Exemplo:

Essa separação entre Foundation e Components garante na nossa estrutura centralizar os pontos de mudanças, sem perer o poder de customizar cenários específicos.

Documentando componentes

Utilizamos Storybook, tanto para documentar componentes quanto para documentar os tokens dos componentes. É o que parece mesmo, separamos em pacotes diferentes, um pacote de apenas tokens sem elementos visuais, somente variáveis e valores, e cada outro componente ou família de componentes possui um pacote isolado, mas todos fazem referência ao pacote de Tokens, assim gerenciar versões isoladamente dos elementos.

Cada pacote possui um storybook para si (falaremos melhor sobre esse ecossistema em uma publicação futura). No caso do pacote de tokens, tivemos que criar um storybook addon, para exibir e registrar a descrição dos valores, exemplo:

E como funciona entre o Figma e o Código?

Nosso objetivo como fundação do Design System é estabelecer um acordo que tanto desenvolvedores quanto designers evitem quebrar. Não poderia ser apenas um documento escrito, pois isso não se sustentaria a longo prazo. Por isso, criamos algo que ofereça vantagens reais para ambos os lados ao seguir e adotar o sistema.

Desenvolvemos uma biblioteca com um algoritmo que extrai informações de estilo de um documento do Figma através de suas APIs. Isso permite acessar todas as informações de estilos, nomes e vetores disponíveis em um documento.

Com os valores dos estilos e as regras semânticas mencionadas no início desta publicação, conseguimos criar um elo que se estende do Figma ao código front-end. Em outras palavras, a mudança ou adição de um token publicada no Figma gera uma PR (pull request) em um repositório com os novos valores em código CSS, SASS, Typescript, Dart, ou qualquer outra linguagem. Os front-ends podem então aprovar e publicar esses valores como pacotes privados para nossa organização. Isso mesmo, não precisamos que um desenvolvedor seja acionado para adicionar um novo token ou ícone; conseguimos extrair tudo automaticamente por API e Webhook do Figma.

Se quiser saber mais sobre como isso funciona, siga a página do Tino. Em breve, explicaremos essa biblioteca e os fluxos com mais detalhes.

Cebolas e camadas para padrões de projetos no Front-end — Parte I

Robson Mathias — Wed, 19 Jun 2024 12:35:40 +0000

Nesse texto, tenho como objetivo trazer uma alternativa de padrões de projetos front-ends, esse padrão funciona independente do framework ou biblioteca.

A estrutura proposta neste artigo utiliza alguns recursos e nomenclaturas conhecidas pela comunidade do ReactJS, mas outras são uma inspiração de outros ecossistemas como Angular e similares, a ideia é compartilhar um padrão que já adotei em alguns projetos e que serve muito bem para um monolito escalável, e com uma ótima fórmula para modelar um ecossistema que poderá evoluir para um micro-frontend em um futuro próximo.

O que vamos encontrar aqui?

Um projeto To-Do List com ReactJs e arquitetura onion.
Referências a outras publicações que irá descrever melhor alguns contextos e implementações.
Uma simples comparação entre uma arquitetura layered e uma onion.
Um relato dos projetos em que implementei essa composição com pontos positivos e negativos.

Mas antes de começar:

O projeto de exemplo não possui uma API para gerenciar acessos e salvar dados, ou seja, os dados são salvos localmente no navegador.
Essa arquitetura não é uma bala de prata, é complexa e robusta para escalar grandes projetos, para algo menor considere recursos mais objetivos como um MVC por exemplo.
Os nomes podem ser modificados e adaptados para cada organização e contexto.
É uma arquitetura conhecida no mundo back-end então, possuímos muitos posts e referência sobre ela, mas são sobre aplicações back-end.

Porque eu preciso adotar padrões de projetos?

O conceito de padrões foi primeiramente descrito por Christopher Alexander em Uma Linguagem de Padrões.

Padrões de projeto são soluções comuns para alguns problemas típicos, mas acredito que não deva ser algo que seja uma organização de arquivos que fica mais bonita ou que agrade a preferência do programador que está construindo, porque tudo isso é sempre do ponto de vista de quem implementa. Para, ser imparcial durante a definição de um bom padrão de projeto eu levo alguns pontos em consideração de que ele precisa cumprir:

Testabilidade — Que seja possível implementar diferentes testes (unitário, integrado, E2E, mutação, regressão e etc…), precisa ser fácil testar, a porcentagem de coverage não significa qualidade de teste e muito menos de software, porém quanto mais difícil de testar mais cenários os desenvolvedores irá deixar de testar ao longo do caminho.
Manutenabilidade — A alteração de algo em funcionamento, não deveria afetar muitos lugares do organismos. Abstrações e camadas podem parecer burocráticas e verbosa, mas elas garantem a manutenção, isolamento do contexto e sua sanidade no futuro.
Escalabilidade — Uma aplicação assim como uma cidade precisa ser preparada para abrigar muitos cidadãos (usuários) e os engenheiros que irão mantê-la (devs). Não é só escalar apenas código, é escalar a capacidade de muitas pessoas atuarem no mesmo projeto, um projeto grande com muitas pessoas, irá enfrentar problemas como: CI/CD, Ambiente de deploy, PRs e merges, rollback, estratégias de deploy e etc. Para todas as nossas decisões temos que levar isso em consideração.
Separação de responsabilidades (SoC — separation of concerns) — Isolar domínios e responsabilidades, permite um compartilhamento melhor de recursos sem afetar a performance e complexidade da sua aplicação.
Observabilidade — Se algo quebrou, eu preciso saber o que e em qual momento isso aconteceu, preciso atuar e reverter o problema de maneira rápida e eficiente, garantindo que o erro não volte mais a acontecer. Como podemos saber qual é a parte da sua aplicação que mais consome performance? Será que só usar a URL é o suficiente para entender quantos elementos e domínios temos ali e o que eles realmente fazem?
Evitar pastas genéricas e sem propósito, shared e utils — Quando não conseguimos separar bem nossas entidades e camadas, começamos a criar acoplamento entre os recursos, gerando a necessidade de criar pastas para shared ou utils. Funciona para o primeiro elemento, mas depois de um tempo, os desenvolvedores não irão gastar muito tempo pensando sobre o domínio das coisas, e tudo será útil ou shared.

Entre camas e cebolas.

Uma padrão de projeto de camadas tradicional (layered pattern), o fluxo de dependências entre as camadas segue de cima para baixo. Na camada superior encontramos a área de interface do usuário (User Interface), no meio o processamento das informações (Business), e na base a saída ou entrada de dados para um serviço externo (Data).

Fazendo uma sim analogia com uma estrutura em React:

O grande ponto sobre esse padrão é o forte acoplamento entre as camadas, uma vez que é preciso substituir qualquer uma delas, as outras camadas relacionadas sofrem uma grande alteração ou conflito de comportamento. Ou seja, imagina que precisamos mudar a camada de Data de um Rest API para um GraphQL, a camada de business sofreria diretamente com essa mudança, além da baixa reutilização dos mesmos recursos em lugares diferentes.

Agora invertemos a ordem das dependências, colocando como centro a nossa camada de Business e as camadas de Data e User Interface como referências ao business. Temos uma forma de garantir que, o que é importante para nossa aplicação, fique segura de mudanças garantindo que as camadas externas fiquem responsáveis por lidar com o mundo exterior.

Vamos mudar um pouco mais o formato do desenho:

Dessa forma, o que temos de evidência?

O Foco é a parte central da nossa aplicação o business, é onde a nossa mudança de negócio e evolução irá acontecer ao longo do tempo. Em alguns casos é possível manter uma linguagem mais pura, sem muitos recursos atrelado a um framework.
User Interface e Data são camadas periféricas, onde os recursos são substituíveis e podem ser atrelados a um recurso ou tecnologia.

Evoluindo nossa cebola

Podemos quebrar ainda mais as camadas dividindo responsabilidades:

A camada de user Interface se torna:

Presentation — Essa é a camada relacionada ao dispositivo do usuário, seja para web, navegador ou mobile. Os controles de rotas, parâmetros de urls, diagramação visual da página e composição de múltiplos domínios, devem ser tratados aqui. No caso de uma aplicação de front-end os componentes de UI também se encontram aqui, ou seja tome cuidado ao utilizar contextos de domínios em componentes que são apenas UI como Button por exemplo.

Business é composta de:

Application — Essa camada do Business é considerada como operador do domínio, conhecido por alguns como os “Use Cases (Caso de usos)”, são métodos ou componentes que cumprem uma função de controlar o estado do domínio.

Domain — Já na camada de domínio, encontramos o controle das nossas principais entidades. “Todos os objetos de uma aplicação deveriam ser uma entidade?” A resposta é não necessariamente, quando você se encontra em uma situação que precisa compartilhar a mesma informação entre dois organismos distintos e vizinhos, você se esbarra no problema da Mutabilidade, logo conseguimos resolver isso com uma entidade Imutável que é parte do domínio. Se o seu domínio for um método de composição de objeto ao invés de um objeto em si também funciona, é um comportamento muito comum em uma estrutura de Functional Programing.

A camada de Data é separada em:

Persistence — Nem todas as aplicações que trabalhei precisou dessa camada, mas cada vez mais tempos aplicações front-ends que permitem o usuário utilizar recursos offline. Logo precisamos persistir um dado primeiramente no dispositivo do usuário, antes de enviar para o back-end. Essa camada abstrai a forma que persistimos essa informação, seja através de um Index DB, Local storage ou memória volátil. Novamente o nosso domínio não deveria se importar quem e como essas informações chegam ou saem.

Infrastructure — Aqui configuramos a camada de serviço e adaptadores, uma forma de criar métodos e clientes para controlar nossas chamadas com o back-end, seja ela através de Rest API, Web Assembly, GRPC ou qualquer outro recurso, novamente nosso domínio poderia apenas esperar uma promessa de dados seja como for, a camada de infraestrutura deve se resolver para passar esse acordo. Outra coisa bacana, podemos adicionar aqui transformadores e compositores, ou seja nossa entidade do domínio pode ser um objeto que para existir, precisa ser composto por uma ou mais APIs e modificações em dados, na falta de um BFF, a camada de service trabalha muito bem removendo essa composição do seu domínio e entregando um dado mais puro para as camadas de dentro da cebola.

As pastas e arquivos precisam respeitar esses nomes?

Não necessariamente, é claro que se estiver com esses nomes facilita a identificação dos contextos por aqueles que já conhecem esse padrão. Porém a adoção dos padrões é um acordo entre os desenvolvedores, e para todos os projetos que implementei, a nomenclatura dos organismos ainda foram o ponto de resistência à mudança pelos desenvolvedores Front-ends. Então minha escolha foi manter os organismos com nomes já conhecido pela comunidade, e criar um dicionário explicando onde se encaixa cada um deles e seus respectivos papéis para o projeto.

Para entender melhor como cada camada ou elemento disso se comporta e funciona, leia a parte 2 dessa publicação.

Pontos positivos

Essa estrutura permite tomar decisões mais tarde, ou seja, podemos desenvolver uma feature ou módulo, sem precisar esperar a API ficar pronta, conseguimos criar um mock dos dados e mudar isso no futuro sem afetar o domínio.
Facilita muito para testar e conseguir garantir uma boa cobertura e qualidade de test.
É fácil identificar a quebra de um módulo e features em pequenas atividades e PRs.
Exclui a necessidade de pastas como shared, utils e recursos que são uma gaveta de quinquilharias, no começo do projeto faz sentido, depois de um ano não sabemos se tudo que tem lá é realmente para ser compartilhado ou útil.
Essa estrutura funciona para qualquer tipo de linguagem ou tecnologia, já usei com projetos Angular, React + NextJS, React, React + Gatsby, VUE e etc.

Pontos negativos

A curva de aprendizado é um pouco mais demorada, é uma estrutura robusta e complexa que exige um entendimento do porquê das coisas.
Antes de desenvolver um domínio é preciso gastar tempo pensando como ele será, o que é relacionado ao seu contexto e o que não é.
Possui camadas de abstração mesmo que pareça redundante.
Diferente do Java que é uma linguagem que possui recursos como “Protected”, que consegue bloquear o uso indevido de algumas funcionalidades, o javascript é modo “Freestyle” onde tudo é possível, mas nem tudo deveria ser permitido. Então criar bons padrões de alias, ajuda a identificar quando alguém está usando algo de forma errada.

Referências

Código de exemplo:
https://github.com/RobsonMathias/frontend-onion-architecture

Fontes de estudos:
https://refactoring.guru/pt-br/design-patterns
https://code-maze.com/onion-architecture-in-aspnetcore
https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1

Reduzindo o tempo da pipeline em x3 vezes

Gabriel Teodoro — Tue, 18 Jun 2024 17:56:29 +0000

Nesse texto, tenho como objetivo compartilhar a nossa estratégia para diminuir o tempo que nossa pipeline de CI/CD demorava para ser executada, essa estratégia pode ser aplicada independente do framework ou biblioteca.

Esse artigo usará um projeto de front-end que demorava 15 minutos para ter sua pipeline concluída. Iremos considerar a pipeline com: Autenticação no NPM, Instalação de bibliotecas, Lint de arquivos e tipagem, Build, Deploy, Testes (E2E, Unitários e Integrados).

O que você encontrará nesse artigo?

Importância de reduzirmos o tempo de nossas pipelines
Estratégia para redução de tempo de execução
Referências a documentação de ferramentas que estamos utilizando

Antes de começar

O projeto front-end que vamos usar roda com React e Webpack inicialmente
Essa estratégia não é uma bala de prata, só aplicamos ela depois de 3 anos no nosso monolito front-end, evite fazer otimizações prematuras em seu projeto
Pode ser aplicado para projetos de diferentes contextos, porém é necessário analisar se a etapa de build faz sentido ser modificada

Por que eu preciso me preocupar com o tempo da pipeline?

Impacto na entrega de valor - Uma pipeline demorada afeta de maneira significativa a entrega de valor para o usuário, causando falta de eficiência em disponibilizar recursos ou correções para o usuário.
Escalabilidade - Quanto mais o projeto cresce, mais a sua pipeline vai demorar para ser concluída. Em algum momento será mais custoso esperar a pipeline ser concluída do que desenvolver a solução.
Colaboração - Em um time com muitos engenheiros, uma pipeline demorada vai causar um grande gargalo de entregas. Onde um engenheiro irá fazer o merge de uma Pull Request e os outros precisaram rodar a pipeline novamente por conta da mudança. Com a pipeline demorada, isso vai gerar um grande gargalo e vai ficar quase que impossível de se entregar novas soluções.
Otimização de custos - A maioria das ferramentas cobram por tempo de execução da pipeline, quanto mais a sua pipeline demorar maior será o custo final.

Encontrando os gargalos dentro da nossa pipeline

Com a imagem abaixo, podemos analisar o tempo que cada etapa leva para completar a execução de nossa pipeline.

Paralelizando nossa pipeline

Nesse projeto estamos usando o Cloud Build da GCP, com isso não conseguimos ter etapas paralelas dentro de um único trigger. Para isso vamos criar dois novos triggers, um para os testes unitários e outro para os testes integrados, dessa forma eles vão rodar de forma paralela e já irá causar uma redução considerável em nossa pipeline.

Reduzindo o tempo de 15 minutos para 7 minutos.

É importante notar que não vamos conseguir paralelizar os testes E2E, por que eles dependem da etapa de deploy, que depende da etapa de build.

Aprimorando os resultados

Uma forma de aprimorarmos o nosso resultado é melhorando o tempo de build, nesse projeto estávamos usando React com Webpack, com isso o tempo de build levava 3 minutos. Para solucionarmos isso, analisamos algumas ferramentas do mercado e optamos por usar o Vite. Você pode encontrar mais informações sobre o Vite aqui.

Aplicando o Vite em nosso projeto, conseguimos obter esse resultado:

Referências

https://cloud.google.com/build?hl=en
https://vitejs.dev/guide/why.html