O que é Autorização? Qual a diferença de Autenticação?

Antes de entrar nos detalhes do tema, é importante relembrar a diferença entre Autenticação e Autorização, dois conceitos que muitas vezes andam juntos mas são fundamentalmente diferentes.

Em resumo, Autenticação é o processo de Identificação de um usuário, que garante que ele é quem diz ser. Já Autorização é o processo que indica se um usuário identificado (ou não) tem a permissão para realizar determinadas ações dentro do sistema.

Soluções e Frameworks que temos disponíveis para usar podem lidar com um ou ambos aspectos, e é importante saber disso porque pode inviabilizar uma escolha. Você pode, por exemplo, ser obrigado a usar o aspecto de Autenticação da solução para que o aspecto de Autorização funcione e, dependendo do caso (como foi na Alice), isso pode não ser desejado.

Tipos comuns de Autorização

Temos alguns tipos diferentes de Autorização, que cobrem a maior parte das necessidades comuns dos sistemas de mercado. Aqui descrevo os principais:

• Role-Based Access Control (RBAC): o tipo mais comum de controle de acesso, consiste em atribuir papéis (roles) aos usuários e definir o que cada papel pode fazer. A ideia é que papéis possam ser atribuídos ou revogados a qualquer momento, e o sistema possa mudar seu comportamento imediatamente após os papéis mudarem. Os papéis costumam ser uma informação curta, que pode ser facilmente trafegada dentro de Tokens JWT por conveniência.
  • Exemplo: Joãozinho assume o papel de analista de Operações e ganha a capacidade de editar quaisquer Membros (como chamamos os pacientes da Alice) no sistema.

• Attribute-Based Access Control (ABAC): controle de acesso baseado em atributos do usuário e / ou do recurso sendo acessado.
  • Exemplo: Joãozinho pode editar um Membro do sistema se seu atributo do usuário isAdmin = true, ou se o membro tem o atributo isPublic = true.

• Relationship-Based Access Control (ReBAC): caso específico de ABAC onde uma permissão é concedida se há um relacionamento específico entre o usuário e o recurso sendo acessado.
  • Exemplo: Joãozinho pode editar os dados de um Membro se o registro representar ele mesmo ou um dependente dele.

Seu sistema pode ter necessidades de Autorização em qualquer um dos níveis. No caso, as regras que a Alice precisa suportar são RBAC em sua maioria, com alguns casos de ABAC e ReBAC. Isso significa que a solução escolhida precisa também suportar esses modelos de autorização; somente RBAC não é suficiente (ou envolveria muito improviso para fazer).

Nossa abordagem original de Autorização

Sendo uma empresa de saúde, a Alice evidentemente tem muito contato com informações pessoais e de saúde. Portanto, um mecanismo de Autorização é essencial para garantir que dados não sejam acessados ou modificados por pessoas não autorizadas, sejam médicos, enfermeiros ou até o time de atendimento operacional.

Inicialmente optamos por manter a camada de Autorização junto à nossa camada compartilhada de acesso a dados (Data-Layer), que já realiza outras atribuições, como tokenização dos registros, de-identificação e afins. Através de uma DSL fluida, avaliamos quatro parâmetros essenciais para tomar uma decisão de Autorização:

• Root Service: o serviço do qual se originou a solicitação. Isso é importante pois um mesmo usuário pode ter permissões distintas em sistemas diferentes.
• Subject: o usuário atual.
• Resource: o recurso que se deseja acessar.
• Action: a ação que o usuário deseja realizar no recurso. No contexto de acesso a dados, consideramos as ações CRUD (Create, Read, Update, Delete).

Também partimos do princípio de “Least Privilege”, o que significa que qualquer acesso precisa necessariamente ser liberado via a escrita de Policies, ou regras de autorização, na DSL supracitada. Caso contrário, o acesso por padrão é negado. Essas regras são deployadas junto ao Data-Layer, e toda alteração das mesmas exige uma nova versão em produção para ser efetiva e impactar os usuários finais.

Problemas

A abordagem que inicialmente escolhemos nos permite grande liberdade na tomada de decisões de Autorização, mas vem com os seguintes contrapontos:

• Acoplamento com o Data-Layer: não podemos alterar policies sem redeployar o serviço; regras de certos domínios acessam diretamente dados de outros domínios sem passar pelo serviço correspondente, quebrando o encapsulamento. Gera acoplamento da própria camada de dados com os modelos servidos por ela.
• Testes: não é trivial escrever testes das policies e é comum haver erros em tempo de desenvolvimento descobrindo que esquecemos de incluir uma policy necessária.
• Isolamento (“siloing”): a alteração de policies é altamente técnica e só pode ser feita por desenvolvedores back-end. Não há UI ou facilitador para isso.
• Escopo: limitado somente à camada de acesso a dados; isso significa que, com esse mecanismo, não temos capacidade de tomar decisões de exibição de itens visuais no front-end de acordo com o perfil do usuário, por exemplo.

Com esses aspectos em mente, olhamos para o mercado procurando por uma solução de Autorização que suportasse as nossas necessidades, ao mesmo tempo que mitigasse a maior parte possível desses problemas.

Alternativas consideradas

Um ponto importante na hora de elencar a solução: não tínhamos a intenção de mudar o mecanismo de Autenticação utilizado atualmente, o que significa que soluções que fazem a “venda casada” com Autorização (por exemplo, keycloak e aserto) não resolveriam nosso problema.

Assim sendo, encontramos duas alternativas mais em linha com o que buscávamos:

• Oso Cloud
• Open Policy Agent (OPA)

Após uma análise minuciosa, preferimos seguir com o OPA, em vez do Oso Cloud, devido a alguns fatores:

• o Oso é menos flexível e a migração das nossas policies atuais seria mais trabalhosa.
• o Oso é um SaaS e tem um custo associado; com nosso volume de requests esse custo pode ser bem significativo.
• o Oso tem uma UI para edição de policies, mas para escrever ABAC / ReBAC é preciso escrever as regras na linguagem Polar.

Por outro lado, o OPA tem várias características que o tornam uma boa opção para a gente. É open-source, utilizado por algumas grandes empresas, flexível e orientado à nuvem. É escrito em Golang, altamente performático e capaz de responder a um grande volume de requests de Autorização na casa dos milissegundos – característica essencial para nosso caso, pois teríamos que externalizar as chamadas de autorização, já pagando o custo de latência de rede.

Outra característica que tornava o OPA mais atrativo era que as regras são escritas na linguagem Rego , que apesar de não ser tão simples é flexível o bastante para implementar RBAC, ABAC, ReBAC e outros tipos de controle de acesso. As regras e dados de autorização são alimentados no serviço e ficam disponíveis em memória, e podem ser substituídos em tempo de execução.

Além disso, o usuário do OPA é quem define o formato do input (os dados de autorização relativos a um dado request) e o formato do output (quais permissões são calculadas e retornadas), então ele pode ser usado em mais de um contexto.

Além de tudo isso, há um forte ecossistema em torno do OPA, com várias ferramentas construídas para facilitar sua adoção em escala, e até mesmo uma versão Enterprise.

Como o OPA endereça nossos problemas

