Com avanços em IA surgindo diariamente, fica cada vez mais evidente o seu impacto disruptivo. A IA vai transformar indústrias, gerar novas oportunidades, impulsionar a produtividade ao longo de todos os setores e abrir as portas para uma nova era das empresas de tecnologia.

Enquanto startups que têm IA em seu DNA nascem todo dia, companhias de setores tradicionais precisam se adaptar rapidamente a esse novo contexto. É um desafio análogo ao nascimento dos primeiros computadores, e realizar uma mudança cultural tão importante exige um esforço imenso.

A Alice e IA

A Alice é um plano de saúde para empresas que permite que os seus membros (clientes) naveguem pelo sistema de saúde de forma coordenada entre os três diferentes níveis de atenção: primária, secundária e terciária. Fazemos isso direcionando os nossos membros aos agentes mais custo-efetivos do sistema de saúde – membros com condições simples podem ser tratados por enfermeiras e médicos de família, enquanto aqueles com sintomas graves deveriam rapidamente se consultar com os especialistas.

Abordagens baseadas em machine learning e dados sempre foram centrais para essa missão. Quando a Alice foi fundada, isso significava modelos proprietários construídos por nosso time interno de cientistas de dados, e um grande foco em análise de dados.

Mas a ascensão da IA generativa mudou isso. Em vez de depender de um time específico, a nova geração de produtos permite que todo funcionário da Alice faça uso de modelos no estado da arte. Seja incorporando modelos de terceiros diretamente em nossos produtos – para, por exemplo, resumir dados médicos baseados em transcrições de consultas em áudio – ou por aplicações de dia-a-dia que nos permitem reduzir burocracia, a IA deveria ter uma presença constante em como trabalhamos.

Um estudo recente mostrou que a adoção do ChatGPT foi ampla, mas desigual. Muitos funcionários precisam de treinamento e direcionamento para aproveitar completamente os aumentos de produtividade, e muitos são prejudicados por restrições das empresas em que trabalham.

Não cair nessas armadilhas exige uma mudança cultural importante. Product managers (PMs) e times operacionais deveriam enxergar a IA como a primeira solução para todo problema com que se deparam. Isso também significa que o uso de IA deveria ser tão simples quanto possível e não exigir expertise técnica.

Transformação cultural

Para fortalecer a ideia de que recorrer à IA é simples e esperado, organizamos eventos que chamamos de “AI Day”, envolvendo toda a empresa.

Durante todo um dia de trabalho, times de todas as áreas se reuniram em nosso escritório e trabalharam em implementar vários protótipos de aplicações de IA. Esses protótipos poderiam ser lançados no mesmo dia, ou poderiam ser um ponto de partida para um ciclo normal de desenvolvimento. Os times contaram com o apoio de membros de nossas equipes de engenharia e dados, assim como outros funcionários da Alice que já haviam adotado IA como uma ferramenta de trabalho cotidiano.

Antes desses eventos, os participantes levantaram ideias para vários protótipos em uma planilha comum, a serem validados por aqueles que lideraram a iniciativa. Esses projetos variavam dos mais simples, como classificar dados de exames com base em texto não estruturado, aos mais complexos, como gerar um banco de dados com uma ferramenta de busca usando todo o histórico médico de membros.

Fornecemos uma conta no ChatGPT aos participantes com acesso a assistants. No fim de cada dia, eles apresentaram seus projetos a todo mundo presente no evento.

Tivemos três objetivos com essa iniciativa: ensinar a todos como usar IA numa base cotidiana e incorporar essa possibilidade em seu raciocínio; aumentar o ritmo de geração de novas aplicações de IA; e identificar que ferramentas nosso time de engenharia deveria desenvolver para incentivar a adoção de IA.

Esses esforços foram em grande parte bem-sucedidos. Vários dos protótipos desenvolvidos em nosso primeiro AI Day se tornaram projetos completos, e muitos outros foram implementados imediatamente. Temos visto times que não são tradicionalmente de tech usando IA em seu dia a dia, e geramos um novo roadmap para o time de Foundation em engenharia com entregáveis claros que vão impulsionar a produtividade daqueles que trabalham com IA.

Com isso, vieram aprendizados importantes:

• Depois que a porteira está aberta, é difícil segurar a boiada. Um dos principais fatores que levam times fora de tecnologia a relutarem em usar IA é que eles precisam adaptar seu pensamento a uma nova ferramenta. Quebrar essa barreira rapidamente leva a um uso acelerado;
• Transicionar para um modelo em que IA é uma parte central de como trabalhamos exige quebrar dependências. Se funcionários da Alice precisam contatar os times de dado ou engenharias para usar IA, isso significa que estamos fazendo algo errado;
• IA pode ser transformador com produtos de larga escala, sim, mas uma parte importante do valor vem da soma de muitas aplicações pequenas. Aumentar eficiência em todos os lados da companhia pode ser tão impactante quanto desenvolver um novo produto de IA.

IA como plataforma

Nossa experiência com os AI Days nos fez dividir nossos esforços para facilitar o uso de IA em duas frentes: primeiro, precisávamos simplificar o teste de novas aplicações; segundo, precisávamos fazer com que lançar novos produtos de IA fosse tão fácil quanto possível, sem abrir mão de qualidade, controle de custo ou privacidade.

Na primeira frente, nosso time de Foundation em engenharia começou a desenvolver uma plataforma de testes que permitirá que nossos usuários cumpram várias tarefas que hoje são difíceis em um ambiente no-code:

• Rodar prompts de IA que são dinamicamente atrelados a dados de teste em batch. Por exemplo, um usuário pode subir um arquivo com comentários do NPS e pedir que a plataforma rode um prompt, atribuindo a cada um deles uma classificação;
• Otimizar prompts em escala comparando o resultado de diferentes prompts sobre um conjunto de arquivos; diferentes contextos sobre um único prompt; etc.
• Conectar diretamente a nossa camada analítica pelo Metabase, garantindo que usuários não precisam inserir manualmente dados de teste;
• Gerar workflows de diferentes modelos de IA. Por exemplo, transcrever um áudio e em seguida enviar essa transcrição a um modelo de texto;
• Controles de custo e acesso por meio de uma estrutura de times que atribui orçamentos específicos para cada unidade;
• Salvar e comentar em experimentos passados, permitindo que usuários mantenham um histórico dos últimos testes de seu time;
• Fazer uso de nossa infraestrutura de anonimização e privacidade para garantir que respeitemos nossas regras de governança.

Adotamos a estratégia de lançar iterações da plataforma rapidamente e testar com usuários. Representantes de produto, operações e até nossa equipe médica foram os clientes e tiveram a responsabilidade de validar nossos planos e evangelizar seus times.

