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.