• Acoplamento com o Data-Layer: o deploy de novas policies é feito diretamente no OPA e não precisa nem redeployar o serviço, pois ele tem suporte a hot-reload (apontando para um bucket do S3, por exemplo). O OPA pode também ter uma base de dados de Autorização, que torna mais simples a implementação de ReBAC em vez de ficar buscando esses dados em real-time no momento do request.
• Testes: toda policy pode e deve ser testada unitariamente; os testes são rápidos e podem ser incluídos na sua pipe de CI. Em termos de garantir que os dados esperados são efetivamente enviados para o OPA, essa responsabilidade fica com os testes do seu sistema.
• Isolamento (“siloing”): infelizmente o OPA não resolve este ponto muito bem, pois é necessário escrever código e não há UI que facilite o processo. Mas um ponto positivo é que quem cuida das policies não precisa ser o mesmo time dono dos dados, pode ser um time focado nisso.
• Escopo: dependendo de como forem escritas as regras, pode-se usar um mesmo servidor do OPA para atender a requests de Autorização de várias fontes. Na Alice, conseguimos escrever de uma forma que a mesma regra calcula permissões para o front-end (quando tenho dados somente do usuário acessando) e para o back-end (quando tenho as demais informações de recurso e ação, por exemplo).

Conclusão

Apesar de ser um problema bastante comum no desenvolvimento de sistemas, pode ser desafiador encontrar uma solução de Autorização que case bem com as suas necessidades. É importante estudar com calma as alternativas, realizar Provas de Conceito em escopos menores e ter um bom plano de migração quando já há bastante coisa construída no esquema atual.

Esse é o tipo de problema que faz muito sentido ser endereçado pelo time de Plataforma, pois causa um grande impacto ao longo de todas as camadas de desenvolvimento, e precisa de grande apoio das lideranças para efetivamente sair do papel.

——————————————————————————————————-

Alice is a technology company with the mission of making the world healthier. But like any tech company, it faces common challenges and must decide how to address them. This article explains some of the authorization-related problems we encountered, explores the alternatives we considered, and shows how the solution we chose solves these problems (while inevitably creating others as well ).

What is Authorization? How is it Different from Authentication?

Before diving into the details, it’s important to recall the difference between Authentication and Authorization—two concepts that often go together but are fundamentally different.

In short, Authentication is the process of identifying a user, ensuring that they are who they claim to be. Authorization, on the other hand, is the process of determining whether an identified (or even unidentified) user has permission to perform certain actions within the system.

The solutions and frameworks available may handle one or both aspects, which is important to consider when making a choice. You might, for example, be forced to use a solution’s Authentication component just to make its Authorization component work. Depending on the case (as was true for Alice), this may not be desirable.

Common Types of Authorization

There are several types of Authorization, covering most of the common needs of modern systems. Here are the main ones:

• Role-Based Access Control (RBAC): The most common type of access control, in which roles are assigned to users, defining what each role can do. Roles can be assigned or revoked at any time, and the system adjusts behavior accordingly.
  • Example: Bob is assigned the role of Operations Analyst and gains the ability to edit any Member (as we call the patients here in Alice) in the system.

• Attribute-Based Access Control (ABAC): Access control based on user attributes and/or the attributes of the resource being accessed.
  • Example: Bob can edit a Member in the system if his user attribute isAdmin = true, or if the Member has the attribute isPublic = true.

• Relationship-Based Access Control (ReBAC): A specific case of ABAC where permission is granted based on a specific relationship between the user and the accessed resource.
  • Example: Bob can edit a Member’s data if the record represents himself or one of his dependents.

A system may require Authorization at any of these levels. In Alice’s case, most rules follow RBAC, with some cases requiring ABAC and ReBAC. This means the chosen solution must support these Authorization models—RBAC alone wouldn’t be sufficient (or would require excessive workarounds).

Our Initial Approach to Authorization

As a healthcare company, Alice deals extensively with personal and medical information, making a robust Authorization mechanism essential to ensure that data is accessed or modified only by authorized individuals—whether doctors, nurses, or operational support teams.

Initially, we decided to implement Authorization within our shared Data-Layer, which already handled tasks like tokenizing records, de-identifying data, and other privacy and security measures. Using a fluid Domain Specific Language (code homebrewed for this purpose), we evaluated four key parameters to make Authorization decisions:

• Root service: The service where the request originated (important because a user might have different permissions in different systems).
• Subject: The current user.
• Resource: The resource being accessed.
• Action: The action the user wants to perform on the resource (CRUD: Create, Read, Update, Delete).

We also followed the Least Privilege principle, meaning access must be explicitly granted via written Policies in the DSL—otherwise, access is denied by default. These rules were deployed alongside the Data-Layer, requiring a new production release for any changes to take effect.

Problems

While this approach gave us flexibility in Authorization decisions, it also introduced some drawbacks:

• Tight coupling with the Data-Layer: Policies could not be changed without redeploying the service; some domain rules accessed data from other domains directly, breaking encapsulation.
• Testing challenges: Writing tests for policies wasn’t trivial, leading to frequent runtime errors when missing a necessary policy.
• Expertise: Policy modifications were highly technical and could only be done by backend developers—there was no UI or other tooling to facilitate this.
• Scope limitations: The mechanism only covered data access, meaning we couldn’t use it for UI-based authorization (e.g., controlling which UI elements should be displayed based on a user’s role).

With these challenges in mind, we looked for an Authorization solution that met our needs while mitigating as many of these issues as possible.

Considered Alternatives

A key requirement in our search: we had no intention of changing our existing Authentication mechanism. This meant solutions that bundled Authentication and Authorization together (such as Keycloak or Aserto) wouldn’t work for us.

Instead, we found two alternatives that better aligned with our needs:

• Oso Cloud
• Open Policy Agent (OPA)

After a thorough analysis, we decided to go with OPA instead of Oso Cloud for several reasons:

• Oso is less flexible, and migrating our existing policies would be more complex.
• Oso is a SaaS solution with associated costs, which could be significant given our request volume.
• Oso provides a UI for policy editing, but writing ABAC/ReBAC rules still requires using the Polar language.

On the other hand, OPA has several characteristics that make it a great option for us. It is open-source, used by some large companies, flexible, and cloud-oriented. It is written in Golang, highly performant, and capable of handling a high volume of authorization requests in milliseconds—an essential feature for our case since we needed to externalize authorization calls while already accounting for network latency costs.

Policies are written in the Rego language, which, although not the simplest, is flexible enough to implement RBAC, ABAC, ReBAC, and other access control models. Authorization rules and data are fed into the service, stored in memory, and can be replaced at runtime.

OPA users define the input format (the authorization data related to a given request) and the output format (which permissions are calculated and returned), allowing it to be used in multiple contexts.

Beyond all this, OPA has a strong ecosystem, with various tools built to facilitate large-scale adoption and even an Enterprise version.

How OPA Solves Our Problems

• Decoupling from the Data-Layer: Policies are deployed directly to OPA, eliminating the need to redeploy the service. OPA also supports an Authorization database, making it easier to implement ReBAC without real-time data lookups.
• Improved Testing: Policies can and should be unit tested, with fast execution that integrates into CI pipelines. Ensuring the right data reaches OPA remains the responsibility of system tests.
• Less Expertise: While OPA still requires writing code (lacking a UI for policy management), policy ownership and authoring can be assigned to a dedicated team rather than the teams managing the data itself.
• Expanded Scope: A single OPA instance can handle Authorization requests from multiple sources. At Alice, we structured our policies so the same rule could determine permissions for both the frontend (based on user attributes) and the backend (considering additional resource and action information).

Conclusion