Enquanto isso, também precisávamos facilitar o deploy de aplicações que se conectassem diretamente a nossos produtos. Por sorte, trabalhar com a nova geração de LLMs é simples, e nos concentramos em garantir que os dados inseridos e gerados por esses modelos passem pelos mesmos processos que nossos dados em produção.

O futuro

A Alice acredita que IA é o futuro, e que ocupamos uma posição única que nos permite nos beneficiar de novos desenvolvimentos. Como um payvidor que atua em toda a jornada de saúde e tem acesso a dados de fontes muito diversas, produtos de dados deveriam ser tão centrais para nós quanto nossa operação médica.

Em uma publicação futura, vamos explorar os detalhes da arquitetura descrita nas últimas sessões. Mas já demos passos largos em adotar uma cultura que coloca IA no centro com nossos esforços institucionais para educar os times e com o desenvolvimento rápido de ferramentas para incentivar a adoção. O futuro é animador e há muito mais a ser feito, tanto em termos dos planos da própria Alice quanto do desenvolvimento de LLMs como um todo.

How Alice is building a culture of ‘AI as a go-to solution’

Alice believes that AI should permeate every aspect of what we do. How do we make sure that this is the case? That’s the hard part.

As advances in AI technology pop up daily, claims of its transformative impact pile up. AI is set to disrupt established industries, foster new opportunities, drive up productivity across the board and usher in a new era for tech companies.

While startups that make AI as part of their DNA are born everyday, incumbents in traditional sectors have to quickly adapt to the new environment. That is a challenge analogous to the advent of the first computers, and bringing about such a major culture change requires major effort.

Alice and AI

Alice is a healthcare company that provides direct access to our own primary care physicians as well as third-party secondary and tertiary care. We do this by directing members to the most cost-effective agent in the healthcare chain – members with simple conditions can be treated by nurses and family doctors, while those with aggravated symptoms should be rapidly attended on by specialists.

Machine learning and data-based approaches have always been core to how we accomplish that mission. Back when we were founded, this meant proprietary models built by our in-house data scientists and a strong reliance on analytics.

But the ascent of generative AI has changed this. Instead of relying on a specific team, the new generation of products allows every single Alice employee to make use of state-of-the-art models. Whether it is by embedding third-party models directly into our products, such as by summarizing medical data based on consultation audio transcripts, or by day-to-day applications that allow us to reduce bureaucratic work, AI should play a constant role in how we work.

A recent paper showed that adoption of ChatGPT has been widespread, but has been unequal. Many workers require training and guidance to fully benefit from productivity increases, and many are hindered by company restrictions.

Not falling into those traps requires a major culture change. Product managers and operational teams should see AI as the number one go-to solution for every problem that arises. It also means that the use of AI should be as hassle-free as possible and does not require much technical expertise.

Culture change

In order to establish the idea that tapping into AI is easy and expected, we ran company-wide events known as “AI Days”.

For a whole working day, teams from across the company would gather in our office and work on implementing several POCs of AI applications that could either be rolled out on the same day or would kickstart a regular development cycle. They would be supported by members of the engineering and data teams, as well as other Alice employees who had already adopted AI as a day-to-day working tool.

Before those events, participants would brainstorm possible POCs in a common spreadsheet to be validated by those leading the initiative. These would range from the simplest, such as tagging exam data based on unstructured text, to the more complex, like generating a searchable database based on members’ full medical history.

Participants would be provided with a ChatGPT account that granted them access to assistants. At the end of each day, they would present their accomplishments to the whole event.

Our objectives with this initiative were threefold: teaching employees how to work with AI on a daily basis and ingraining that possibility into their thinking; increasing the pace of generation of new AI applications; and identifying what tools our engineering team should develop to ensure that AI adoption soars.

Those efforts were largely successful. Several of the POCs developed on our first AI Day event went on to become full-fledged projects, and many others were implemented from the get-go. We’ve seen teams that are not traditionally tech-savvy increasingly rely on AI in their day-to-day work. They also led to a new roadmap for our Engineering Foundation team with clear deliverables that will greatly boost the productivity of those working with AI applications.

All in all, the AI Day events led to significant learnings:

• Once the floodgates are open, the water is hard to stop. One of the main issues that prevent non-tech teams from using AI is that they have to adapt their thinking to a new tool. Breaching that barrier quickly leads to accelerated use;
• Successfully transitioning to a model where AI is a core part of how we work means breaking down dependencies. If Alice employees need to contact data or engineering to make use of AI, that means that there’s something wrong;
• AI can be transformative through large-scale products, yes, but a large swath of its value comes from the sum of a lot of tiny, day-to-day applications. Increasing efficiency across all levels of the company can be as impactful as developing one major new AI product.

AI as a platform

Our experience with AI Days led us to divide our efforts to ease use of AI in two fronts: first, we needed to facilitate testing of new applications throughout the company; second, we should make deploying new AI products as easy as possible while maintaining a high level of quality in our infrastructure, cost control and privacy policies.

In the first front, our Engineering Foundation team began development of a testing platform that will allow users to undertake several different tasks that are as of now hard to achieve in a no-code environment:

• Running AI prompts that are dynamically attached to testing data in batches. For instance, a user can upload a file with NPS comments and then request the platform run a prompt on them, asking it to classify each of the entries between a few different tags;
• Optimizing prompts at scale by comparing the results of different prompts over a single batch of files; different contexts over a single prompt; etc.
• Connecting directly to our analytical layer through Metabase, ensuring that users do not need to manually input testing data;
• Setting up workflows of different AI models. For example, by transcribing an audio, then sending that transcription to a text-based model;
• Access and cost controls through a team-based structure that carries specific budgets for each unit;
• Saving and commenting on past experiments and allowing users to keep a history of their team’s previous attempts;
• Using our own anonymization and privacy infrastructure to ensure that we are not breaching our rules of governance.

We adopted a strategy of rolling out quick iterations of the platform and testing it with users. With representatives of product, operations and even our medical staff as stakeholders, tasked with validating our roadmap and evangelizing their teams, development is running smoothly.

Meanwhile, we also needed to facilitate deployment for those applications that would connect directly with our products. Fortunately, the new generation of LLMs are easy to deal with and we were able to focus on ensuring that data inputted and outputted by those models go through the same processes as those of our production data.

The future

Alice believes that AI is the future, and that it is uniquely positioned to take advantage of new developments. Being a payvidor that acts on the whole healthcare journey and has access to data from a wide range of sources, data products should be as core to us as our medical operations.

In an upcoming post, we will explore the details of the architecture described in the previous sections. But we have taken long strides already in adopting an AI-centric culture by pursuing institutional efforts to educate our teams as well as quick development of tools that boost adoption. The future is bright and there is much more to be done both in terms of Alice’s efforts and the development of LLMs as a whole.

O post Cultura de IA: como a Alice inova no dia a dia apareceu primeiro em Blog da Alice Tech.