Despite being a common challenge in system development, finding an Authorization solution that fits your needs can be difficult. It’s crucial to carefully study alternatives, run Proofs of Concept in limited scopes, and have a solid migration plan when transitioning from an existing system.

This is the kind of problem that makes sense to be handled by a Platform Team, as it impacts all layers of development and requires strong leadership support to be successfully implemented.

O post Autorização com OPA: Open Policy Agent apareceu primeiro em Blog da Alice Tech.

Hoje, o projeto faz uso do Next.js, num contexto de Server-Side Rendering (SSR) e um design system baseado em Stencil. Essa migração, porém, gerou desafios técnicos importantes que exigiram mudanças mais amplas em nossa arquitetura.

Neste artigo, exploramos os problemas e desafios que enfrentamos ao adotar essa stack, com foco em “piscas” na interface com o usuário final, e como os solucionamos e garantimos a melhor experiência e funcionalidades para quem está na ponta.

Next.js, Stencil e SSR

Quando criamos o site adotamos o Nuxt 2 como framework. Foi a escolha apropriada para o momento da empresa e as opções disponíveis à época. À medida que a Alice se desenvolveu, porém, o projeto foi crescendo em complexidade. Em poucos anos, implementamos subprodutos no site como uma calculadora de saúde, um simulador de planos e um sistema de consulta à nossa rede credenciada.

Migrar para o Nuxt 3 se provou uma opção indevida – tratava-se de um framework ainda imaturo que, por características de nossa base de código, exigiria tanto esforço quanto o necessário para migrar para outro framework. Em vez disso, optamos pelo Next.js.

Qualquer migração, porém, traz desafios. No nosso caso, precisávamos integrar perfeitamente uma aplicação em Next.js em SSR com o design system da Alice, baseado em Stencil.js, que exporta web components que podem ser encapsulados para React.

Imediatamente, enfrentamos problemas: um constante “pisca” na tela, que afetava negativamente a experiência do usuário, prejudicava as métricas do Core Web Vitals e reduzia a performance de nossas páginas em buscas no Google.

Uma investigação revelou que esse problema, conhecido como “flash of unstyled content” (FOUC), resultava da interação entre nosso design system, em Stencil.js, com projetos em SSR, como o Next.js. Mais especificamente, tratava-se de problemas na etapa de hidratação da página.

Hidratação

Vamos comparar a construção de uma página web com a montagem de uma casa. Inicialmente, você organiza a casa com móveis essenciais e decoração, preparando-a para receber visitas. Esse processo se assemelha à pré-renderização de uma página no Next.js, onde a estrutura básica é montada no lado servidor antes de qualquer interação do usuário.

Quando alguém visita a casa, não se limita a observar os móveis; interage com o ambiente, abre portas ou acende luzes. Na web, essa interação é possível graças à “hidratação”. Após a página ser carregada, os elementos se tornam interativos, permitindo ao usuário realizar ações como cliques e toques.

Como era em uma stack baseada em Nuxt 2

Numa stack baseada em Nuxt 2 já conseguíamos utilizar os Web components do design system encapsulados para Vue, mas eles eram considerados como client components. Ou seja, toda a hidratação e construção da página era feita do lado do cliente/navegador, prejudicando assim o tempo total de carregamento e, consequentemente, as notas do Core Web Vitals do site como um todo.

O projeto já tinha outros problemas relacionados a performance e experiência de desenvolvimento, pois era muito desafiador escalar páginas mantendo uma boa performance combinado com uma boa experiência de codificação e implementação de testes (unitários e e2e).

Um dos pontos que identificamos como defasado no projeto era a versão do Vue utilizada pelo Nuxt 2, pois o framework estava travado na versão 2.6.14 do Vue, que já era considerada legado. Isso nos impedia de atualizar em relação a outras soluções, como por exemplo o testing-library, cypress, design system, storybook, node, etc.

Além disso, identificamos também outros problemas de experiência de desenvolvimento como auto importação de arquivos em testes, mock de endpoints e store, tempo elevado de execução de build, test e lint.

Como a página operava no Next.js

No entanto, no Next.js, apesar de não passarmos pelos problemas citados acima, ainda precisávamos resolver a questão da hidratação dos componentes do Design System com o Next server.

Tecnicamente, a hidratação vincula o HTML pré-renderizado ao JavaScript necessário para tornar a página interativa. Então, quando o navegador carrega a página, o JavaScript é executado, permitindo interações – e esse processo é conhecido como hidratação. Ele inicializa a aplicação no lado do cliente após o carregamento, reativando event handlers e estados previamente definidos no HTML estático.

Em um aplicativo Next.js, a página é parcialmente pré-renderizada no servidor e entregue como HTML estático. Em seguida, o JavaScript necessário para sua interatividade é enviado e executado pelo navegador. Durante essa execução, ocorre a hidratação, onde o React reconecta os manipuladores de eventos e estados à estrutura de componentes já renderizada. Esse intervalo de tempo foi o que causou o “pisca” em nossa página.

Embora o Stencil já esteja implementando suporte dos web components para SSR, não poderíamos esperar o lançamento dessa funcionalidade, então por meio de uma série de estudos e benchmarking, conseguimos encontrar uma solução entre SSR e client web components.

A ideia principal era garantir que os web components do design system chegassem no cliente final totalmente hidratados e, para isso, criamos um servidor customizado em node e substituímos pelo Next server padrão onde combinamos recursos de renderização do Next com a hidratação do Stencil nos componentes do design system antes mesmo da resposta chegar no navegador.

Essa camada funciona especificamente para páginas com conteúdos totalmente estáticos, então também precisávamos encontrar uma solução para páginas dinâmicas. Para isso, usamos um conceito de Provider, que se trata da injeção de um componente em React responsável por hidratar os componentes do design system. Tudo isso foi feito de forma transparente para o usuário final, justamente na camada de Layout, ou seja, uma camada que age logo depois da resposta do servidor no navegador e antes do usuário receber a página totalmente renderizada.

Observação importante: A proposta final do Stencil é usarmos os web components como server components. Esse suporte foi disponibilizado recentemente e estamos realizando uma série de testes para consolidar de vez o Stencil + Nextjs + SSR.

Resultados

Os resultados foram observados imediatamente. Nossos Core Web Vitals subiram de 72 para 90 na comparação com a implementação em Nuxt 2, com os escores de SEO saltando de 61 para 100.

Em média, o tempo de carregamento foi reduzido em 50%.

A logística da migração

Encontrar a solução técnica é, porém, apenas metade do caminho. Só conseguiríamos extrair valor dessa iniciativa quando implementássemos a nova stack em toda nossa base de código, um processo trabalhoso e arriscado.

Dois times se dedicaram a realizar a migração: o squad de engenharia de produto de vendas, que é formalmente responsável pelo site, além de uma série de outros sistemas e entregas; e o time de plataforma em engenharia.

A primeira grande decisão a ser tomada era entre migrar de uma só vez ou reescrever gradualmente o projeto. Ambas as abordagens exigiriam esforço significativo. No entanto, a reescrita gradual permitiria que realizássemos em paralelo a transição para o Next.js com as entregas regulares do squad de vendas. Além disso, poderíamos monitorar a performance e os resultados da migração de cada funcionalidade, gerando aprendizados contínuos e refinamentos a cada página.

Optamos, então, por reescrever gradualmente todo o projeto, começando pela página inicial, avaliando métricas relevantes como conversão e performance por meio de testes A/B. O resultado foi uma implementação suave, acelerada e bem-sucedida, demarcando o modelo para migrações semelhantes no futuro.

____________________________________________________________________

The challenges of migrating to a Next.js, Stencil and SSR stack

How Alice’s engineering teams implemented a new technology stack for our website, improving load times by 50% and enhancing user experience.

Alice’s website, like many technology companies today, started as a static page. As we evolved, we integrated several functionalities that highlight our unique position as a healthtech company. To support this transition, we migrated the entire codebase to a new framework, a taxing project that yielded substantial improvements in user experience, website performance, and slashed maintenance costs.

Our current tech stack is based on Next.js with Server-Side Rendering (SSR) and a design system powered by Stencil. This migration involved significant technical challenges that necessitated broader architectural changes.

In this article, we delve into the specific problems and challenges we encountered while adopting this stack, with a particular focus on addressing “flashes” in the interface. We’ll discuss how we overcame these issues to ensure the best possible experience and functionality for our end-users.

Next.js, Stencil and SSR

When we started the website, we adopted the Nuxt 2 framework. It was a suitable choice given the company’s stage and the available options at the time. As Alice evolved, however, the project’s complexity increased. Within a few years, we implemented subproducts into the website including a health calculator, a plan simulator and a system allowing users to browse our accredited network of health community.

Migrating to Nuxt 3 proved insufficient – it was a framework still in its early stages, and due to specificities in our codebase, it would require as much effort to implement as a migration to another framework. Instead, we opted for Next.js.

Any migration, however, bears challenges. In our case, we needed to perfectly integrate an application based on Next.js in SSR with Alice’s design system, oriented around Stencil.js, that exports web components that can be encapsulated for React.

We immediately faced a significant challenge: a constant screen flashing, which negatively impacted user experience, depressed Core Web Vitals, and reduced the website’s performance in Google search results.

An investigation revealed that this issue, known as ‘Flash of Unstyled Content’ (FOUC), was a consequence of the interaction between our Stencil.js design system and SSR projects such as Next.js. More specifically, it was a problem during the page’s hydration step.

Hydration

Creating a webpage is somewhat like setting up your home. First, you organize your living room with essential furniture and decoration, preparing it to host visits. This process is similar to prerendering a Next.js page, where its basic structure is built on the server before any user interaction.

When someone visits that apartment, they don’t just look at the furniture; they interact with their surroundings, turning on lights, opening doors, and so on. On the web, these interactions are made possible by ‘hydration’. Once the page loads, all elements become interactive, allowing users to click, tap, and more.

Using a Nuxt 2 stack

In a Nuxt2 stack, we were able to utilize web components from the design system encapsulated for Vue, but they were considered client components. The whole hydration and construction of the web page happened at the client side, hampering overall load times and, consequently, the whole website’s Core Web Vitals.

We had already identified other problems related to performance and development experience. It was very challenging to scale up pages maintaining good performance, an effective coding experience and implementing e2e and unit tests.

One of the main improvement points was the version of Vue used by Nuxt 2: we were still stuck with Vue’s legacy 2.6.14 version. That prevented us from updating other solutions, such as testing-library, cypress, design system, storybook, node, etc.

We also identified other developer experience problems such as auto-importing of test files, endpoint mocks and store, and overly long times for executing build, test, and lint.

How the page operated under Next.js

Under Next.js, though we didn’t encounter the same issues, we still needed to solve the problems involved in hydrating the design system components with the Next server.

Technically, the hydrating step connects a pre-rendered HTML with the JavaScript needed to make the page interactive. In other words, when the browser loads the webpage, it executes the JavaScript, allowing for interactions – and this process is known as hydration. It starts the application in the client side after loading, reactivating event handlers and states previously defined in the static HTML.

In a Next.js application, the page is partially pre-rendered on the server and delivered as static HTML. Subsequently, the necessary JavaScript for interactivity is sent and executed by the browser. During this execution, hydration occurs, where React reconnects event handlers and state to the already rendered component structure. This time interval caused the flash on our page.

Although Stencil was developing SSR support for web components, we couldn’t wait for the launch. Through research and benchmarking, we found a solution between SSR and client web components.

Our primary goal was to ensure fully hydrated design system components on the client side. To make it happen, we created a custom Node.js server to replace the standard Next server, combining Next’s rendering resources with Stencil’s hydration in the design system components before the response reached the browser.

That layer worked well for fully static pages, but we also needed to find a solution for dynamic pages. So, we implemented a Provider concept, injecting a React component responsible for hydrating design system components. All that happened in the Layout layer, that is, a layer activated as soon as the server responds to the browser and before the end user receives the fully rendered webpage.

It’s worth noting that Stencil’s final proposal involves using web components as server components. While this feature is now available, we’re currently conducting several tests to fully integrate Stencil, Next.js and SSR.

Results

Results were observed immediately. Our Core Web Vitals rose from 72 to 90 compared to the Nuxt 2 implementation, with SEO scores jumping from 61 to 100.

Loading improved 50% on average.

Migration logistics

Finding a technical solution is, however, only half the trouble. We could only generate value from this initiative once we had implemented the new stack throughout our codebase – a long and risky endeavor.

Two teams were tasked with the migration: the engineering team in the sales squad, formally responsible for the website as well as other systems; and the engineering platform team.

The first big decision was whether to migrate the entire project at once or to gradually refactor it. While both approaches required substantial effort, a gradual refactoring would allow us to parallelize the transition with the sales squad’s ongoing work. Besides, we could monitor performance and results for each functionality, enabling continuous learning and refining at every step.

Ultimately, we chose to gradually refactor the entire project, starting with the homepage, assessing relevant metrics such as conversion and performance through A/B tests. The end result was a smooth, quick, and successful implementation, setting the standard for future migrations.

O post Migrar para Next.js e SSR: desafios e aprendizados apareceu primeiro em Blog da Alice Tech.

Neste artigo, vamos mostrar como a Alice está utilizando inteligência artificial (IA) para elevar ainda mais a qualidade do atendimento dos nossos membros – como chamamos os clientes aqui na Alice.

Entre todas as áreas do nosso negócio, o ecossistema administrativo é um dos que mais podem gerar frustrações para os usuários. Em um setor que está entre os menos populares no Brasil, queremos garantir que nossos membros tenham todo o suporte necessário para lidar com questões burocráticas. Por isso, a colaboração do time de Design, responsável por cuidar da experiência nos sistemas da Alice e criar uma jornada simples e eficiente, foi essencial para aprimorar um dos aspectos mais desafiadores do mercado de planos de saúde.

Como a Alice lida com problemas administrativos

Quando um membro da Alice enfrenta alguma dificuldade com seu plano, ele usa nosso chat proprietário para entrar em contato com uma equipe essencial: os Navegs – nosso time de atendimento ao cliente. Eles são responsáveis por apoiar nossos membros e ajudar a resolver dúvidas e problemas.

Atualmente, pagamentos e gestão de planos são os temas que geram mais acionamentos do time de atendimento quando falamos de assuntos administrativos. Dentro dessa categoria, boletos e a composição da mensalidade são as dúvidas mais frequentes. Os cenários variam: pode ser desde uma empresa que precisa apenas baixar um boleto, renegociar um pagamento, até um pedido de mudança na data de vencimento do boleto. Cada uma dessas situações exige uma abordagem diferente.