Alice é uma empresa de Tecnologia cujo o propósito é tornar o mundo mais saudável. E como tal, resolve seus principais problemas pensando primariamente em soluções baseadas em Tecnologia. Desde o início, além dos sistemas que alimentam diretamente nossos produtos, construímos ferramentas que poderiam ajudar o trabalho de pessoas engenheiras no geral.

Por exemplo, lá nos tempos primórdios da Alice, construímos o que chamamos de Data Layer, uma camada de abstração de acesso a dados que garante privacidade e segurança para todas as aplicações. Iniciamos a resolução de questões super importantes pro nosso contexto de saúde: privacidade e segurança. Esse e outros projetos foram criados de forma orgânica. Nós identificávamos um problema na Engenharia, e então pessoas se juntavam organicamente pra pensar numa solução, projetavam, implementavam e colocavam no ar.

Entretanto, com o crescimento acelerado da empresa e com a necessidade de subir a barra de qualidade de Engenharia no mesmo ritmo, essa estratégia começou a apresentar problemas.

1. Percebemos que nesse modelo não havia um time para dar manutenção a esses projetos ou iterarem de acordo com novos requisitos. As iniciativas eram interpretadas na perspectiva de projetos pontuais e não de produtos internos e suas complexidades (clientes, necessidades de evolução e de negócio).
2. Além disso, alterações macro eram difíceis de serem priorizadas, já que a cada dia ficavam mais complexas e necessitavam de grande esforço de pessoas que, dentro do contexto de seus times, precisavam negociar algum tempo extra para desenvolver novos projetos cross.
3. Com nossa nova escala, também aumentamos a complexidade dos sistemas e o número de novas pessoas engenheiras, tornando “conhecimento tribal” e qualidade mais difícil de se reproduzir.

Diante deste cenário de crescimento rápido pós Series C, percebemos que precisávamos dar o próximo passo na nossa organização de Engenharia para atacar nossos desafios: os times de Plataforma.

Como é Plataforma na Alice?

O que é um time de Plataforma?

Times de Plataforma são geralmente voltados para uma missão técnica de empoderar o time de Engenharia a ser consistentemente eficaz, construindo produtos que abstraem os detalhes técnicos (requisitos não funcionais) e que permitem o foco no negócio. Exemplos desses produtos aqui na Alice são:

1. Data Layer: como comentado anteriormente, uma aplicação que abstrai quesitos de privacidade e segurança na persistência de dados;
2. Design Systems: um ecossistema de repositórios de estilos, componentes e padrões predefinidos e reutilizáveis que ajuda os times a criarem experiências consistentes e escaláveis com mais velocidade e fica acessível por meio de código e ferramentas de design.

Mas como Plataforma resolve o nosso problema?

Com um time focado nas iniciativas cross Engenharia, conseguimos ter a especialização e tempo necessários para construir e evoluir produtos que potencializam os outros times de Tecnologia.

1. Somos essenciais para escalar rapidamente: sabemos que padrões e frameworks estabelecidos facilitam a escala de conhecimento e qualidade na Engenharia. Além disso, com um dono claro para requisitos não funcionais, que são críticas para o funcionamento de qualquer produto, conseguimos garantir que todas as equipes cumpram os mesmos requisitos consistentemente.
2. Melhoramos a eficiência organizacional: reduzimos a duplicação de trabalho e ajudamos na padronização de abordagens (nos casos onde a padronização é um benefício para a organização). Além disso, como donos dos produtos, construímos software mais manutenível e escalável.
3. Agilizamos a entrega de novos produtos: além de remover conflitos entre squads e fornecer serviços que agilizam o desenvolvimento, podemos ajudar quando as equipes de produto estão introduzindo uma nova tecnologia. A equipe da plataforma pode incubar essa nova tecnologia e, em seguida, ajudá-la a ser adotada por outros squads. {plataformização}

Um pouco mais sobre nós

Na Alice, a visão do nosso time é ser o alicerce para a construção de soluções de Tecnologia que aceleram a entrega de saúde no mundo. Para chegarmos a esse objetivo, temos quatro pilares estratégicos:

1. Construção de soluções de forma colaborativa com os times: entendemos que só conseguimos ser pertinentes construindo as ferramentas certas se estivermos muito próximos dos times de Tecnologia entendendo suas dores. Ao mesmo tempo, somos o alicerce para construção de Tecnologia com qualidade, então estamos sempre perto dos times para ajudá-los em suas demandas e entendermos como podemos subir a barra de Engenharia. Em um caso recente, por exemplo, de construção da nova arquitetura Mobile, entendemos junto a todos os times impactados quais casos de uso tinham dificuldades na arquitetura antiga e construímos em conjunto um diagnóstico dos problemas correntes.
2. Antecipação de problemas e pensamento de longo prazo: como um alicerce sólido, desenvolvemos soluções que são robustas no longo prazo. Para chegar a esse objetivo consistentemente, utilizamos um processo diligente de entendimento dos problemas futuros e tomada de decisão. Por exemplo, no caso da nova arquitetura Mobile, além do diagnóstico, projetamos prováveis casos de uso futuros (funcionalidades mais complexas, interações entre diferentes módulos ou até suporte a funções nativas mais recentes), dando insumos para decisões fundamentadas.
3. Abrangência na resolução de problemas priorizando padronização e plataformização: um problema só deve ser prioridade para o time de Plataforma se impactar o alicerce de Tecnologia. Portanto, focamos em soluções abrangentes que podem ser padronizadas ou plataformizadas para a utilização em diferentes contextos. Nosso backend, por exemplo, é bastante padronizado: a quase totalidade das aplicações segue a mesma arquitetura e tecnologia (Kotlin) num mesmo repositório (monorepo). Num caso onde precisamos melhorar a utilização de recursos de uma aplicação, conseguimos com pouco esforço estender essa melhoria para todas as outras as aplicações da empresa.
4. Inovação: para construir um alicerce que acelera a entrega de saúde no mundo precisamos buscar novas soluções, dado que queremos obter resultados diferentes do que já foi feito no passado. A inovação é o único caminho para chegar no nosso objetivo e temos trilhado essa estrada desde a criação do nosso Data Layer, que, diferente de outras soluções de mercado, torna controle de acesso a dados e identificação e de-identificação de dados, padrões em todos os sistemas da Alice.

Nosso time tem menos de 6 meses, mas já atuamos nas nossas três frentes principais: Development Experience, Shared Systems e Quality. Algumas de nossas iniciativas recentes:

• Design System: pensando em DevEx e na padronização de comportamentos, construímos o core do produto, desenvolvemos e aplicamos nossos primeiros componentes Mobile
• Ferramentas de Desenvolvimento local: pensando em DevEx, construímos uma nova forma muito fácil de desenvolver localmente na nossa arquitetura de microsserviços utilizando um ambiente remoto
• Sherlock: pensando em escalar Privacidade, construímos um sistema interno que permite, em casos específicos, acesso a dados PII com rastreabilidade
• Observabilidade no frontend: pensando em escalar estabilidade, integramos nossa plataforma de observabilidade (tracing, alertas, etc) com a ferramenta de monitoramento do Datadog
• Data Layer: estamos desenvolvendo novas funcionalidades no nosso sistema compartilhado (que não tínhamos tempo de evoluir no passado) com foco em estabilidade, performance e escala da aplicação
• Arquitetura Mobile: como foco em qualidade, estamos construindo uma nova arquitetura de software que prepare o nosso aplicativo Mobile para os próximos anos de Alice

E este é só o começo… temos planos ambiciosos de sermos este alicerce de Tecnologia em saúde mundial e ainda temos diversas áreas inexploradas (DevTools, Testes de alta complexidade, Microfrontends, etc.)

Que tal fazer parte desse time?

Estamos buscando pessoas que topem o desafio de transformar a saúde no Brasil através da tecnologia. Clica aqui para saber mais das vagas que temos em aberto!

O post Plataforma: como escalar qualidade em Tech apareceu primeiro em Blog da Alice Tech.

About a year ago I arrived at Alice with the compromise to make the world healthier. We had less than 100 employees and living from series A, which means short money. A big challenge and a lot of work to do!

The first challenges

As a data engineer, my responsibility was to provide data for everybody. The team was very small (actually just me and half the time of my boss) and the systems were changing very fast.

Facing the situation, the plan needed to be as simple and direct as possible:

• Use a relational database as the data warehouse. We choose PostgreSQL hosted in AWS RDS. Easy to configure and maintain.
• Use a simple tool to schedule the ETL pipelines. The choice was Airflow since it’s a very stable, well know tool and we had experience with it (and we love Python).
• A visualization interface. Metabase was the winner for many motives: Free, previous experience with it, easy to install and configure, self-service, very stable and users usually like it.

OK…. That’s something we can make happen! I reused some previous code I wrote in the past to copy data from one place to another and data started to flow! Great! Mission accomplished!

Problems always happen!

BUT…. almost every day I had dags broken and had to add a table, fix some table structure, re-run dags, and deploy emergency PRs. The problem was for every new column, every modification in size or type, even the order of some selects could break something. How to solve it?

For every problem, a solution!

At that point, I started to work on an Airflow plugin for a smarter extractor which was baptized, given my total lack of imagination, “SmartTransfer”. The main idea was to check the existence and structure of the table in the destination stage area and automatically create or re-create as needed.

The intention was to be really easy to be called, with minimal parameters. Below is a real example of a very simple dag with it:

(all code is available at https://github.com/alice-health/airflow_plugins )

So, how does it work? No big secret, but there are some steps in the process.

First, we need to check the structure of the source table. We run a query and get one row from the source table and analyze the columns.

From the table, we can create build the ‘create table’ statement.

We used the ‘unlogged table’ PostgreSQL feature because it should be, in principle, faster. Unlogged tables are faster but not crash-free, so be careful! Since staging is just a copy of production, it’s not a problem to lose data. You can learn more about PostgreSQL here. We didn’t notice much difference but we have only a few gigabytes. We will benchmark again in the future as our database grows.

Everything set, the logic is quite straightforward:

• If the destination table doesn’t exist, create it
• If the destination table exists but the structure is different, drop it and recreate it
• If tables have the same structure, same primary keys, just keep the table

It’s important to remember in the case of (re)creating the destination table we need to do a full import, so we set the flag “need_full_import” to True

Finally, transfer the data. The first step is to know if we are going to do a full import or an incremental import:

and prepare the insert statements. The syntax is PostgreSQL specific, with “ON CONFLICT DO UPDATE” to create a mixed insert/update statement:

The main loop makes the data transfer. The most important part here is the grouper function: It lazily consumes the source_cursor, keeping in memory only the data will be sent in the current block

More details of installing, using, and testing SmartTransfer are in the README file in the official repository at https://github.com/alice-health/airflow_plugins.

Conclusion

I tried to cover the most important (and interesting) parts of the code and show how we solved the problem of moving, not hundred of terabytes with 100 people, but a couple of gigabytes with two people, in a way to automatize all table synchronization and copying process to minimize the data engineer manual work.

O post How we extract data for our DW apareceu primeiro em Blog da Alice Tech.

Afinal, o que é um microbenchmark?

Um microbenchmark é um teste projetado para medir o desempenho de uma unidade muito pequena: o tempo para chamar um método sincronizado versus um método não sincronizado; a sobrecarga na criação de um encadeamento versus o uso de um conjunto de encadeamentos; o tempo para executar um algoritmo aritmético versus uma implementação alternativa; e assim por diante.

É uma forma bem interessante de verificar se algum fluxo que estamos fazemos está consumindo muito ou pouco tempo ou recursos (CPU, memória, rede, disco, etc). Porém deve ser feito com cautela.

Muitos fatores podem interferir na execução e aferição de um benchmark, como capacidade de processamento do computador, memória disponível, versão do framework, entre outros. Por conta disso, deve ser feito para testes isolados de unidades bem específicas.

Testando uso de reflections para nossos logs

Há alguns meses atrás, o time Alice estudou a necessidade do uso de Reflection para identificar a função e a classe exata de onde o log foi gerado.

Nossa hipótese era que a utilização de Reflection poderia aumentar o consumo de recursos da função, mas não sabíamos o quanto aumentaria e se isso impactaria de verdade nossas aplicações.

Importação de dependências

Usamos a biblioteca JMH (the Java Microbenchmark Harness) para fazer a comparação. Utilizamos tanto o JMH Core quanto JMH Annotation Processor.

plugins {
    kotlin("jvm") version "1.4.32"
    kotlin("kapt") version "1.4.32"
    id("me.champeau.gradle.jmh") version "0.5.2"
    id("io.morethan.jmhreport") version "0.9.0"
    application
}

No build.gradle.kts do projeto nós declaramos a task para rodar os testes de benchmark

task("benchmarks", type = JavaExec::class) {
  classpath = sourceSets.getByName("test").runtimeClasspath
  main = "br.com.alice.benchmarks.BenchmarksRunnerKt"
}

Além disso importamos a biblioteca orgs.slf4j.Logger para criar nossos logs. A lista de dependências ficou:

dependencies {
    kapt("org.openjdk.jmh:jmh-generator-annprocess:1.25")

    implementation("org.openjdk.jmh:jmh-core:1.25")
    implementation("org.openjdk.jmh:jmh-generator-annprocess:1.25")

    api("ch.qos.logback:logback-classic:1.2.3")
    implementation("net.logstash.logback:logstash-logback-encoder:6.4")

    annotationProcessor("org.openjdk.jmh:jmh-generator-annprocess:1.25")

    testImplementation(kotlin("test-junit"))
}

Criação da função de log

Para realizar o teste, criamos uma abstração para a biblioteca orgs.slf4j.Logger . Só possui uma simples função de logar info, simulando nossa biblioteca interna para logs.

Criando os casos de teste

JMH suporta diferentes tipos de benchmarks: Throughput, AverageTime, SampleTime, and SingleShotTime. São configurados via annotation @BenchmarkMode .

• Throughput: nesse modo, o teste é executado em um período pre determinado e é avaliado o número de vezes que o método em teste foi executado
• AverageTime: inverso ao Throughput, esse método é usado para se ter o tempo médio de cada chamada do método em teste.
• SampleTime: esse método também utiliza um tempo pré determinado, porém aqui algumas chamadas são selecionadas randomicamente e seu tempo avaliado.
• SingleShotTime: mede o tempo de uma única chamada.

Para o nosso caso, utilizamos AverageTime, dessa forma a gente simular os nossos micro-serviços utilizando os métodos de log diversas vezes e ver o quanto isso impactaria o tempo e os recursos dos mesmos.

Configuramos também a unidade de medida temporal para microsegundos, também via annotation @OutputTimeUnit .

Usamos a annotation @Benchmark para definir uma função como test case do benchmarking. Criamos 3 tipos de testes:

• Log sem nenhuma reflection
• Log utilizando reflection através do Throwable para receber os nomes de classe e método.
• Log utilizando reflection através da Thread para receber os nomes de classe e método.

Configuração final do benchmark

Para agrupar todos os testes, configurar saída do resultado e definir últimas configurações, nós criamos o arquivo BenchmarksRunner.kt, assim declarado no gradle.build.kts , mostrado no início do artigo.

As configurações utilizadas no OptionsBuilder:

• include adiciona o teste que vamos realizar. Nele indicamos qual a classe a ser executada, nesse caso o LogReflectionBenchmark .
• forks é o número de testes paralelos que vão ser executados em cada iteração. Utilizamos 2 forks.
• threads é o número de threads a ser utilizada para cada teste. Escolhemos duas threads. Dependendo do número de threads disponíveis na máquina, esse valor pode aumentar.
• warmupBatchSize é o tamanho o grupo de aquecimento. Utilizamos 2 batches.
• warmupIterations é o número de iterações a serem executadas antes de começar a contabilizar o tempo. Esse número é importante pois ajuda a contabilizar depois que a máquina já estiver rodando os testes. Um número muito alto pode impactar negativamente o teste, se o processo já tiver consumido bastante recurso da máquina.
• measurementIterations é o número de iterações, agora contabilizando o tempo de cada teste. O resultado final é montado a partir a média entre as diferentes iterações.

Além disso, definimos como arquivos output benchmark_output.log e benchmark_result.json . Eles vão conter as informações dos testes.

Hora de rodar os testes

Depois de toda a configuração, podemos rodar o BenchmarksRunner.main e aguardar os resultados. Após alguns minutos, o resultado foi mostrado no arquivo benchmark_output.log .

LogReflectionBenchmark.logWithReflectionThreadGetStackTrace     avgt    4  28.860 ± 7.172  us/op
LogReflectionBenchmark.logWithReflectionThrowableGetStackTrace  avgt    4  42.075 ± 11.087  us/op
LogReflectionBenchmark.logWithoutReflection                     avgt    4  0.36028 ±  0.00035  us/op

Como vocês podem ver, a utilização do log sem nenhum tipo de reflection foi cerca de 100x mais rápida do que com uso de qualquer reflection. Isso já foi necessário para que o nosso time decidisse não precisar logar o nome da função e nem da classe.

Teste você mesmo

Caso queira validar também em sua máquina, o código de exemplo está aberto. Você pode fazer o mesmo teste que nós fizemos, ou usar o exemplo para criar seus próprios microbenchmarks em Kotlin.

alice-health/kotlin-benchmark-example

No repositório tem a descrição de como executar os testes. E se você conseguiu testar outros use cases, compartilha aqui com a gente!

Que tal fazer parte desse time?

Estamos buscando pessoas que topem o desafio de transformar a saúde no Brasil através da tecnologia. Clica aqui para saber mais das vagas que temos em aberto!

O post Como fazemos microbenchmarks em Kotlin apareceu primeiro em Blog da Alice Tech.

Na Alice, temos a cultura de tomada de decisões em conjunto para assuntos que impactem a engenharia como um todo. Isso sendo desde a definição da tecnologia a ser usada para desenvolvimento mobile, até a arquitetura de processamento assíncrono dos serviços (spoiler: ela é baseada em Kafka).

Mas antes de contar como e porque escolhemos o Kafka, vale uma n̶ã̶o̶ ̶t̶ã̶o̶ breve introdução sobre ele.

O que é o Apache Kafka?

Resumidamente, o Kafka pode ser definido como um sistema de processamento de stream de dados em tempo real / um sistema de mensageria (messaging system) publish-subscribe distribuído.

Ele possui como principais características — se comparado com outros sistemas de mensageria — um alto throughput, clusterização no DNA (permitindo escalabilidade horizontal), ordenamento e persistência de mensagens com estrutura de disco O(1) (entraremos em mais detalhes sobre o que isto representa).

O que é um sistema de mensageria?

Um sistema de mensageria nada mais é do que uma forma de comunicação assíncrona entre duas (ou mais) aplicações. Neste conceito, as aplicações se comunicam através de uma fila (message queue), de forma totalmente desacoplada, onde o produtor da mensagem (producer) não tem conhecimento de quem a processará, assim como o consumidor (consumer) também não possui ciência de quem a produziu. Ambas as pontas apenas se preocupam com o conteúdo da mensagem.

Existem dois tipos de padrões de mensageria: ponta à ponta (point to point) e publish-subscribe (pub-sub).

Sistema de mensageria ponta à ponta

Um sistema de mensageria ponta à ponta é caracterizado pelo fato de que cada mensagem apenas poder ser consumida uma única vez. Neste sistema, a mensagem é persistida na fila e, a partir do momento que um consumidor lê esta mensagem, ela é automaticamente removida da fila. Exemplos de sistemas neste modelo temos o Amazon Simple Queue Service (SQS) e o Microsoft Message Queuing (MSMQ).

Sistema de mensageria publish-subscribe

No sistema de mensageria publish-subscribe assim como no de ponta à ponta, as mensagens são persistidas em uma fila através de um produtor (publisher). Porém, diferentemente do modelo anterior, os consumidores podem se inscrever/assinar (subscribe) à uma ou mais filas e consumir todas as mensagens destas filas. Neste modelo, todos os consumidores (subscribers) processam todas as mensagens de todas as filas no qual eles se inscreveram. Exemplos de sistemas neste modelo temos o RabbitMQ e o Apache Kafka.

Background

História

Tudo começou em meados de 2010, com uma necessidade do LinkedIn: integração massiva de dados. Um volume enorme de dados era gerado a todo tempo, porém, com as ferramentas existentes na época, não era possível integrar e centralizar estes dados da forma que gostariam e com a escala que precisavam.

Foi então que Jay Kreps e sua equipe surgiram com o conceito do Kafka.

Timeline

Em 2011 tornou-se um projeto open-source, sendo absolvido pela Apache Foundation em 2012.

Em 2014, os engenheiros do LinkedIn responsáveis pelo desenvolvimento do Kafka fundaram a Confluent, empresa com foco em Kafka.

Fun fact

Kafka é desenvolvido em Scala e Java, e seu nome é uma referência ao escritor alemão Franz Kafka. Jay diz que a escolha do nome se deu ao fato de que, devido o Kafka ser um sistema otimizado para escrita, faria sentido ter o nome de um escritor. Além de achar que soava bem para um projeto open source.

Mas por que utilizar Kafka?

Dentre as principais vantagens do Kafka, podemos destacar:

• Sistema de registros: após persistido, um registro (mensagem) nunca mais é mais removido do log (por padrão). Desta forma, é possível “voltar no tempo” e reprocessar todas as mensagens a partir de uma data específica.
• Ordenamento garantido: ao ser publicada a mensagem A (POST) e então a B (PUT), sempre serão retornadas e lidas nesta mesma ordem (FIFO).
• Centralização: uma mesma mensagem pode servir de input para uma operação SQL e para um registro em um Data Lake.
• Escalabilidade: Kafka é totalmente pensado em clusterização e escalabilidade horizontal.
• Pull over Push: diferentemente de outros sistemas de mensageria (e.g. RabbitMQ) e/ou sistemas de service bus, o Kafka trabalha com um modelo de pulling ao invés de pushing, no qual o consumidor tem de solicitar ativamente a leitura de novas mensagens. Isto possibilita a existência de consumers com velocidades de processamento distintas entre si.
• Performance: possui um alto throughput, comportando centenas de milhares de mensagens/seg até em hardwares mais modestos. Como citado anteriormente, possui persistência de mensagens com estrutura de disco O(1), ou seja, não importa a quantidade de mensagens existentes, a velocidade de escrita sempre se mantém a mesma.

Performance linear

Devido a arquitetura de distribuição que o Kafka implementa, é possível obtermos escalabilidade linear em nosso sistema. Desta forma, para cada nó (broker) adicionado ao cluster, teremos um aumento linear de throughput suportado pelo Kafka.

Use cases

Mesmo o Kafka sendo extremamente versátil, existem alguns casos de uso no qual acaba se destacando. Tais como:

• Hub de eventos: Kafka pode servir de um hub centralizador dos eventos da sua aplicação, permitindo que inputs de diversas fontes de dados sejam concentrados em um único ponto, para então serem potencialmente filtrados, transformados e processados de formas distintas.
• Data pipeline: um dado pode ser persistido no Kafka para então ser replicado para outros repositórios, tais como banco de dados.
• Entry point de Big Data: em casos de utilização de data lakes baseados em storages na nuvem (e.g. AWS S3), Kafka costuma servir como um “buffer” dos dados devido ao seu throughput, armazenando-os até serem transferidos para o storage final.

Semânticas

Registros

Os registros (records) são as mensagens persistidas em uma fila (tópico). Um registro é composto de três componentes: chave, valor e timestamp.

A chave (key) é o que define em qual partição este registro será armazenado (mais detalhes sobre particionamento abaixo). A chave não é obrigatória e, caso não seja fornecida, o Kafka se encarregará de definir a partição correta para este registro.

O valor (value) é o conteúdo do registro, o equivalente ao corpo de uma mensagem. O valor pode conter qualquer dado, desde uma simples string até um objeto serializado em JSON.

O timestamp é a data e hora no qual o registro foi persistido, sendo atribuído automaticamente pelo Kafka no momento da criação do registro.

O registro é sempre imutável e append-only, ou seja, somente é possível incluir novos registros. Uma vez incluído não pode mais ser modificado ou removido.

Os registros são sempre persistidos em disco, não havendo nenhum cache em memória, tanto para escrita quanto para leitura.

Producer e Consumer

O producer é quem será responsável por gerar registros em um tópico e o consumer por ler estes registros. Em ambos os casos, a comunicação é sempre feita com o broker (nó) líder do cluster.

Ao ler um registro, o consumer pode tanto solicitar o último não lido, quanto a partir de uma posição específica.

Tópicos

O tópico é a nomenclatura lógica para uma ou mais partições. Basicamente é onde os registros ficam armazenados, sendo equivalente à uma fila, porém considerando todas as partições do cluster.

Partições

As partições são as divisões “físicas” de um tópico. Cada partição representará o conjunto de registros de um tópico, em um broker (nó) no cluster.

As partições seguem o modelo de líder/seguidor (leader/follower), onde sempre há ao menos um broker com uma partição principal que recebe todas as operações de leitura e escrita, sendo replicado posteriormente para os demais brokers seguidores em forma de réplica.

No exemplo acima, temos quatro partições com duas réplicas cada. Cada partição ficará responsável por um conjunto de dados daquele tópico, onde estes mesmos dados serão replicados em cada um dos outros dois brokers seguidores.

O particionamento pode ser feito manualmente ou baseado em uma chave. No primeiro cenário, quem estiver produzindo e/ou consumindo as mensagens, fica responsável por indicar com qual partição deseja interfacear. Já no segundo caso, deve-se definir previamente qual o range de valores de uma chave que cada partição será responsável. Desta forma, ao publicar ou ler um registro, o Kafka ficará encarregado por atribuir a partição correspondente, baseado nas configurações previamente estabelecidas.

Grupos de consumo

Grupo de consumo (consumer group) é o nome lógico para um ou mais consumers. É através dele que se dá a escalabilidade do lado dos consumidores.

Cada grupo lê todas as mensagens de um tópico, dividindo as partições deste tópico por entre os integrantes do grupo.

Cada grupo vai representar um processamento específico (e distinto) dos registros de um tópico em relação ao outro grupo. Já cada integrante de um mesmo grupo representará uma instância de processamento (um processo, uma thread, um container, etc.) idêntica em relação aos consumers deste mesmo grupo.

No exemplo acima, temos um tópico dividido em quatro partições, e dois grupos de consumo: grupo A com dois integrantes e B com quatro.

Desta forma, tanto o grupo A quanto o grupo B processarão todas as mensagens de um determinado tópico. Devido ao grupo A possuir dois integrantes, cada integrante ficará responsável pelos registros de duas partições cada. Já no grupo B por possuir quatro integrantes, cada integrante ficará responsável pelas mensagens provenientes de uma única partição cada.

Com isto, é possível ter N processos distintos para um mesmo dado e paralelizar cada um destes processamentos em N instâncias conforme a necessidade, sem gerar concorrência entre si.

Offsets

Ao inserir um registro em um tópico, o Kafka automaticamente atribui um identificador único sequencial para ele, que consiste basicamente de um índice deste registro na partição daquele tópico.

O offset por sua vez, representa a posição de leitura de um grupo de consumo, em relação à uma partição de um tópico.

No exemplo acima, temos um tópico com três partições. As setas representando um grupo de consumo e os números destacados os offsets daquele grupo nas respectivos partições.

O objetivo do offset é definir qual foi o último registro lido por aquele grupo de consumo naquela partição, para que assim possa prosseguir com a leitura de onde parou.

O Kafka mantém o tracking dos offsets para que apenas retorne os registros ainda não lidos. Porém, como citado anteriormente, um consumer pode solicitar um registro em uma posição específica.

Conclusão

Conforme pudemos ver, o Kafka é uma excelente ferramenta para criação de sistemas distribuídos, mas assim como qualquer tecnologia, nasceu para resolver problemas específicos e não para ser uma “bala de prata” da persistência de dados.

Que tal fazer parte desse time?

Estamos buscando pessoas que topem o desafio de transformar a saúde no Brasil através da tecnologia. Clica aqui para saber mais das vagas que temos em aberto!

O post Descomplicando o Apache Kafka apareceu primeiro em Blog da Alice Tech.

Mas é claro, como quase tudo no mundo do frontend, as opções não param por ai. Dependendo do framework que você usa, também existem algumas alternativas diferentes para escrever CSS {como se já não fosse complexo o suficiente haha, mas vamos falar disso depois}.

Aqui na Alice, nós usamos o Vue e durante algumas semanas no nosso chapter de frontend, discutimos qual seria o padrão que iríamos adotar. Antes de tomar uma decisão, nós testamos as opções mais comuns e algumas obscuras que a comunidade ainda não está usando tanto. Como o nosso chapter de frontends não é muito grande, é importante para nós termos um padrão bem definido {já que cada pessoa está em um time diferente} e que seja fácil para quem não trabalha com frontend {já que nem todo time tem alguém com esse foco}.

No decorrer desse artigo, junto com os pontos que levantamos, tem algumas implementações básicas de um componente de botão {que chamei ele de base-button} que tem algumas propriedades: tamanho, ícone e loading que são as responsáveis por mudar o comportamento/CSS.

Então aperte o cinto que vamos seguir numa jornada do que nós encontramos em cada uma das possibilidades ✨

Mas antes, uma leve introdução ao vue file

Para quem nunca trabalhou com o Vue antes, é possível criar componentes usando arquivos .vue, que possuem o HTML dentro do <template>, o JS dentro de <script> e o CSS dentro de <style>.

Focando no assunto desse post, na parte de CSS nós temos algumas alternativas: escrever o CSS puro {assim como vemos da linha 16 a 18}, ou escrever com algum pré-processador.

Escolhendo a segunda o opção, tudo que nós precisamos fazer é adicionar um atributo lang na linha 15 com o nome da “linguagem” que queremos {Aqui na Alice nós usamos o SASS com a sintaxe scss, então a maioria dos exemplos daqui pra frente terão o CSS escrito dessa forma}.

Sabendo disso vamos começar falando de uma das nossas opções de escrever CSS, que não depende de estar usando ou não um pré-processador:

BEM

Acredito que essa seja uma das formas mais comum de escrever CSS. Por ser uma metodologia, não tem grandes segredos, mas não significa que seja fácil. Pensar no nome das coisas provavelmente é a parte mais difícil do desenvolvimento de software {risos}, e com o BEM é preciso pensar com carinho no nome das classes para que a estrutura faça sentido.

Para quem nunca trabalhou com a metodologia antes, vamos a uma explicação rápida:

Nós basicamente dividimos uma classe em três pedaços:

• O Block representa o bloco que vai ser estilizado {normalmente algum elemento que esteja envolvendo outros elementos/outras tags}.
• O Element é algum elemento ou tag que esteja dentro desse bloco, e para identificarmos ele facilmente, é separado por dois underscores.
• O Modifier significa que o estado daquele elemento mudou, o que significa que o nosso layout vai mudar graças; a separação dele é por dois dashes.

Isso significa que em uma classe eu posso ter dois elements? Ou dois modifiers? Não. A estrutura do BEM espera que você tenha um de cada, por isso para pessoas que não estão familiarizadas com a metologia, pode ser bem confuso como criar uma classe nova. {Nesse artigo tem uma explicação detalhada do uso do BEM e erros comuns, vale a leitura!}

De qualquer forma, se usado corretamente vários problemas de CSS são resolvidos, além de termos uma boa organização.

Agora vamos para a aplicação dessa metologia no Vue.

Começando pelas linhas 4, 5, 6, 7 — aqui nós temos classes condicionais baseadas em alguns atributos {que no nosso exemplo são props declaradas nas linhas 28 e 29}, uma coisa que podemos ver é que por serem condicionais, usamos o modifier para alterar visualmente o layout de cada uma delas {já que elas representam um estado do nosso botão}.

Na linha 12, temos uma classe com um element, pois esse componente de icone representa um elemento no nosso bloco {que nesse exemplo é o botão}.

Por fim, na linha 34 temos a declaração da lang, que como é importante dizer que só vai funcionar se o projeto está preparado para o pré-processador declarado. Se você começar um projeto usando o Vue CLI é uma das coisas que você pode ou não escolher. Se você quiser mudar o lang, na documentação do Vue tem um passo-a-passo.

Scoped CSS

Você pode se perguntar: por quê exatamente eu preciso do BEM? Não é só sair espalhando minhas classes por ai e tudo bem?

Conforme você vai escrevendo o seu CSS, no final das contas o Vue vai pegar o CSS de todos os componentes sendo usados naquela página e jogar ele no <head>. O que significa que qualquer componente vai ser afetado por qualquer regra definida em um componente. O BEM tenta resolver isso tendo classes especificas que não vão afetar outro componente tão facilmente.

É ai que entra o scoped CSS. Ele nos ajuda a resolver esse problema de escopo adicionando um atributo a mais nas nossas tags HTML para deixar as classes específicas para aquele componente.

Tudo o que precisamos para isso funcione é adicionar o atributo scoped à declaração de <style>, assim como na linha 34 do exemplo.

Para entender melhor vamos pegar a classe na linha 5.

O Vue vai transformar ela em algo como: .loading[data-v-763db97b]. Esse atributo novo sempre vai começar com data-v e vai terminar com uma hash aleatória, o que ajuda caso tenhamos classes iguais {elas não vão colidir graças ao hash} e impede que um componente distante seja afetado.

O problema dessa solução é que mesmo com esse atributo a mais na tag HTML, as regras afetam os componentes filhos. Olhando no exemplo ao lado, se o <base-icon> tivesse a classe “icon” e removêssemos a linha 12, as regras de CSS dessa classe afetariam o componente filho mesmo assim.

Podemos resolver isso facilmente evitando seletores iguais {até mesmo usando uma metologia como o BEM que vimos anteriomente}, para não correr o risco de herdar regras que não gostaríamos.

CSS Modules

Assim como a solução anterior, o CSS Modules tenta nos ajudar com esse problema de conflitar regras de CSS ou herdar regras que não gostariamos.

A diferença dele para o scoped, é que não teremos um atributo novo no HTML e sim uma classe gerada pelo Vue, composta pelo nome do componente + o nome da classe que nós colocamos no CSS + uma hash aleatória.

Para que essa solução funcione, precisamos adicionar o atributo module à declaração de <style>, assim como na linha 35 do exemplo.

Uma das coisas mais importantes aqui é que a sintaxe de declarar uma classe sempre vai ser :class=”$style.xpto” e com o nome da classe sempre em camelCase. E no caso de classes condicionais como na linha 5, 6 e 7, precisamos usar a classe dentro de colchetes.

Para entender melhor, vamos pegar a linha 5 de exemplo. No fim das contas o Vue vai gerar uma classe parecida com BaseButton_loading_1VuSe. Isso vai resolver o nosso problema de conflito de regras e não é algo que interfere nos filhos.

Mas e se você quisesse que isso acontecesse? Até agora pontuei que um componente filho herdar as regras do pai era uma coisa ruim, mas dependendo da situação é exatamente isso que nós queremos para não repetir código.

Nesse caso, você pode passar as classes como prop para o componente filho, ou usar mixins de um pré-processador e importar nos dois componentes.

Achou que tinha acabado?

Achou errado!

As três soluções que vimos até agora, são as formas oficiais do Vue de definir CSS, mas a partir daqui vamos entrar no mundo obscuro das formas alternativas.

Nós separamos duas para testar e ambas são frameworks CSS-in-JS, o que significa que nós escrevemos o CSS no JS e não precisamos mais da tag <style> nos nossos componentes.

Aphrodite

Começando pelo Aphrodite {que não tem muita coisa sobre o uso dele com o Vue na internet e eu usei esse artigo como referência para a minha implementação}.

Inicialmente, nós precisamos importar duas coisas do framework: o StyleSheet e o css {como vemos na linha 8}.

O StyleSheet vai ser o responsável por gerar as nossas regras de CSS baseado na estrutura de objeto com o nome da classe sendo a chave, e o valor sendo os atributos de CSS {linha 10 à 19}.

E para que nós possamos usar essas classes no HTML, primeiro precisamos expor elas no JS {como vemos da linha 22 à 24} e usamos o css na linha 2 {separando os nomes das classes por vírgula se necessário}.

Agora vamos voltar o mesmo componente de botão dos exemplos anteriores, mas dessa vez usando Aphrodite:

Temos algumas limitações com essa solução, e de cara o que mais me incomodou foi que por padrão todas as regras são geradas com !important. A linha 18 poderia estar importando só de ‘aphoridite’, mas para não ter o comportamento de !important, eu acabei importando as dependências necessárias de outro pacote.

Também não existe um jeito oficial de definir classes aninhados {ou seja, uma classe dentro de outra classe}, com isso precisamos ter classes diferentes para um estado específico de um elemento, como por exemplo na linha 27 e 28, onde o componente de ícone que nos exemplos anteriores só tinha uma classe, aqui nós precisamos de duas.

Com essa implementação, as classes geradas são completamente aleatórias {algo parecido com _w3twfb}, o que dificulta um pouco encontrar onde que essas regras foram definidas, mas tem a vantagem de serem nomes curtos.

Por fim, a implementação de exemplo não é a mais otimizada possível, dá para criar um plugin que importe o Aphrodite em todos os nossos componentes.

Styled Components

Por fim chegamos na última opção da nossa lista, o Styled Components, que nos permite criar componentes estilizados.

Na linha 22 e 33 temos dois componentes sendo definidos usando o styled importado do framework. O primeiro parâmetro é a tag HTML que vai ser renderizada, o segundo são as props daquele componente. A partir dai é possível retornar todas as regras de CSS necessárias {e condicionar elas dependendo de uma propriedade, o que nos dá muita liberdade}.

Por mais diferente que essa implementação seja, esses dois componentes são iguais a qualquer outro definido por um arquivo vue {claro, com as suas limitações, ele é um componente puramente visual, então não vamos ter métodos ou outros tipos de atributos nele} e precisa ser declarado como na linha 42 para ser usado pelo HTML.

Eles também não precisavam estar dentro do vue file {só coloquei aqui para facilitar o exemplo rs}. Por serem componentes normais, poderiam estar em arquivos separados para serem importados pelo base-button.

É uma solução simples para componentes básicos.

Conclusão

Depois de muita discussão e uni-duni-tê, nós escolhemos usar o CSS Modules como padrão aqui na Alice {pessoalmente, eu ainda prefiro usar o BEM, mas vamos manter isso entre eu e vc, blz? haha}.

Pelas nossas conversas, foi a opção que mais fez sentido para o nosso momento e para os nossos produtos, onde muitas pessoas precisam mexer. Mesmo sendo uma sintaxe diferente do normal, é algo rápido de aprender/entender e ganhamos uma certa liberdade com qual nome de classes vamos colocar {além de impedir certos problemas de herdar regras desnecessárias/ter seletores de tag HTML}.

Mas por que fizemos essa escolha? As outras opções são ruins?

Particularmente as soluções não oficiais não me agradam, pois é uma dependência a mais que precisamos colocar no projeto, temos uma curva de aprendizado para escrever o CSS dentro do JS, e do meu ponto de vista não é mais vantajoso do que usar uma solução oficial do Vue.

Porém, não existe solução perfeita, não tem uma forma melhor do que a outra, no fim das contas é necessário considerar o que mais faz sentido para o projeto e para as pessoas que vão dar manutenção no código.

Hoje o CSS Modules faz sentido pra gente, mas quem sabe daqui um tempo não faça mais. É importante ter a mente aberta para qualquer solução, e do meu ponto de vista, manter o mais simples possível. 🙂

Que tal fazer parte desse time?

Estamos buscando pessoas que topem o desafio de transformar a saúde no Brasil através da tecnologia. Clica aqui para saber mais das vagas que temos em aberto! 🙂

O post Melhor forma de escrever CSS no Vue apareceu primeiro em Blog da Alice Tech.