Por serem questões tão recorrentes, mas de baixa complexidade de execução, enxergamos uma excelente oportunidade para criar automação por meio de chat de inteligência artificial. Dessa forma, o atendimento poderia ser expandido para 24h por dia, 7 dias por semana, e os Navegs, por sua vez, poderiam focar em atendimentos mais complexos.

Ser um Navegs não é uma tarefa fácil. Esse time lida com vários atendimentos simultâneos, com chamados que são abertos automaticamente, e precisa fazer uma triagem antes de resolver o problema do membro. Um desafio comum dele é manter o tempo de espera curto enquanto gerencia várias ocorrências ao mesmo tempo. Garantir essa velocidade na resposta é fundamental para que o customer experience seja bom.

O atendimento na Alice pode ser dividido em quatro etapas:

Etapa 1 : Triagem (Definição, classificação e investigação do problema)

Etapa 2 : Definição (Identificação da melhor forma de resolver o problema)

Etapa 3 : Execução (Implementação da solução escolhida)

Etapa 4 : Devolutiva (Comunicação da solução ao membro)

Antes da iniciativa de chats de inteligência artificial, todas essas etapas do atendimento eram realizadas por pessoas. Agora, a inteligência artificial entrará em ação no momento que o membro abrir um chamado. Para isso ser possível, utilizamos dois agentes de IA, que nada mais são do que programas que coletam e utilizam dados estruturados para realizar tarefas predeterminadas.

Um primeiro agente, conhecido como “Classificador”, consulta nosso banco de dados para coletar informações e classificar o tema abordado. Em seguida, o segundo agente, chamado de “Explorador”, faz perguntas ao membro para entender melhor sobre o problema. Com base nas respostas, o agente cria um resumo do atendimento e passa para o Navegs que, por fim, inicia o atendimento pessoal.

Em resumo, os agentes de IA coletam os dados e só depois transferem o atendimento para um humano, já com um resumo do problema e a triagem realizada. Dessa forma, reduzimos o tempo na primeira etapa do atendimento, e o Navegs pode focar na segunda etapa (definição da solução) e dali em diante.

Com a implementação dessa automação, reduzimos a quantidade de telas que o membro precisa acessar no app até iniciar o atendimento de fato. No caso de dúvidas sobre gestão de planos, reduzimos de 4 para 3 telas e, em pagamentos, de 5 para 3 telas.

Aprendizados em Design

No time de Design da Alice, temos princípios que são fundamentais em qualquer trabalho que executamos. Colaboração e resolutividade são os que consideramos como principais neste projeto. Falaremos sobre cada um deles a seguir.

• Colaboração: Uma parte essencial dessa iniciativa tem relação com testar os prompts (tarefas que a IA precisa executar), ou seja, garantir que a IA responda corretamente de acordo com regras predefinidas. Há um equilíbrio entre automatizar cenários comuns e entender que alguns casos específicos podem não ser resolvidos pela IA de imediato. Reunimos pessoas de diferentes áreas – incluindo Design, Engenharia, Product Management e Operações – para testar os prompts. A diversidade de perspectivas foi fundamental para identificar erros e propor melhorias.
• Resolutividade: Como esse é um experimento recente e sem histórico de referência, é crucial entender o impacto dessa iniciativa. Hoje utilizamos a métrica de CSAT (Customer Satisfaction Score) para avaliar a satisfação do membro em nossas entregas. Vamos continuar acompanhando essa métrica ao longo dos próximos meses para considerar melhorias futuras.

Reflexões para o Futuro

A aplicação de inteligência artificial nos negócios é um tópico relativamente novo e cheio de desafios. Sabemos que estamos todos aprendendo juntos, e esses novos métodos de trabalho devem sempre ser explorados com uma perspectiva centrada nas pessoas que usam o nosso produto, no caso, nossos membros.

Assim, pensando nos próximos passos para desenvolver ainda mais soluções que melhorem nosso customer experience e o dia a dia dos nossos membros, disponibilizaremos uma documentação que será compartilhada com os times da Alice para que todos tenham autonomia para criar os seus próprios projetos de IA. Para mantermos uma padronização nesse processo, o time de UX Writing será fundamental para garantir a consistência de linguagem e tom de voz adequado.

Essa iniciativa foi apenas uma entre muitas baseadas na aplicação de IA por toda a Alice. Ela ilustra o papel estratégico que a nova geração de modelos de linguagem tem para o nosso negócio e os esforços para difundir seu uso em toda a companhia.

_____________________________________________________________________________________________________________________________________

Artificial Intelligence applied to customer experience

How Alice is using AI to improve client support

The healthcare sector encompasses much more than hospitals with their medical and nursing teams. Throughout the system, there is an enormous structure that handles essential day-to-day tasks for patients, such as payments, procedure authorizations, bureaucratic questions and financial charges. Optimizing this structure and ensuring safety and an excellent customer experience is a challenge.

In this article, we will discuss how Alice has been using artificial intelligence (AI) to raise the quality of customer service for our members – how we call Alice’s clients.

Health insurance plans’ users often find the administrative ecosystem one of the most frustrating areas of this business. In a sector that ranks among the least popular in Brazil, we want to ensure that our members have all necessary support to handle bureaucratic matters. The collaboration of our Design team, which is responsible for safeguarding customer experience across all systems in Alice, was essential to improve one of the most challenging aspects of the healthcare market.

How Alice handles administrative matters

When a member faces some sort of difficulty with his/her plan, he/she uses our proprietary chat to contact an essential team: Navigators – our customer service team. They are in charge of supporting our members and helping to solve doubts and problems.

Payments and plan management are currently the most frequent issues addressed by our members. Under these categories, invoices and the composition of monthly bills are the most common themes. These range from a company that needs to download an invoice or renegotiate a payment to a request for changing the maturity date on the invoice. Each of these situations requires a different approach.

Because these are recurring, low-complexity matters, we saw an excellent opportunity for automation using AI. Doing so would allow us to extend service 24/7, and the Navigators, in turn, could focus on more complex cases. The Design team played a key role in finding a solution, since it is tasked with understanding member demands and creating a simple and efficient journey.

Reformulating journeys

Navigators face a complex task. They juggle multiple concurrent support requests, including auto-generated tickets, and must triage them efficiently. A key challenge is reducing members’ wait time while managing a high volume of tickets. Timely responses are essential to deliver a superior customer experience.

Their journey can be summarized in four steps:

1: Screening (Defining, classifying and investigating the problem)

2: Definition (Identifying the best way of solving the problem)

3: Execution (Implementing the chosen solution)

4: Feedback (Communicating the solution to the member)

Before the AI initiative, human beings were tasked with all these steps. Now, the AI will step up when members get in touch. We make use of two AI agents – programs that collect and make use of structured data to take on predetermined tasks.

A first agent, known as “Classifier”, browses Alice’s database to collect information and classify the member’s complaint under one of several themes. Then, a second agent, known as an “Explorer”, poses questions to the member to better understand the matter. Based on the answers, the agent generates a summary that is sent to the Navigator, which, finally, begins the one-on-one interaction.

AI agents collect data and only then hand the member over to a human, having finished a screening process and delivering a complaint summary. This reduces the time spent in the first step, allowing the Navigator to focus on the second to fourth steps.

With this implementation, we reduced the amount of screens the member has to move through until he reaches the actual interaction with a Navigator. For plan management matters, this number fell to 3 from 4 and, for payments, to 3 from 5.

Design learnings

In Alice’s design team, we hold a few principles as fundamental to all of our work and this feature exemplifies this. In particular, we believe this project showcased our focus on Collaboration and Resolutivity.

• Collaboration: An essential part of this initiative was testing prompts (tasks that the AI executes) – that is, ensuring that the AI answers correctly based on predefined rules. There’s a tradeoff between automatizing common scenarios and understanding that some specific cases cannot be solved immediately by the AI. Several different areas at Alice – including Design, Engineering, Product and Operations – collaborated in testing those prompts. Having a diversity of views was essential to identifying errors and proposing improvements.
• Resolutivity: Because this is a recent experiment with no prior history, it is crucial to understand its impact. Currently, we focus on CSAT (Consumer Satisfaction Score) and will be tracking that performance indicator in order to iterate on the agents.

Looking forward

Deploying AI to solve business problems is a relatively new topic that is full of challenges. We are learning collectively, and new ways of working must always be explored  with a client-centric approach.

For the next steps in developing even more solutions that improve customer experience and day-to-day experience, we will develop documentation that will be shared with all teams at Alice so that all are able to autonomously take on AI projects. Our UX Writing team will be key in ensuring language consistency and an adequate voice.

This initiative is one among many based on implementing AI solutions throughout Alice. It highlights the strategic role that the new LLM generation plays in our business and efforts to democratize its use across the company.

O post IA aplicada ao customer experience na Alice apareceu primeiro em Blog da Alice Tech.

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.

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.

Certo dia fui surpreendida por um evento na minha agenda: “Café Legal.”

Era um convite de duas pessoas do Time de Legal da Alice para um café. Dentre outras coisas, elas queriam entender mais sobre a Área de Produto e como elas poderiam contribuir de forma ativa com as nossas tomadas de decisão.

Falamos sobre amenidades, eu expliquei um pouco sobre as Áreas de Produto e Tecnologia e quando me questionaram sobre como poderiam ser mais participativas nos nossos processos, eu inconscientemente respondi: “precisamos inserir vocês nos nossos discoveries.”

Falei isso com certa naturalidade e fiz uma pausa. Elas me olharam com cara de “quê?”. E então perguntei: vocês sabem o que é discovery?

Elas não sabiam. E isso, de forma alguma, é um demérito. Nós, que trabalhamos com produtos digitais, estamos muito acostumados com determinados termos, que acabamos utilizando com pessoas que não lidam diretamente com o nosso universo.

Expliquei para elas o que vou resumir aqui:

Discovery, como o nome já indica, é um processo de descoberta: existe um problema, existem hipóteses de como resolver esse problema e, baseado nessas hipóteses, existem as possíveis soluções.

No discovery, buscamos encontrar a melhor solução para um problema sob três pilares: usuário (UX), tecnologia (viabilidade) e negócios (alinhamento estratégico).

E, embora o discovery seja, muitas vezes, liderado por uma pessoa de produto (PM), ele é executado em conjunto com Product Designers e pessoas de desenvolvimento (tech), que têm papel fundamental para se obter um bom resultado.

Como estamos descobrindo a melhor forma de “descobrir” na Alice

Somos uma empresa early stage e sempre estamos descobrindo a melhor forma de fazer alguma coisa.

Uma das nossas virtudes é: “Subimos a barra, evoluímos todos os dias”. E para o processo de discovery não é diferente.

Iniciamos no melhor modelo free style.

Cada PM, com sua experiência e bagagem de aprendizados, iniciou e concluiu diversos processos de discovery. E os resultados, naturalmente, tiveram méritos, falhas e novos aprendizados.

Decidimos nos reunir para unificar esse processo, juntar nossas forças para preencher as lacunas de cada processo individualizado.

E chegamos a um framework que vou detalhar a seguir.

Framework de Discovery da Alice

Para apresentar o framework, vamos usar um suposto problema como exemplo:

Muitas pessoas do Time de Saúde estão reportando baixa adesão dos membros ao plano de ação.

Plano de ação é uma lista de tarefas que o Time de Saúde estabelece com o membro com o objetivo de tornar sua vida mais saudável. As tarefas podem variar entre: iniciar uma atividade física, realizar um exame, se consultar com um especialista, tomar um medicamento, fazer acompanhamento com Nutricionista, entre outras coisas.

Esse framework está dividido em 2 grandes etapas:

1. Entendimento do problema e levantamento de hipóteses;
2. Validação ou redução do grau de incerteza das hipóteses e proposta de solução;

Cada uma dessas etapas é marcada por um evento que reúne as pessoas envolvidas com o tema central do discovery.

1ª Etapa: entendimento do problema e levantamento de hipóteses

Ser PM é fazer escolhas, sempre — ser humano é fazer escolhas, sempre!

Como PM precisamos escolher qual problema resolver primeiro. Isso porque existem recursos limitados para desenvolver soluções. Essa etapa tem dois objetivos principais:

1. Responder se o problema é relevante (qual é o impacto dele) e se existe alinhamento estratégico para priorizar a solução desse problema;
2. Levantar hipóteses para solucionar esse problema;

É sempre importante frisar que hipóteses não são soluções. As hipóteses estão mais relacionadas a “o que deve ser feito” para se obter determinado resultado, enquanto as soluções estão relacionadas a “como isso deve ser feito”.

Eu sugiro escrever as hipóteses utilizando esse modelo: se [variável], então [resultado], porque [racional].

Utilizando o problema de exemplo: se [as pessoas tivessem uma maneira mais fácil de agendar seus exames], então [o engajamento delas com o plano iria aumentar], porque [verificamos que + de 45% das pessoas demoram mais de 15 dias para agendar seus exames e aproximadamente 25% das pessoas não realizam o agendamento].

A hipótese aqui: as pessoas têm dificuldades para agendar exames.

A solução a gente deixa para a segunda etapa.

Nessa primeira etapa vamos a fundo no entendimento do problema. Entre outras coisas, fazemos entrevistas com as pessoas envolvidas, shadowings (passar um tempo acompanhando a rotina dessas pessoas ou, até mesmo, assumir esses papéis), análise de dados, análise da evolução do produto, etc…

Como resultado dessas ações, temos um documento contendo:

[x] Descrição do problema
[x] Descrição do impacto do problema
[x] Evidências (quali/quanti) do problema a ser resolvido
[x] Impacto no OKR
[x] Proposta de hipóteses

Essa etapa é marcada pelo evento Discovery Kick-off, onde reunimos os principais stakeholders para apresentar o problema e as hipóteses de solução. Nesse evento buscamos o buy-in dos envolvidos para seguir para próxima etapa.

Ou seja, baseado no que sabemos até aqui: podemos afirmar que o problema é relevante, e o desenvolvimento de uma solução — agora — está alinhado estrategicamente com a empresa?

Se sim, next (se não, re-prioriza)

2ª Etapa: validação das hipóteses e proposta de solução

Ótimo. Já conhecemos a fundo o problema e já temos em mãos algumas hipóteses de como solucioná-lo. Mas como saber se essas são hipóteses válidas? Existem algumas formas.

Vamos usar como exemplo a hipótese descrita na primeira etapa: se [as pessoas tivessem uma maneira mais fácil de agendar seus exames], então [o engajamento delas com o plano iria aumentar], porque [verificamos que + de 45% das pessoas demoram mais de 15 dias para agendar seus exames, e aproximadamente 25% das pessoas não realizam o agendamento].

Aqui o problema é o baixo engajamento ao plano e a hipótese é que isso se deve à dificuldade de agendamento de exames.

Uma das formas de validar as hipóteses é entrevistar as pessoas que possuem baixa adesão ao plano. Nessas entrevistas, perguntamos a elas se aumentaria a probabilidade de adesão ao plano se houvesse uma forma mais fácil de agendar os exames.

Perguntamos também sobre outras hipóteses de solução a fim de entender quais são mais aderentes.

Outra forma complementar a essa, é simular um cenário onde enviamos um formulário para o membro para coletar informações sobre o melhor dia/horário de realização de exames e fazemos o agendamento pela pessoa.

Ao final desta simulação, comparamos se o engajamento ao plano dessas pessoas aumentou em comparação às demais.

Sim? Sinal de que estamos no caminho certo!
Entrevistas, cenários simulados e benchmarks são algumas formas de reduzir incertezas em relação às hipóteses.

Nesse momento algumas hipóteses serão validadas, outras terão seu grau de incerteza reduzido, e outras cairão.

Com base nas hipóteses validadas, partimos para o desenho da solução.

Utilizando o mesmo exemplo, o que fazemos aqui é propor qual é a melhor forma de facilitar o agendamento de exames.

Podemos ter como solução, uma funcionalidade de agendamento de exames no app da Alice. Sendo assim, criamos um protótipo dessa funcionalidade e selecionamos pessoas para testarem a solução.

Minha sugestão é, se possível, desenvolver protótipos navegáveis de alta fidelidade.

Isso ajuda muito a ter resultados de testes mais assertivos, e, não menos importante, é uma documentação bastante robusta para posterior alinhamento com todos os envolvidos.

Com o protótipo em mãos, partimos para os testes, e inicia-se o famoso ciclo — teste > feedback > iteração — até chegarmos à solução final.

Aqui na Alice usamos e abusamos do Maze para testes de usabilidade. É uma ferramenta incrível, que nos ajuda a ter mais alcance, e resultados mais estruturados.

Ah, e sabe o Time de Legal?

Então, esse é um ótimo momento para envolvê-lo se você entender que a solução proposta pode ter algum impacto jurídico.

Ou apenas para pegar a opinião deles, porque eles são “legal” — (tudumtss).

Ao final dessa etapa complementamos nosso documento de discovery com mais esse checklist preenchido.

[x] Descrição da solução (fluxograma, protótipo, casos de uso, etc.)
[x] Evidências de validação / invalidação das hipóteses
[x] Validação da solução com users
[x] Roadmap
[x] Métricas de sucesso
[ ] Alinhamento com stakeholders

Para coroar, convidamos os stakeholders envolvidos para um evento que chamamos de Discovery Sign-off, apresentamos a solução final e nos alinhamos sobre os próximos passos.

[x] Alinhamento com stakeholders

Para finalizar…

Todo esse framework pode dar, à primeira vista, a impressão de excesso de burocracia. Mas ele é só uma trilha, e não um trilho — parafraseando o Time de Saúde da Alice em relação aos protocolos de saúde. Cumprir todas essas etapas, ou apenas parte delas, depende da complexidade e impacto do problema e do grau de incerteza em relação às hipóteses.

O discovery ajuda a validar hipóteses, mas dificilmente será possível reduzir a zero o grau de incerteza em relação a elas.

Muitas vezes é importante arriscar. A verdade é que uma hipótese somente será 100% validada quando a solução derivada dela estiver em uso.

Muito embora o discovery seja uma importante ferramenta para evitar custos que são evitáveis com a implementação de uma solução que tem grandes chances de não funcionar, ele é, também, um processo que custa caro. É preciso escolher quais batalhas lutar!

O post Discovery: a forma de descobrir da Alice apareceu primeiro em Blog da Alice Tech.

Como padrão, no Javascript utilizamos o camelCase para nomenclatura de variáveis ​​e funções, e é possível encontrar essa definição nos principais guias de estilo de JS, como o standardjs ou o airbnb. E aqui na Alice, nós também seguimos esse padrão para os projetos de Front-end.

Uma das decisões que tomamos ao definir o padrão para nossas APIs é que usaríamos JSON com snake_case pois consideramos que para a leitura de logs por humanos, esse formato é mais legível do que camelCase. No nosso Back-end, feito em Kotlin, utilizamos a biblioteca em java, GSON. Ela transforma os objetos JAVA em uma representação em JSON e vice-versa. Para que a serialização/deserialização funcionasse com snake_case foi necessário passar o parâmetro FieldNamingPolicy com o valor LOWER_CASE_WITH_UNDERSCORES na configuração do client do GSON. (Imagem abaixo)

Dessa forma ficamos com o padrão snake_case no Back-end em todas as nossas APIs e camelCase em todos os projetos de Front-end, ou seja, o corpo de nossas requisições e respostas HTTP são formados por um JSON com padrão snake_case.

Com isso temos o seguinte problema: Como utilizar camelCase no Front-end, sendo que todas as solicitação para as nossas APIs HTTP teriam que ser feitas com snake_case?

A Solução

Para realizar nossas chamadas HTTP no Front-end, utilizamos a biblioteca ky ( ), que adiciona algumas funcionalidades da fetch API, entre elas, os hooks que permitem modificações da requisição e de seu payload durante o ciclo de vida dessa chamada.

Conseguimos então, resolver esse problema criando um conversor, antes das requisições e após as respostas, utilizando os hooks beforeRequest (que permite modificar a requisição antes dela ser enviada) e afterResponse (que permite alterar a resposta da requisição):

• beforeRequest: Vamos converter o corpo da nossa requisição de camelCase para snake_case.
• afterResponse: Vamos converter o corpo da nossa resposta de snake_case para camelCase.

O código JS ficaria da seguinte forma:

Esse código é open source

Criamos um pacote para permitir essa e outras alterações de case em nossas requisições, e decidimos abrir o código dessa solução:

alice-health/ky-hooks-change-case

Inclusive, esse pacote foi adicionado como biblioteca relacionada no repositório oficial do KY. Sinta-se a vontade para abrir pull requests com melhorias, correções ou mandar qualquer comentário. Já utilizou o ky e/ou hooks para outros casos de uso? Compartilhe com a gente aqui nos comentários quais  .

Kudos e agradecimentos à Diego Leme pela contribuição na biblioteca e início desse post.

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 JSON: integrando Back-end e Front-end na prática 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.

Pode até não parecer, mas eu fiz questão de deixar isso claro durante todo o meu processo de contratação, e o fato da Alice ter me dado esse voto de confiança já diz muito sobre a empresa: aqui, estamos mais interessados no brilho nos olhos e na vontade de aprender de cada um do que nas qualificações técnicas ou o conhecimento de ferramentas específicas.

Logo no começo da minha jornada por aqui, entrei para o squad de Privacidade que temos, que envolve pessoas das mais diversas áreas dentro da empresa {como Produto, Engenharia, Jurídico, TI, Financeiro…} e marquei conversas individuais com cada um como forma de entender um pouco sobre o que já tínhamos feito até o momento e qual a nossa visão para o futuro. Foi assim que tive dimensão do desafio e de sua importância para a Alice.

A importância da privacidade para a Alice

Aqui na Alice, a gente lida com dados muito sensíveis sobre a saúde dos nossos membros, o que inclui nossos funcionários e o que chamamos de membros “externos”, que são as pessoas que compraram nosso produto {e são apaixonadas por ele}.

Para uma empresa como a nossa, não preciso nem dizer o quão importante é conseguirmos garantir a segurança e a privacidade dos dados que coletamos.

Um possível ataque ou vazamento de dados, como vimos recentemente acontecer com o STJ {que teve seus sistemas criptografados por um ransomware} ou com o Ministério da Saúde {que acabou tendo a chave para acesso a dados de mais de 200 milhões de brasileiros divulgada} pode prejudicar não só a reputação e marca da Alice, como acarretar em multas e, pior, na perda da confiança dos nossos membros.

Para aumentar o tamanho do desafio {ainda bem, porque se fosse fácil eu nem estaria aqui pra contar essa história}, o produto oferecido pela Alice é um produto que depende do compartilhamento de dados de saúde entre diferentes profissionais e instituições.

Esse compartilhamento existe para que possamos fazer o que chamamos de “coordenação de cuidados”, que nada mais é que um termo bonito para dizer que, aqui, queremos que nossos membros tenham experiências mágicas, do tipo:

• Chegar numa consulta com um especialista que já te recebe pelo nome, sabe todo o seu histórico e o motivo do atendimento
• Depois da consulta, conversar com o seu Time de Saúde {o time de médicos, enfermeiros, preparadores físicos e nutricionistas que cuida de cada membro Alice} e perceber que eles já sabem o que foi discutido e quais foram as recomendações do especialista
• Ir ao laboratório fazer um exame e, ao se identificar {só com o CPF, nada de códigos e carteirinhas}, já ser atendido por alguém que tem todo o seu encaminhamento e contexto dos pedidos

Por esse motivo, desde a sua concepção, a Alice tem a privacidade dos membros como um dos seus pilares. Mas como fazemos isso quando dependemos tanto justamente do compartilhamento de informações sensíveis para entregarmos mais saúde aos nossos membros?

Cultura e tecnologia como ferramentas para entregar privacidade

A resposta para essa pergunta {como garantir privacidade em uma empresa cujo business model parte da premissa do compartilhamento de dados sensíveis?} passa por duas principais alavancas: a criação de uma forte cultura de segurança de dados e respeito à privacidade dos membros e a utilização da tecnologia como ferramenta viabilizadora para a execução de melhorias nos produtos e processos da empresa.

Cultura

Um dos conceitos mais importantes que temos como mantra aqui na Alice é o de Privacy by Design. De forma bem simplificada, Privacy by Design é uma forma de abordar e resolver desafios de privacidade logo na concepção de um produto, e não após o produto ser lançado e o risco ser identificado.

Isso significa, por exemplo, que os PMs {Product Managers} e desenvolvedores da Alice têm uma atuação proativa para entender a melhor forma de criar uma nova ferramenta que já nasça adequada à proteção da privacidade dos nossos membros. Não preciso nem dizer que essa forma de desenvolver produtos é muito mais eficiente e segura do que se, no futuro, tivéssemos que adaptar ferramentas já existentes para adequá-las do ponto de vista de privacidade.

Inclusive, para uma empresa que cresce de forma tão acelerada, como é o caso da Alice, lançando novos produtos e funcionalidades semanalmente, ter os conceitos de Privacy by Design embutidos na cultura dos times é essencial para garantir que não estejamos sempre correndo atrás do prejuízo e fazendo remendos em nossas ferramentas e produtos, e consigamos manter a agilidade necessária e esperada de uma startup com ambições tão grandes quanto as nossas.

Além dos princípios do Privacy by Design, uma forte cultura de privacidade ajuda a garantir que os funcionários da Alice sigam outras boas práticas de privacidade, como por exemplo:

• A não exposição de dados pessoais de membros em canais de comunicação internos com muitos colaboradores {por aqui, usamos o Slack}
• A utilização da mínima quantidade de dados pessoais possível em determinado processo ou fluxo de informações
• A garantia de que softwares utilizados para o tratamento de dados pessoais possuam determinados requisitos de segurança e proteção à privacidade {no caso de dados de saúde, temos também a exigência de que todos os softwares sejam HIPAA-compliant}

Ainda falando sobre a importância da cultura nesse processo, uma das principais virtudes que temos na Alice é a transparência com nossos membros, parceiros e também entre nossos times. A união da transparência com a cultura de privacidade da Alice resultou na Política de Privacidade mais incrível desse Brasilzão — nela, nossos membros podem tirar todas as suas dúvidas a respeito do que fazemos com seus dados e quais são seus direitos sobre eles.

Para se manter e fortalecer essa cultura de proteção à privacidade de dados, não existe atalho ou segredo: é muito importante que existam sessões de treinamento recorrentes, com o suporte das lideranças da empresa, e que o assunto seja sempre abordado em fóruns públicos em que todos poderão se educar e tirar suas dúvidas sobre o tema.

Tecnologia

A Alice é, antes de mais nada, uma healthtech. Aqui, acreditamos que a tecnologia é fundamental para conseguirmos entregar mais saúde aos nossos membros.

É graças a ela que conseguimos escalar soluções de coordenação de cuidados {como eu expliquei lá atrás}, realizar o contato proativo com os nossos membros exatamente nos momentos adequados ou garantir que estejamos sempre a um clique de distância através do Alice Agora {nossa ferramenta de chat instantâneo entre o membro e nossos Times de Saúde}.

Além de acreditarmos na tecnologia para a entrega de saúde, entendemos que ela é também peça essencial para a promoção da privacidade dos membros. Através dela, nós implementamos medidas como:

• A separação entre os dados de saúde {não identificados} e os dados pessoais dos nossos membros em duas estruturas de bases de dados separadas, com uma terceira base {guardada a sete chaves} funcionando como a chave para identificar os dados de saúde. Assim, protegemos a identidade dos nossos membros caso ocorra um possível vazamento {toc, toc, toc} da base com dados sensíveis
• A de-identificação dos dados dos nossos membros {o uso de um código interno nas nossas rotinas operacionais, ao invés de usarmos nomes ou CPFs}
• A automatização do envio e recebimento de dados de saúde para/dos nossos especialistas {lembra que, ao realizarem um atendimento, eles já têm todo o contexto e histórico médico de quem estão atendendo?}
• A disponibilização dos resultados de exames diretamente no nosso app {assim, os membros não precisam ficar enviando PDFs por e-mail para o seu Time de Saúde, que consegue acessar os resultados de forma automática}
• A restrição do acesso às nossas bases e sistemas apenas às pessoas essenciais

E agora? O que vem a seguir?

Apesar de já termos percorrido um bom caminho para chegarmos até aqui, sabemos que o trabalho de promoção da segurança e privacidade dos dados na Alice {e em qualquer empresa} é um que nunca acabará: sempre teremos novos fluxos de dados para serem mapeados {já contei que é muito importante termos um mapa de tudo o que acontece com os dados pessoais na empresa? só assim podemos priorizar o desenvolvimento de melhorias nos diferentes fluxos}, novos colaboradores com quem compartilharmos nossa visão de como executar privacidade {e aprendermos no processo!} e novas demandas de funcionalidades para quebrarmos a cabeça durante seu desenho {lembra do Privacy by Design?}.

Dito isso, tenho confiança de que a Alice já é, e será cada vez mais, referência na forma como pensamos em privacidade em saúde. E fico muito feliz de fazer parte de tudo isso.

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 Privacidade em healthtechs: como a Alice garante segurança apareceu primeiro em Blog da Alice Tech.