DEV Community: Paulo Cesar Jr

APIs de tradução em nuvem estão com os dias contados

Paulo Cesar Jr — Mon, 08 Dec 2025 17:36:07 +0000

A primeira vez que precisei usar uma API de tradução foi durante o desenvolvimento de um sistema que traduzia sinopses de filmes. Eu consultava uma API pública chamada OMDb, que retornava todas as informações exclusivamente em inglês. A solução mais prática era integrar meu front-end com um serviço de tradução, e naquela época optei pelo Amazon Translate.

Felizmente, tudo funcionou muito bem. Porém, como acontece com a maioria das APIs de tradução, o custo por volume de textos traduzidos era alto e acabei deixando de lado aquela aplicação, que era apenas mais um hobby.

Curiosamente, alguns anos depois, estou aqui escrevendo que o fim das APIs tradicionais de tradução está mais próximo do que imaginamos. E o responsável por isso? A boa e nem tão velha assim inteligência artificial.

Tradução client-side

Se pararmos para pensar, uma API de tradução nada mais é do que um grande dicionário que, dado um input no idioma X, retorna um output no idioma Y. Entretanto, o custo desse tipo de aplicação tende a ser elevado pelo número de caracteres do conteúdo a ser traduzido e pela complexidade de tradução entre diferentes idiomas.

Com a evolução das LLMs (Large Language Models), hoje você pode pedir facilmente para qualquer agente de IA traduzir um texto para praticamente qualquer idioma. Por que então não usar esse potencial diretamente nos browsers para facilitar a vida dos desenvolvedores web? Esse momento chegou.

A Translator é a nova API JavaScript disponível no Google Chrome a partir da versão 138. Ela permite traduzir textos diretamente no client-side, sem precisar consultar APIs de terceiros ou serviços em nuvem. Isso reduz custos e processamento, já que o desenvolvedor precisa apenas configurar o dicionário com o idioma de origem e o idioma de destino para realizar a tradução.

Translator do Google

Por se tratar de uma funcionalidade bem recente do Chrome, o primeiro passo para testarmos esse recurso é verificar sua compatibilidade via JavaScript:

if ('Translator' in self) {
  // A Translator API é suportado.
}

Em seguida, é necessário fazer o download do modelo de IA responsável por realizar as traduções. Esse download acontece apenas na primeira vez que o site solicita o recurso, o que otimiza o carregamento e reduz consideravelmente o tempo de execução nas próximas chamadas.

Para baixar o modelo, precisamos informar o idioma de origem e o idioma de destino nos campos sourceLanguage e targetLanguage:

const translatorCapabilities = await Translator.availability({
  sourceLanguage: 'en',
  targetLanguage: 'pt',
});
// 'available'

Após criado, podemos usar a função .translate() para traduzir qualquer string. A API se encarrega de retornar o conteúdo no idioma configurado:

// Cria um tradutor do idioma Inglês para Português do Brasil
const translator = await Translator.create({
  sourceLanguage: 'en',
  targetLanguage: 'pt',
});

Ao executar a função .translate() passando uma string para tradução, a API se responsabiliza por traduzir o conteúdo para o idioma configurado:

await translator.translate('I love listening to Kiss while I'm programming!');
// "Eu adoro ouvir Kiss enquanto programo!"

O fim das APIs de tradução na nuvem?

Me arrisco a dizer que as APIs de tradução em nuvem não serão extintas, mas certamente sua popularidade deve cair. A possibilidade de traduzir textos diretamente no client-side usando LLMs é significativa, reduzindo custo computacional e evitando despesas extras no projeto.

Obviamente, tudo depende da adesão dos outros grandes navegadores do mercado, como Safari, Edge e Firefox. Mas, como acontece com qualquer bom recurso JavaScript, é apenas uma questão de tempo até que ele possa ser usado em praticamente qualquer lugar.

Ainda vale a pena escrever CSS?

Paulo Cesar Jr — Tue, 26 Aug 2025 12:41:48 +0000

Antes de começar a expor minha opinião sobre esse tema polêmico, quero adiantar a conclusão deste artigo: sim, ainda vale a pena escrever CSS! Mas com algumas ressalvas importantes, que vou tentar abordar aqui.

Como desenvolvedor front-end, sou um grande fã de CSS, especialmente de estruturas bem organizadas e reutilizáveis. No entanto, com a evolução da linguagem, o surgimento de diversos frameworks e utilitários de IA capazes de gerar CSS com facilidade, surge a questão: até que ponto precisamos realmente conhecer e dominar a escrita de CSS?

Criadores vs Consumidores de CSS

É comum que times de desenvolvimento que mantêm style guides de suas aplicações precisem evoluir seus componentes e estilizações. Isso exige que o desenvolvedor tenha domínio sobre as propriedades CSS desses componentes. No entanto, essa não é a realidade para a maioria dos desenvolvedores que apenas consomem esses componentes, já que não há necessidade de conhecer todas as regras e detalhes da estilização dessas partes.

Imagine que você está prestes a criar um sistema de agendamento e decide utilizar o Material UI como biblioteca de estilização. Ao criar uma tela de cadastro de eventos, você não precisará se preocupar com o espaçamento das grids ou a tipografia dos botões. Você simplesmente adicionará os componentes desejados à sua interface e esperará que eles funcionem corretamente.

A questão é que a maioria dos times de desenvolvimento atua como consumidora de bibliotecas de CSS, e não como criadora. Esse contraste impacta diretamente a capacidade dos desenvolvedores de dominar ou não a linguagem.

O início do fim

Eu diria que a necessidade de um desenvolvedor front-end se especializar em CSS começou a diminuir com o surgimento dos frameworks de estilização. Lembro bem que o primeiro que utilizei foi o Bootstrap, há cerca de 10 anos. Na época, eu estava bastante focado em dominar o CSS e conhecer a maioria de suas propriedades. Por isso, foi uma dificuldade entender a mecânica de colunas e linhas do Grid. Até que, em um belo dia, percebi que o tempo de desenvolvimento de qualquer site ou aplicação reduzia pela metade, simplesmente pelo fato de não ser mais necessário escrever uma única linha de CSS ao usar o Bootstrap!

Nessa mesma época surgiu a necessidade de toda aplicação web ser responsiva para dispositivos móveis, o que caiu como uma luva para quem trabalhava com Bootstrap. O sistema de prefixos de resolução resolvia muito bem essa tarefa, dispensando o esforço do desenvolvedor em lidar diretamente com media queries no CSS nativo. Bastava usar classes como col-sm-12 ou col-md-6 para definir como os elementos se comportariam em diferentes tamanhos de tela, sem escrever uma única linha de CSS adicional.

Desde então, comecei a ouvir comentários que até aquele momento não eram muito comuns. Algo como: “Por que vou escrever CSS se o Bootstrap já faz tudo por mim?”

Frameworks não fazem tudo

Atualmente, é difícil listar o que uma ferramenta de CSS, seja qual for, não é capaz de fazer. Os frameworks facilitam desde a construção de grids até o uso de estilos pré-montados, como os que popularizaram o Tailwind. Mas eu diria que todos eles têm um calcanhar de Aquiles em comum: animações.

Ao utilizar qualquer framework ou biblioteca, é preciso estar disposto a se adequar às regras impostas por essas ferramentas. No entanto, quando observamos um site repleto de animações ou transições complexas que flertam com a terceira dimensão, é quase certo que elas não foram construídas apenas com Bootstrap ou Tailwind. Geralmente, esses efeitos são elaborados por desenvolvedores que dominam CSS e suas manipulações em conjunto com JavaScript na árvore DOM. Portanto, se você realmente deseja criar esse tipo de aplicação, talvez seja melhor estudar bem CSS antes de optar por um framework.

O exemplo acima é o tipo de coisa que Bootstrap ou Tailwind não oferecem direto. Aqui o domínio de CSS faz toda a diferença.

Saber ou não saber

Afirmar se vale ou não a pena aprender CSS para um desenvolvedor front-end é, na verdade, muito simples: sim, vale a pena! Mas talvez não da maneira como estávamos acostumados. Hoje, acredito que o aprendizado de CSS é muito mais orientado pela necessidade do que pelos fundamentos. Ferramentas como o Figma já exportam blocos de código prontos baseados na UI projetada, e o ChatGPT já substitui as buscas intermináveis por snippets de CSS no Stack Overflow ou no CodePen.

Se o seu foco é construir aplicações web rapidamente, aproveite a infinidade de frameworks e bibliotecas de CSS disponíveis e não se preocupe por não conhecer uma propriedade específica, alguém já sofreu antes para resolvê-la por você.

Agora, se o seu objetivo é criar interfaces robustas, com interações refinadas e animações complexas, aí sim eu recomendaria dedicar algumas boas horas ao estudo dos fundamentos e aplicações do CSS nativo.

Documentando componentes React com Storybook

Paulo Cesar Jr — Tue, 24 Jun 2025 17:14:15 +0000

Recentemente, aceitei o desafio de integrar um novo time de desenvolvimento aqui na Globo. Dessa vez, deixei um pouco de lado o contexto de streaming e players de vídeo para mergulhar de vez no oceano das TVs. Agora faço parte do time de TV 3.0 e, se você ainda não está familiarizado com esse assunto, não se preocupe: ele, por si só, já renderia um belo artigo.

Um dos pontos mais legais de entrar em um novo time é poder aprender sobre assuntos que, até então, não eram tão familiares. E o melhor de tudo, talvez, é a grande oportunidade de propor melhorias e contribuir com o conhecimento que você já carrega na bagagem.

Componentes poderosos

O time de TV 3.0 é responsável por criar interatividades para as TVs de sinal aberto. Essas interatividades podem ser pequenos aplicativos de votação, previsão do tempo ou até mesmo um one-click-buy, disponíveis na TV pra serem usados via controle remoto. O interessante é que tudo isso é desenvolvido em React, o que combina muito bem com esse tipo de aplicação orientada ao usuário.

Mas há um problema. Nas primeiras semanas no time, percebi que uma das principais dores era a ausência de documentação dos componentes React já criados o que, muitas vezes, resultava em duplicidade de código desnecessária. Estamos falando de um time com mais de dez pessoas; sem uma documentação eficiente, é praticamente inviável ter uma visão completa do que já foi criado ou melhorado por cada desenvolvedor.

Diante dessa boa oportunidade, imediatamente me veio à mente o Storybook. Pense nele como uma documentação e playground 100% orientados a componentes, onde é possível descrever propriedades, comportamentos e até simular interações entre diferentes componentes. Tudo isso é disponibilizado por meio de uma interface amigável, tanto para desenvolvedores quanto para designers (UX).

Basicamente, qualquer desenvolvedor que saiba criar um componente React consegue escrever uma storie para o Storybook. Trata-se de um arquivo JavaScript (ou TypeScript) que descreve exatamente o que você deseja documentar sobre o seu componente. Além disso, é possível adicionar diversos addons que expandem significativamente o leque de ferramentas disponíveis como controles, documentação automática, testes de acessibilidade e muito mais.

Configurando o Storybook

Para demonstrar um pouco do arsenal do Storybook, vamos implementar uma aplicação React que simula uma loja virtual de venda de carros. Teremos alguns componentes básicos que servirão de base para nossa documentação.

Utilizando o Vite, criaremos nossa aplicação React em TypeScript, que chamaremos de cars-shop-storybook:

npm create vite@latest

Feito isso, podemos criar uma pasta chamada /components, onde ficarão todos os componentes que vamos utilizar e, consequentemente, documentar no Storybook. Basicamente, nossa aplicação será composta por três componentes: Button.tsx, CarCard.tsx e Photo.tsx, conforme o código a seguir:

Button.tsx

import { IoCart } from "react-icons/io5";
import "./button.css";

type ButtonProps = {
  title: string;
  showIcon?: boolean;
};

function Button({ title, showIcon = true }: ButtonProps) {
  return (
    <button className="button">
      {showIcon && <IoCart />} {title}
    </button>
  );
}

export default Button;

Photo.tsx

import { clsx } from "clsx";
import "./photo.css";

type PhotoProps = {
  url: string;
  isBlackAndWhite?: boolean;
};

function Photo({ url, isBlackAndWhite = false }: PhotoProps) {
  const styles = clsx("car-photo", {
    "car-photo--black-and-white": isBlackAndWhite,
  });

  return <img className={styles} src={url} alt="Photo" />;
}

export default Photo;

CarCard.tsx

import Button from "../Button/Button";
import Photo from "../Photo/Photo";
import "./car-card.css";

type CarProps = {
  make: string;
  model: string;
  year: number;
  price: number;
  photo: string;
};

function CarCard({ model, make, year, price, photo }: CarProps) {
  return (
    <div className="car-card">
      <h3>{model}</h3>
      <Photo url={photo} />
      <ul className="car-details">
        <li>{make}</li>
        <li>{year}</li>
        <li>{price}</li>
      </ul>
      <Button title="Comprar" />
    </div>
  );
}

export default CarCard;

Por fim, o componente principal, App.tsx, será responsável por renderizar uma listagem de carros utilizando o componente CarCard.tsx:

App.tsx

import "./App.css";
import type { Car } from "./types/Car";
import { cars } from "./data/cars";
import CarCard from "./components/CarCard/CarCard";

function App() {
  return (
    <>
      {cars.map((car: Car) => (
        <CarCard
          key={car.id}
          make={car.make}
          model={car.model}
          year={car.year}
          price={car.price}
          photo={car.photo}
        />
      ))}
    </>
  );
}

export default App;

Sua aplicação deve exibir algo semelhante a isto aqui:

Uma vez definida nossa aplicação de teste, podemos focar na instalação do Storybook. Como nosso projeto utiliza o Vite, existe uma seção na própria documentação do Storybook com as orientações para o setup: Vite + Storybook.

Vamos criar o Storybook na raiz do projeto principal:

npm create storybook@latest

Após seguir as instruções do CLI, uma pasta /.storybook será criada. Nela ficarão todas as configurações referentes à sua documentação, inclusive com a possibilidade de criar páginas .mdx personalizadas para descrever todos os detalhes do seu projeto.

Para o nosso exemplo, podemos apagar todos os arquivos criados e manter apenas os três principais arquivos de configuração:

/.storybook/
 |___main.ts
 |___preview.ts
 |___vitest.setup.ts

Documentar pode ser divertido

Geralmente, quando pensamos em documentação na programação, a maioria dos desenvolvedores torce o nariz. Com o Storybook, a dinâmica é um pouco diferente. Cada componente da sua aplicação pode conter um arquivo .stories.ts, que funcionará como um mapa para quem for utilizar esse componente. Nele, é importante que sejam descritas todas as variações possíveis e os casos de uso conhecidos desse componente.

Vamos pegar o componente Button.tsx como exemplo. Dentro da sua pasta, vamos criar um arquivo Button.stories.ts que será lido pelo Storybook de acordo com as nossas orientações:

import type { Meta, StoryObj } from "@storybook/react-vite";
import Button from "./Button";

const meta = {
    component: Button
} satisfies Meta<typeof Button>;

type Story = StoryObj<typeof meta>;

export const NoIcon: Story = {
    args: {
        title: "Button Without Icon",
        showIcon: false
    }
}

export const WithIcon: Story = {
    args: {
        title: "Button With Icon",
        showIcon: true
    }
}

export default meta

Analisando o arquivo acima, podemos perceber que o objeto meta é exportado juntamente com NoIcon e WithIcon, que representam duas variações possíveis para esse componente de botão: uma sem ícone e outra com ícone.

Dentro da propriedade args, passamos as props responsáveis pela renderização do nosso componente. Em resumo, é como se criássemos duas instâncias do componente, que ficarão visíveis na documentação.

Agora na raiz do nosso projeto já podemos rodar o comando:

Photo.stories.ts

yarn storybook

E nossa documentação será aberta no browser:

Note que, na área inferior, são listadas todas as propriedades do componente Button.tsx, e elas podem ser alteradas dinamicamente pela própria interface da página.

Podemos fazer o mesmo para os componentes Photo.tsx e CarCard.tsx e criar suas stories.

import type { Meta, StoryObj } from "@storybook/react-vite";
import Photo from "./Photo";

const meta = {
    component: Photo
} satisfies Meta<typeof Photo>;

type Story = StoryObj<typeof meta>;

export const Default: Story = {
    args: {
        url: "https://image1.mobiauto.com.br/images/api/images/v1.0/12433679/transform/fl_progressive,f_webp,q_80",
        isBlackAndWhite: false
    }
}

export const BlackAndWhite: Story = {
    args: {
        url: "https://image1.mobiauto.com.br/images/api/images/v1.0/12433679/transform/fl_progressive,f_webp,q_80",
        isBlackAndWhite: true
    }
}

export default meta

CarCard.stories.ts

import type { Meta, StoryObj } from "@storybook/react-vite";
import CarCard from "./CarCard";

const meta = {
    component: CarCard
} satisfies Meta<typeof CarCard>;

type Story = StoryObj<typeof meta>;

export const Primary: Story = {
    args: {
        make: "Toyota",
        model: "Corolla",
        year: 2020,
        price: 20000,
        photo: "https://image1.mobiauto.com.br/images/api/images/v1.0/12433679/transform/fl_progressive,f_webp,q_80"
    }
}

export default meta

Nosso Storybook vai responder a todas as stories criadas para os componentes React:

Boas práticas

Eu diria que o primeiro grande passo para a criação de um bom Storybook é o alinhamento com o time de UX. Cada story deve representar o componente de forma isolada e contemplar seus principais casos de uso: habilitado, desabilitado, com ícone, sem ícone etc. As variações podem ser infinitas, por isso, ter um escopo bem definido em mente é fundamental.

Por fim, aproveitar o acervo de addons do Storybook é uma escolha certeira. As funcionalidades vão desde a adição de testes unitários para os componentes até tabelas de compatibilidade entre navegadores, no estilo do Can I Use do MDN. Você pode conferir os diversos plugins disponíveis em: Addons

Ah! E não se esqueça de conferir o repositório com o projeto completo deste artigo: cars-shop-storybook.

Micro-frontends na prática

Paulo Cesar Jr — Sun, 16 Mar 2025 18:16:56 +0000

Há alguns anos, trabalhei em uma empresa onde tentamos dividir uma única aplicação front-end em partes menores, independentes e isoladas. Bom... não deu muito certo. Talvez por falta de conhecimento ou pelas limitações tecnológicas da época. O resultado foi uma SPA (Single Page Application) em Angular que carregava diversos iframes, cada um executando outra SPA em Angular. De fato, conseguimos um certo "desacoplamento", mas, em contrapartida, a performance da aplicação principal despencou. O alto consumo de memória e a demora para carregar os iframes tornaram claro que teria sido melhor manter tudo em uma única aplicação.

Mesmo após esse desafio, a experiência não me desanimou. A ideia por trás dos Micro-frontends continuava me fascinando, e eu não conseguia aceitar completamente que a tentativa havia dado errado. Por isso, segui estudando o conceito e buscando maneiras mais eficientes de implementá-lo. Neste artigo, quero apresentar uma abordagem que teria sido muito útil naquela época — e que pode ajudar quem enfrenta desafios semelhantes.

Dividir para conquistar

O conceito de Micro-frontends é simples de entender. Diferente das aplicações monolíticas, onde todo o front-end é carregado e servido por uma única estrutura, os Micro-frontends permitem que pequenos componentes sejam isolados e carregados independentemente por uma ou mais aplicações.

Imagine uma loja virtual com vários elementos na tela, cada um com uma função específica. Se toda a interface for disponibilizada por um único servidor, temos um front-end monolítico. Mas se, por exemplo, o carrinho de compras for muito complexo e exigir regras de negócio específicas, ele pode ser desacoplado e hospedado separadamente, até mesmo em um repositório diferente. Dessa forma, outras lojas virtuais podem reutilizá-lo facilmente, garantindo maior flexibilidade e escalabilidade.

Um dos grandes diferenciais dos Micro-frontends é a flexibilidade tecnológica. Não é necessário restringir-se a um único framework para desenvolver toda a aplicação. É possível criar componentes em diferentes tecnologias e integrá-los a uma aplicação central.

Por exemplo, imagine um sistema de aluguel de imóveis onde o front-end principal é feito em React, mas os componentes responsáveis por exibir as informações dos imóveis são Micro-frontends desenvolvidos em Angular.

Essa interoperabilidade é uma das grandes vantagens do desacoplamento. No fim das contas, tudo é JavaScript!

Federation

Em um belo dia, o Webpack introduziu o Module Federation na versão 5, revolucionando a forma como aplicações compartilham dependências. Esse recurso permite definir módulos que podem ser carregados dinamicamente, mesmo estando em projetos diferentes.

Na prática, ele define uma aplicação container (host), responsável por carregar módulos independentes expostos (remotes) por outras aplicações. Essa abordagem torna os Micro-frontends ainda mais eficientes, aplicando Code Splitting para carregar componentes sob demanda, evitando que façam parte do bundle final desnecessariamente.

Para demonstrar essa mágica na prática, vamos criar duas aplicações React simples que, juntas, formarão uma dashboard de jogadores de um time de futebol. A ideia é que a lista de jogadores seja uma aplicação independente, desenvolvida em React, e que será carregada como um Micro-frontend dentro da aplicação principal, que será responsável por exibi-la.

Vamos utilizar o Vite para criar duas aplicações React:

container: a aplicação principal, que servirá como host do Micro-frontend.
players : a aplicação independente que exibirá a lista de jogadores.

No container, o componente App.jsx terá um HTML básico com um título para a aplicação:

// 📂 container/src/App.jsx

import "./App.css"

function App() {
  return (
    <>
      <h1>⚽ Soccer Dashboard Micro-frontend</h1>
    </>
  )
}

export default App

No nosso projeto players, criaremos um componente Players.jsx que fará uma listagem de jogadores de futebol. Ao clicar em um jogador, acionaremos uma função de callback para enviar seus dados para uso externo:

// 📂 players/src/Players.jsx

import "./Player.css"

const team = [
  {
    name: "Martin Braithwaite",
    photo:
      "https://s3p.sofifa.net/5f55c5509a088da5658cfc69b31be62f7595778e.png",
    position: "ATA"
  },
  {
    name: "Franco Cristaldo",
    photo:
      "https://s3p.sofifa.net/8909750ea3bdec2d403fd56c3bfe5571e7880a52.png",
    position: "MEI"
  },
  {
    name: "Gustavo Cuellar",
    photo:
      "https://s3p.sofifa.net/14b4aaa618de1a853f4298694e7751ec30a43f7b.png",
    position: "VOL"
  },
  {
    name: "Jamerson",
    photo:
      "https://s3p.sofifa.net/f12d7b370613b35527a35a328716313dfbdbde94.png",
    position: "ZAG"
  },
  {
    name: "Tiago Volpi",
    photo:
      "https://s3p.sofifa.net/04736af5928a0443fa2ec4bf8d84e1524cfde82d.png",
    position: "GOL"
  }
]

function Players({ onPlayerSelected }) {
  return (
    <ul className="team">
      {team.map((player, index) => (
        <a
          key={index}
          className="team__player"
          onClick={() => onPlayerSelected(player)}
        >
          <li>
            <div>
              <img
                src={player.photo}
                alt={player.name}
                className="team__player--photo"
              />
            </div>
            <div className="team__player--info">
              <p>
                <strong>Nome:</strong> {player.name}
              </p>
              <p>
                <strong>Posição:</strong> {player.position}
              </p>
            </div>
          </li>
        </a>
      ))}
    </ul>
  )
}

export default Players

Uma vez que nossos componentes foram criados, chegou a hora de carregar o componente Players.jsx como um Micro-frontend dentro do App.jsx do projeto container. Para isso, vamos instalar uma abstração do Module Federation feita especificamente para o Vite: vite-plugin-federation.

Em ambos os projetos, container e players, vamos rodar o seguinte comando:

yarn add @originjs/vite-plugin-federation --dev

No projeto players, em players/vite.config.js, vamos importar a biblioteca federation e definir um nome para nosso Micro-frontend. Além disso, especificaremos na propriedade exposes quais componentes React serão disponibilizados para outras aplicações.

A propriedade filename define um arquivo JavaScript que contém o bundle desses componentes expostos.

// 📂 players/vite.config.js

import { defineConfig } from "vite"
import react from "@vitejs/plugin-react"
import federation from "@originjs/vite-plugin-federation"

// https://vite.dev/config/
export default defineConfig({
  plugins: [
    react(),
    federation({
      name: "players",
      filename: "remoteEntry.js",
      exposes: {
        "./Players": "./src/Players"
      },
      shared: ["react", "react-dom"]
    })
  ],
  build: {
    target: "esnext",
    minify: false,
    cssCodeSplit: false
  },
  preview: {
    host: "localhost",
    port: 5002,
    strictPort: true,
    headers: {
      "Access-Control-Allow-Origin": "*"
    }
  }
})

Ao executar o comando yarn vite preview, podemos acessar esse arquivo no navegador através de http://localhost:5002/assets/remoteEntry.js.

Já no projeto container, em container/vite.config.js, vamos importar a biblioteca federation e definir, na propriedade remotes, o endereço do bundle do componente players. Com isso, ele passará a ser disponibilizado dentro do escopo desse projeto:

// 📂 container/vite.config.js

import { defineConfig } from "vite"
import react from "@vitejs/plugin-react"
import federation from "@originjs/vite-plugin-federation"

// https://vite.dev/config/
export default defineConfig({
  plugins: [
    react(),
    federation({
      name: "container_app",
      remotes: {
        players: "http://localhost:5002/assets/remoteEntry.js"
      },
      shared: {
        react: {
          singleton: true,
          requiredVersion: "^18.0.0"
        },
        "react-dom": {
          singleton: true,
          requiredVersion: "^18.0.0"
        }
      }
    })
  ],
  build: {
    modulePreload: false,
    target: "esnext",
    minify: false,
    cssCodeSplit: false
  }
})

Após configurar corretamente o Federation, podemos importar o componente Players.jsx dentro de App.jsx, como se ele fosse parte integrante do mesmo projeto. Esse processo torna o Micro-frontend funcional, permitindo que o componente seja carregado e utilizado na aplicação principal sem complicações, mantendo a estrutura modular e desacoplada:

import "./App.css"
import Players from "players/Players"

function App() {
  return (
    <>
      <h1>⚽ Soccer Dashboard Micro-frontend</h1>
      <Players />
    </>
  )
}

export default App

Podemos expandir ainda mais a funcionalidade ao acessar o callback onPlayerSelected no projeto container. Dessa forma, quando um jogador for selecionado na aplicação de players, suas informações serão passadas para o projeto container. No App.jsx do container, podemos capturar esses dados e exibi-los, proporcionando uma integração dinâmica entre os Micro-frontends.

Isso mantém a modularidade e desacoplamento, enquanto ainda permite a comunicação entre os componentes de diferentes projetos:

import { useState } from "react"
import "./App.css"
import Players from "players/Players"

function App() {
  const [player, setPlayer] = useState(null)

  const selectPlayer = (player) => {
    setPlayer(player)
  }

  return (
    <>
      <h1>⚽ Soccer Dashboard Micro-frontend</h1>
      <div className="dashboard">
        <div className="dashboard__team">
          <Players onPlayerSelected={selectPlayer} />
        </div>
        <div className="dashboard__player">
          {player && (
            <>
              <h2>{player.name}</h2>
              <img
                className="dashboard__player--photo"
                src={player.photo}
                alt="Foto do Jogador"
              />
              <h3>{player.position}</h3>
            </>
          )}
          {!player && <h2>Selecione um dos jogadores a esquerda</h2>}
        </div>
      </div>
    </>
  )
}

export default App

Após rodar o comando yarn build && yarn vite preview no projeto players, ele estará pronto para expor o componente Players.jsx. Já no projeto container, ao rodar yarn run dev, a aplicação estará disponível em http://localhost:5173/. Lá, você poderá visualizar a aplicação React completa, com o Micro-frontend do componente de jogadores integrado e interativo, exibindo as informações corretamente ao clicar em cada jogador.

Ao explorar a implementação de Micro-frontends, vimos que essa abordagem pode trazer grandes benefícios, como maior modularização, escalabilidade e flexibilidade no uso de diferentes tecnologias. Porém, também existem desafios, como a complexidade adicional na comunicação entre Micro-frontends e a possível sobrecarga de performance. Esses aspectos devem ser considerados ao escolher adotar essa arquitetura. Para conferir o código completo do projeto, acesse meu repositório no GitHub: Soccer Dashboard Micro-frontend.

Como funciona um Player de Vídeo? Uma abordagem em JavaScript

Paulo Cesar Jr — Sat, 22 Feb 2025 17:08:47 +0000

É difícil imaginar, nos dias de hoje, que, após um dia cansativo de trabalho, não aproveitemos algumas horas em frente à TV, seja assistindo a uma boa série ou filme, seja passando raiva com uma partida de futebol do seu time.

Embora atualmente existam várias opções de serviços de streaming, como Netflix, Disney+, Globoplay e Max, nem sempre foi fácil consumir esse tipo de conteúdo pela internet — muito menos de forma rápida.

As pessoas mais jovens talvez não se lembrem da dificuldade de conectar transmissões ao vivo pelo Justin.tv (que mais tarde se tornou a Twitch) em uma internet lenta. Ou dos longos tempos de carregamento para assistir a vídeos curtos no YouTube. Com certeza, hoje nossa experiência melhorou muito!

Desde os primeiros modelos de streaming do final dos anos 90 até hoje, grandes evoluções aconteceram. Um dos componentes principais dessa tecnologia, porém, passou por atualizações significativas e é o foco principal deste artigo: os players de vídeo.

Ascensão e queda do Flash Player

Durante os anos 2000, a reprodução de vídeos na Web dependia quase que exclusivamente do plugin Adobe Flash, assim como animações, jogos e outros conteúdos multimídia.

Devido ao alto consumo de recursos e a alguns problemas de segurança, o Adobe Flash foi descontinuado em 2020. Com o lançamento do HTML5 e a introdução da tag <video>, as páginas Web passaram a integrar áudio e vídeo sem a necessidade de plugins de terceiros.

Curiosamente, antes de trabalhar no Player de vídeo da Globo, eu imaginava que os players de maneira geral se limitavam a componentes front-end com pouca ou quase nenhuma regra de negócio para execução do streaming. Eu estava errado.

Media Source Extensions

De maneira geral, para executarmos um vídeo numa página HTML basicamente precisaremos de um arquivo de vídeo válido e a tag <video> para isso:

<video controls autoplay>
  <source src="filme.mp4" type="video/mp4" />
  <source src="filme.ogg" type="video/ogg" />
  Seu browser não suporta a tag video.
</video>

Mas sinto dizer que isso não é streaming de verdade. Aqui, nossa página HTML está carregando o arquivo de vídeo inteiro de uma vez só, o que traz várias implicações para a aplicação. O primeiro e mais evidente é o consumo elevado de banda e memória. Imagine tentar assistir a um filme de quase 3 horas em qualidade 4K — o carregamento seria demorado e exigiria muitos recursos. O segundo, e não menos importante, é a falta de suporte para a exibição de conteúdo ao vivo. Afinal, qual seria o formato de arquivo de um vídeo ao vivo?

Para responder a essa e muitas outras dúvidas, surge o Media Source Extensions (MSE), um conjunto de recursos em JavaScript que oferece um controle muito maior sobre a reprodução de vídeos em páginas web. Com o MSE, é possível substituir o valor da propriedade src da tag <video> por um objeto MediaSource, responsável por gerenciar os dados e o estado do vídeo.

Dito isso, vamos criar uma aplicação web que utiliza o MSE para reproduzir vídeo, com o objetivo de explorar o potencial dessa API. Para agilizar o setup do projeto, podemos usar o Vite para criar um projeto Vanilla (JavaScript puro).

Com NPM instalado na máquina, vamos criar o projeto definindo seu nome como html5-mse-player e escolhendo o framework Vanilla:

npm create vite@latest html5-mse-player --template vanilla

Em seguida, precisamos acessar a pasta do projeto e instalar todas as suas dependências:

 cd html5-mse-player
 npm install
 npm run dev

Podemos apagar os arquivos criados pelo Vite, com exceção da pasta /node_modules. Além disso, vamos mover o index.html e main.js para a raiz do projeto:

./node_modules/
main.js
index.html
package.json

No index.html, criaremos um HTML básico apenas com uma tag <video> que será gerenciada pelo objeto MSE em main.js:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>HTML5 Player MSE</title>
  </head>
  <body>
    <video controls id="videoElement"></video>
    <script type="module" src="/main.js"></script>
  </body>
</html>

Por fim, no arquivo main.js vamos instanciar um objeto MediaSource e atribuí-lo a uma URL na propriedade src:

const videoElement = document.getElementById('videoElement')
const mediaSource = new MediaSource()
videoElement.src = URL.createObjectURL(mediaSource)

Ao rodar o comando npm run dev e acessar a aplicação no navegador, podemos perceber que o player de vídeo é exibido corretamente, mas apresenta um carregador em execução sem mostrar o conteúdo. Isso acontece porque o objeto MediaSource está aguardando a inserção do Source Buffer.

Source Buffer

Quando pensamos em streaming, o verdadeiro segredo por trás do seu funcionamento está na segmentação do conteúdo. Em termos simples, um vídeo transmitido por streaming é dividido em pequenos pedaços chamados chunks ou segmentos. Esses fragmentos permitem que o conteúdo seja carregado e reproduzido de forma contínua, sem a necessidade de baixar o arquivo completo. Isso torna a transmissão mais eficiente, adaptável à conexão do usuário e essencial para uma experiência de reprodução fluida.

Compreendido o processo de segmentação, podemos retomar nosso exemplo prático. O vídeo não é inserido diretamente no objeto MediaSource. Em vez disso, os Source Buffers são utilizados: eles armazenam os segmentos do vídeo e os adicionam ao objeto associado à propriedade src da tag <video>.

Voltando ao código, precisamos definir uma lista de segmentos (chunks) de vídeo que será adicionada ao Source Buffer no objeto MSE. Além disso, é essencial especificar o formato e o codec do vídeo para garantir que o navegador possa decodificar o conteúdo corretamente:

const mimeCodec = 'video/mp4; codecs="avc1.4D401F"'
const videoChunks = [
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_0.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_1.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_2.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_3.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_4.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_5.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_6.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_7.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_8.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_9.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_10.m4v"
]

Agora é possível adicionar o evento sourceopen ao objeto mediaSource. Esse evento é acionado quando o MediaSource está pronto para receber dados. A partir desse momento, podemos começar a inserir cada pedaço de vídeo no Source Buffer. Assim que os segmentos são adicionados, o player deve iniciar o download e a reprodução do conteúdo:

mediaSource.addEventListener("sourceopen", () => {})

Media Segments

É importante entendermos que, mesmo sendo uma aplicação front-end, o player precisa buscar esses segmentos de vídeo em um servidor. O conteúdo completo é previamente segmentado em pequenos pedaços de alguns segundos e armazenado em um servidor. O Player, então, consome esses chunks conforme necessário, realizando o download sob demanda.

As URLs dos chunks são, então, organizadas de forma sequencial no servidor, permitindo que o Player faça a leitura dos segmentos na ordem correta. Isso garante que os trechos sejam reproduzidos cronologicamente, preservando a fluidez e a integridade do conteúdo original.

./video/
  |___chunk_0.mp4
  |___chunk_1.mp4
  |___chunk_2.mp4
  |___chunk_3.mp4

Ao final, nosso código agora deve adicionar os chunks ao SourceBuffer e posteriormente fazer download desses segmentos:

mediaSource.addEventListener("sourceopen", onSourceOpen)

function onSourceOpen() {
  const mediaSource = this
  const sourceBuffer = mediaSource.addSourceBuffer(mimeCodec)

  let currentSegmentIndex = 0

  sourceBuffer.addEventListener("updateend", () => {
    if (!sourceBuffer.updating && currentSegmentIndex < videoChunks.length) {
      fetchVideoSegment(videoChunks[currentSegmentIndex], sourceBuffer)
      currentSegmentIndex++
    } else if (currentSegmentIndex >= videoChunks.length) {
      mediaSource.endOfStream()
    }
  })

  sourceBuffer.addEventListener("error", (e) => {
    console.error("SourceBuffer error:", e)
  })

  fetchVideoSegment(videoChunks[currentSegmentIndex], sourceBuffer)
  currentSegmentIndex++
}

function fetchVideoSegment(url, sourceBuffer) {
  fetch(url)
    .then((response) => response.arrayBuffer())
    .then((data) => {
      if (!sourceBuffer.updating) {
        sourceBuffer.appendBuffer(data)
      }
    })
    .catch((error) => console.error("Error fetching video segment:", error))
}

Nosso main.js deve estar dessa forma:

const mimeCodec = 'video/mp4; codecs="avc1.4D401F"'
const videoChunks = [
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_0.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_1.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_2.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_3.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_4.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_5.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_6.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_7.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_8.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_9.m4v",
  "https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_10.m4v"
]

const videoElement = document.getElementById("videoElement")
const mediaSource = new MediaSource()
videoElement.src = URL.createObjectURL(mediaSource)

mediaSource.addEventListener("sourceopen", onSourceOpen)

function onSourceOpen() {
  const mediaSource = this
  const sourceBuffer = mediaSource.addSourceBuffer(mimeCodec)

  let currentSegmentIndex = 0

  sourceBuffer.addEventListener("updateend", () => {
    if (!sourceBuffer.updating && currentSegmentIndex < videoChunks.length) {
      fetchVideoSegment(videoChunks[currentSegmentIndex], sourceBuffer)
      currentSegmentIndex++
    } else if (currentSegmentIndex >= videoChunks.length) {
      mediaSource.endOfStream()
    }
  })

  sourceBuffer.addEventListener("error", (e) => {
    console.error("SourceBuffer error:", e)
  })

  fetchVideoSegment(videoChunks[currentSegmentIndex], sourceBuffer)
  currentSegmentIndex++
}

function fetchVideoSegment(url, sourceBuffer) {
  fetch(url)
    .then((response) => response.arrayBuffer())
    .then((data) => {
      if (!sourceBuffer.updating) {
        sourceBuffer.appendBuffer(data)
      }
    })
    .catch((error) => console.error("Error fetching video segment:", error))
}

Isso aí! Agora, com o projeto rodando, temos um Player funcional que transmite vídeo em tempo real por meio de streaming segmentado.

O universo dos streamings e players de vídeo vai muito além do que exploramos aqui. Ainda há muito a descobrir, como os diferentes protocolos de streaming e cenários avançados de implementação. Mas isso fica para um próximo post!

Quer ver o código completo deste projeto? Confira no repositório: https://github.com/paulocesarjr/html5-mse-player 🚀

Criando aplicações em tempo real com SSE (Server-Sent Events)

Paulo Cesar Jr — Mon, 27 Jan 2025 23:40:23 +0000

Há cerca de uma década, se precisássemos desenvolver uma aplicação em tempo real, como um chat ou um feed de atualizações, a primeira solução que viria à mente seria o uso de polling. Essa técnica consiste em enviar requisições HTTP de forma temporizada e recorrente ao servidor, buscando dados atualizados. No entanto, mesmo quando não há novas informações disponíveis, essas requisições continuam sendo disparadas, resultando em desperdício de recursos, como largura de banda e processamento do servidor.

Felizmente, os tempos mudaram. Hoje, ao trabalharmos com JavaScript, contamos com a biblioteca EventSource, que permite estabelecer uma conexão SSE (Server-Sent Events). Neste artigo, explorarei os conceitos por trás desse recurso e apresentarei um breve tutorial para aplicar esses conceitos na prática.

Uma conexão sempre aberta

Diferentemente das requisições HTTP convencionais, onde o cliente dispara uma requisição e o servidor devolve uma resposta, as conexões SSE permanecem sempre abertas. Isso possibilita uma comunicação unidirecional entre servidor e cliente. Ao contrário dos WebSockets, que permitem comunicação bidirecional, no SSE apenas o servidor envia dados ao cliente, que os recebe de forma instantânea enquanto está conectado.

Uma vez estabelecida a conexão, os dados chegam ao cliente JavaScript na forma de eventos, eliminando a necessidade de disparar novas requisições ao servidor para buscar atualizações, como acontece no polling. Cabe ao servidor a responsabilidade de enviar eventos com os dados atualizados sempre que necessário.

A menos que a conexão seja encerrada, o cliente fica constantemente aguardando novos eventos de dados do servidor, tornando essa técnica ideal para a construção de notificações, dashboards ou chats que necessitam de atualizações constantes.

Sistema de controle de conexões

Para demonstrar na prática os conceitos abordados, vamos criar uma aplicação em Node.js (back-end) responsável por disponibilizar um endpoint de conexão SSE, que será utilizado por um cliente JavaScript (front-end).

Nossa aplicação consiste em um sistema onde o usuário deve informar um UserID e estabelecer uma conexão SSE. A partir disso, o servidor começa a disparar, a cada 5 segundos, um evento que retorna a lista de usuários conectados. Caso o usuário encerre sua conexão, ele é removido automaticamente da lista de usuários conectados.

Vamos começar!

npm init -y

npm i express

Ao criar o arquivo index.js, vamos centralizar a lógica do nosso back-end. Além disso vamos criar um pasta /public onde ficarão o index.html e arquivo script.js para gerenciar nossa página. A estrutura deve ficar assim:

/public
  index.html
  script.js
index.js
package.json

Em index.js, vamos importar a biblioteca express, que é responsável por permitir a criação de endpoints HTTP:

import express from "express"

const app = express()
app.use(express.json())

const PORT = 3000
app.listen(PORT, () => console.log(`Server is running on ${PORT} port`))

Além disso, é necessário configurar para que o conteúdo da pasta /public seja retornado quando o usuário acessar http://localhost:3000/:

import express from "express"
import fs from "fs"
import path from "path"

const app = express()
app.use(express.json())
app.use(express.static(path.join(path.resolve(path.dirname("")), "public")))

app.get("/", (_, res) => {
  res.writeHead(200, { "content-language": "text/html" })
  const streamIndexHtml = fs.createReadStream("index.html")
  streamIndexHtml.pipe(res)
})

const PORT = 3000
app.listen(PORT, () => console.log(`Server is running on ${PORT} port`))

Dentro de /public em index.html vamos montar um HTML básico para retornar um título e testar o funcionando do servidor:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Server Sent Events Demo</title>
  </head>
  <body>
    <h1>Server Sent Events Demo (SSE)</h1>
  </body>
</html>

Agora, ao rodar o comando npm start no terminal, a página já deve ser exibida no navegador:

Voltando as atenções para o back-end, podemos criar arquivo connection.js, responsável por gerenciar as conexões do usuários ao servidor:

/public
  index.html
  script.js
index.js
connection.js
package.json

Dentro dele, vamos exportar uma classe Connection, onde será armazenado um mapa de usuários conectados, além dos métodos registerUser, para registrar novos usuários, e removeUser, para removê-los do mapa:

export default class Connection {
  _users = new Map()

  registerUser() {}

  removeUser() {}
}

Também podemos criar um getter connectedUsers para facilitar o acesso aos usuários conectados fora da classe:

export default class Connection {
  _users = new Map()

  get connectedUsers() {
    return [...this._users.keys()]
  }

  registerUser() {}

  removeUser() {}
}

No método registerUser, vamos receber o userId do usuário conectado e gerar um connectionId, que servirá como identificador único para essa conexão estabelecida:

registerUser(userId, response) {
  if (!this._users.has(userId)) {
    this._users.set(userId, [])
  }

  const connectionId = this.generateConnectionId()
  this._users.get(userId).push({ connectionId, response })
  return connectionId
}

No método generateConnectionId, podemos utilizar a biblioteca crypto para gerar e retornar um token aleatório:

generateConnectionId() {
  return crypto.randomBytes(20).toString("hex")
}

Já o método removeUser receberá o userId e o connectionId do usuário que fechou a conexão, e, com isso, removerá o usuário do mapa:

removeUser(userId, connectionId) {
  if (!this._users.has(userId)) {
    return
  }

  const connections = this._users
    .get(userId)
    .filter((connection) => connection.connectionId !== connectionId)

  if (connections.length) {
    this._users.set(userId, connections)
  } else {
    this._users.delete(userId)
  }
}

Como a classe Connection isola a lógica de gerenciamento das conexões, precisamos configurar um endpoint em nosso servidor (index.js) para que os clientes possam iniciar uma comunicação SSE. Essas conexões, por sua vez, serão gerenciadas pela classe Connection:

const connection = new Connection()

app.get("/events", (req, res) => {
  res
    .writeHead(200, {
      "Cache-Control": "no-cache",
      "Content-Type": "text/event-stream",
      Connection: "keep-alive"
    })
    .write("\n")

  const EVENTS_INTERVAL = 5000
  const userId = req.query.user
  const connectionId = connection.registerUser(userId, res)

  setInterval(() => {
    res.write(`data: ${JSON.stringify(connection.connectedUsers)}\n\n`)
  }, EVENTS_INTERVAL)

  req.on("close", () => connection.removeUser(userId, connectionId))
})

Aqui podemos destacar três pontos importantes:

O endpoint /events deve responder ao cliente com o cabeçalho Content-Type: text/event-stream. Isso permite que os clientes reconheçam a comunicação SSE e criem um objeto EventSource para estabelecer a conexão.
A cada cinco segundos, o servidor enviará uma resposta em forma de evento para os clientes conectados, informando quais usuários estabeleceram conexão.
Conexões encerradas podem ser monitoradas utilizando o evento req.on("close", () => {}), permitindo que usuários desconectados sejam removidos do mapa de conexões.

Nosso back-end está pronto! Agora podemos voltar nossa atenção para o front-end.

Como o servidor já disponibiliza um endpoint para conexões SSE, cabe ao cliente requisitar esse endereço e aguardar o recebimento dos eventos enviados.

No arquivo index.html, vamos criar:

Um campo de texto para o usuário informar seu UserID;
Dois botões: um para iniciar e outro para encerrar a conexão SSE;
Uma tag <ul> para exibir a lista de usuários conectados, que será atualizada com os eventos enviados pelo servidor.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Server Sent Events Demo</title>
  </head>
  <body>
    <h1>Server Sent Events Demo (SSE)</h1>

    <input type="text" id="userIdTxt" placeholder="User ID" />
    <input type="button" id="connectBtn" value="Connect" />
    <input type="button" id="closeBtn" value="Close" disabled />
    <ul id="users"></ul>
    <script type="text/javascript" src="script.js"></script>
  </body>
</html>

Por fim, no arquivo script.js para isolar a lógica de manipulação dos componentes e a criação do objeto EventSource.

let eventSource = null
const userIdInput = document.querySelector("#userIdTxt")
const connectButton = document.querySelector("#connectBtn")
const closeButton = document.querySelector("#closeBtn")
const ulUsers = document.querySelector("#users")

connectButton.addEventListener("click", startConnection)
closeButton.addEventListener("click", closeConnection)

function startConnection() {
  const userId = userIdInput.value.trim()
  if (!userId) {
    alert("Please enter a User ID")
    return
  }

  eventSource = new EventSource(`/events?user=${userId}`)
  connectButton.setAttribute("disabled", "")
  closeButton.removeAttribute("disabled")
  userIdInput.setAttribute("disabled", "")

  eventSource.onmessage = (event) => {
    const connectedUsers = JSON.parse(event.data)
    updateUsersList(connectedUsers)
  }
}

function updateUsersList(users) {
  ulUsers.innerHTML = ""

  users.forEach((user) => {
    const liUser = document.createElement("li")
    liUser.textContent = user
    ulUsers.appendChild(liUser)
  })
}

function closeConnection() {
  eventSource.close()

  ulUsers.innerHTML = ""
  connectButton.removeAttribute("disabled")
  userIdInput.removeAttribute("disabled")
  closeButton.setAttribute("disabled", "")
}

Aqui, destacamos a criação do objeto eventSource:
eventSource = new EventSource(`/events?user=${userId}`).

No construtor, ele espera como argumento um servidor que responda com o conteúdo text/event-stream. Por sorte, já configuramos exatamente isso! 😜

A função eventSource.onmessage(event => {}) permite receber em tempo real todos os eventos enviados pelo servidor de forma unidirecional.

Para evitar que a conexão permaneça aberta indefinidamente, podemos utilizar eventSource.close(), que fecha o canal de comunicação com o servidor. Alternativamente, a conexão também será encerrada ao fechar o navegador.

A magia do tempo real

Ao abrir duas abas da nossa aplicação no navegador, podemos validar o funcionamento da conexão em tempo real, observando as atualizações de usuários conectados em ação.

Note que, enquanto a conexão SSE permanecer aberta, os eventos continuarão sendo recebidos a cada 5 segundos, atualizando automaticamente a lista de usuários conectados ao servidor.

Na aba Network do navegador, é possível acompanhar os eventos enviados pelo servidor sendo recebidos pelo cliente em tempo real.

Com isso, concluímos a implementação de um sistema simples utilizando SSE para conexões em tempo real. Essa técnica é ideal para casos em que o servidor precisa enviar dados contínuos e unidirecionais para o cliente, como feeds, chats ou dashboards. Se você quiser conferir o código completo deste projeto, acesse meu repositório no GitHub: Server Sent Events.

O que eu entendo sobre Clean Code?

Paulo Cesar Jr — Sun, 19 Jan 2025 17:48:52 +0000

Quando comecei a me aprofundar no estudo das boas práticas de desenvolvimento de software, imaginava que Código Limpo (Clean Code) fosse apenas um conjunto de regras a serem seguidas para garantir um código legível. Em parte, é isso mesmo. No entanto, essas regras nem sempre se aplicam a todos os tipos de código e, com certeza, não são totalmente compreendidas apenas pela leitura de um livro.

Código Limpo

Há alguns meses, terminei de reler o clássico Clean Code, de Robert C. Martin, e tive uma percepção muito diferente da primeira vez que o li, há seis anos. Quando ainda estava começando na faculdade, muitos dos problemas apresentados nos capítulos não eram claros para mim, assim como as soluções propostas. Esse, talvez, seja o grande equívoco de quem busca aprender sobre Código Limpo: não é algo destinado a iniciantes.

[…] e se você fosse médico e um paciente exigisse que você parasse com toda aquela lavação de mão na preparação para a cirurgia só porque isso leva muito tempo? […] não é profissional que programadores cedam a vontade dos grandes gerentes que não entendem os riscos de se gerar códigos confusos.

Considerando essa complexidade para iniciantes em programação, neste artigo procurei destacar os pontos que considerei mais relevantes durante a leitura, além de compartilhar algumas experiências adquiridas no dia a dia de trabalho.

Funções

Uma função bem escrita deve ter uma única responsabilidade: ela deve fazer uma coisa, fazê-la bem e apenas isso. Quando tentamos agrupar várias responsabilidades em uma única função, o código se torna difícil de ler, testar e manter.

Considere o seguinte exemplo, em que uma função faz múltiplas tarefas para salvar e notificar usuários:

function salvarUsuarioENotificar(usuario) {
    // Valida os dados do usuário
    if (!usuario.nome || !usuario.email) {
        throw new Error('Dados do usuário incompletos.')
    }

    // Salva no banco de dados
    bancoDeDados.salvar(usuario)

    // Envia um e-mail de boas-vindas
    emailService.enviarEmail(usuario.email, 'Bem-vindo!', 'Obrigado por se cadastrar!')
}

Essa função viola o princípio de responsabilidade única porque combina lógica de validação, persistência de dados e envio de e-mails.

Após uma refatoração, cada responsabilidade é delegada a uma função específica:

function validarUsuario(usuario) {
    if (!usuario.nome || !usuario.email) {
        throw new Error('Dados do usuário incompletos.')
    }
}

function salvarUsuario(usuario) {
    bancoDeDados.salvar(usuario)
}

function enviarEmailDeBoasVindas(usuario) {
    emailService.enviarEmail(usuario.email, 'Bem-vindo!', 'Obrigado por se cadastrar!')
}

function processarCadastroDeUsuario(usuario) {
    validarUsuario(usuario)
    salvarUsuario(usuario)
    enviarEmailDeBoasVindas(usuario)
}

Agora, cada função tem uma única responsabilidade, tornando o código mais legível e fácil de modificar ou estender no futuro.

Comentários

Embora os comentários sejam úteis em muitos casos, devemos priorizar o uso de nomes autoexplicativos para evitar explicações redundantes ou desnecessárias. Comentários que apenas descrevem algo óbvio não acrescentam valor e podem até poluir o código.

Veja este exemplo:

/** Dia do mês **/
private number diaDoMes;

Este comentário é completamente desnecessário, já que o nome do atributo deixa claro o que ele representa. Podemos melhorar isso ao usar um nome ainda mais claro, caso necessário, e remover o comentário:

private number diaDoMesAtual;

Agora, o atributo é suficientemente descritivo e dispensa comentários.

Considere uma função em que o comentário descreve sua finalidade de forma redundante:

// Calcula a média de uma lista de números
function calcular(lista) {
    let soma = 0
    for (const numero of lista) {
        soma += numero
    }
    return soma / lista.length
}

Neste caso, o nome da função não é claro o suficiente, então a descrição foi "compensada" com um comentário. Podemos refatorar usando um nome mais específico:

function calcularMedia(listaDeNumeros) {
    let soma = 0
    for (const numero of listaDeNumeros) {
        soma += numero
    }
    return soma / listaDeNumeros.length
}

Agora, o nome da função transmite exatamente o que ela faz, eliminando a necessidade de um comentário.

Objetos e Estruturas de Dados

Um bom design orientado a objetos foca em expor as operações que podem ser realizadas e esconder os detalhes de implementação. Isso promove encapsulamento, reduz o acoplamento e facilita a manutenção do código.

Considere o exemplo abaixo:

class Circulo implements Forma {
    private Ponto centro;
    private number raio;
    private number PI = 3.14159;

    public number calcularArea() {
        return PI * raio * raio;
    }
}

Observe que não precisamos saber o valor de PI nem como o cálculo da área é feito. O importante é que a classe Circulo fornece uma função pública, calcularArea(), que encapsula os detalhes de implementação. Quem utiliza a classe só precisa chamar essa função, sem se preocupar com os detalhes internos.

Evite reutilizar variáveis em escopos diferentes para propósitos distintos, pois isso pode causar confusão e dificultar a leitura do código. Considere o exemplo abaixo, que viola essa prática:

let resultado = 0;

// Calcula a área
resultado = PI * raio * raio;

// Usa a mesma variável para o perímetro
resultado = 2 * PI * raio;

Neste caso, o uso da mesma variável resultado para armazenar valores diferentes (área e perímetro) pode ser confuso. Uma solução melhor seria usar variáveis distintas:

const area = PI * raio * raio;
const perimetro = 2 * PI * raio;

Agora, o código é mais claro, autoexplicativo e menos propenso a erros.

Tratamento de Erros

No passado, as técnicas para tratar e informar erros eram bastante limitadas. As opções geralmente se resumiam a criar uma flag de erro ou utilizar códigos de erro que precisavam ser constantemente verificados pelo chamador. Isso tornava o código mais verboso e menos legível.

Considere o exemplo abaixo, que utiliza várias validações para lidar com erros fundamentais da execução:

function desligarDispositivo() {
    const handle = obterHandle(DEV1);

    if (handle !== HandleDispositivo.INVALIDO) {
        const registro = recuperarRegistroDispositivo(handle);

        if (registro.getStatus() !== DISPOSITIVO_SUSPENSO) {
            pausarDispositivo(handle);
            limparFilaDeTrabalhoDispositivo(handle);
            fecharDispositivo(handle);
        } else {
            logger.log('Dispositivo suspenso. Não foi possível desligar.');
        }
    } else {
        logger.log('Handle inválido para: ' + DEV1.toString());
    }
}

Embora funcional, esse código é verboso e repetitivo. Ele mistura lógica de validação, execução e tratamento de erros em um único lugar, dificultando a leitura e a manutenção.

Em vez de checar manualmente várias condições, uma abordagem mais limpa é lançar exceções para erros. Isso permite centralizar o tratamento de falhas e focar apenas no fluxo principal dentro da função. Veja a refatoração:

function desligarDispositivo() {
    try {
        tentarDesligarDispositivo();
    } catch (erro) {
        logger.log(erro.message);
    }
}

function tentarDesligarDispositivo() {
    const handle = obterHandle(DEV1);

    if (handle === HandleDispositivo.INVALIDO) {
        throw new Error('Handle inválido para o dispositivo: ' + DEV1.toString());
    }

    const registro = recuperarRegistroDispositivo(handle);

    if (registro.getStatus() === DISPOSITIVO_SUSPENSO) {
        throw new Error('Dispositivo suspenso. Não é possível desligar.');
    }

    pausarDispositivo(handle);
    limparFilaDeTrabalhoDispositivo(handle);
    fecharDispositivo(handle);
}

Agora, o código principal (desligarDispositivo) é mais conciso e foca no fluxo principal, enquanto os detalhes de validação e lançamento de erros foram movidos para tentarDesligarDispositivo.

Testes de unidade

Testes limpos devem ser claros, simples e consistentes. Eles precisam transmitir muita informação com o menor número de expressões possíveis, deixando evidente o que está sendo testado e qual o resultado esperado.

Estrutura geral de um teste
1️⃣ Construir: Configure os dados ou o ambiente necessário para o teste.
2️⃣ Operar: Realize a operação ou ação a ser testada.
3️⃣ Verificar: Certifique-se de que o resultado está de acordo com o esperado.

Considere o exemplo abaixo:

it('deve retornar os dados em XML', () => {
    const pagina = criarPaginaComConteudo('PaginaDeTeste', 'conteudo de teste'); // 1️⃣ Constrói

    pagina.enviarRequisicao('PaginaDeTeste', 'tipo:xml'); // 2️⃣ Opera

    expect(pagina.contem('conteudo de teste')).toBe(true); // 3️⃣ Verifica
});

Ao escrever testes de unidade, lembre-se: clareza e foco são mais importantes do que cobrir muitos casos em um único teste. Isso torna a manutenção mais simples e eficiente, ajudando a detectar problemas com mais precisão.

Classes

O nome da classe deve refletir claramente sua responsabilidade. Classes devem ser pequenas, com um único propósito e nome não ambíguo.

SRP - Princípio da Responsabilidade Única

Cada classe deve ter apenas uma responsabilidade e um motivo para mudar. Isso facilita a manutenção e a reutilização do código.

Exemplo simples:

class Sql {
    Sql(tabela, colunas)
    create()
    insert(campos)
    selectAll()
    findByKey(coluna, valor)
    // ...
}

Quando uma classe acumula várias responsabilidades, ela viola o SRP, como no caso da classe Sql que teria múltiplos métodos (create, insert, select). Modificar qualquer parte pode afetar outras funcionalidades, aumentando o risco de falhas.

Refatoração para SRP:

class Sql {
    constructor(tabela, colunas) { }
    gerar() { }
}

class CreateSql extends Sql {
    gerar() { }
}

class SelectSql extends Sql {
    gerar() { }
}

class InsertSql extends Sql {
    gerar() { }
}

Agora, cada classe tem uma responsabilidade clara, seguindo o Princípio de Aberto-Fechado (OCP), que diz que classes devem ser abertas para extensão, mas fechadas para modificação.

O que eu entendo sobre Código Limpo?

Código Limpo não é algo que se aprende de uma vez só ou ao ler apenas um livro. É uma jornada contínua que exige prática, reflexão e evolução. Eu, pessoalmente, continuo aprendendo até hoje, aplicando e refinando essas boas práticas a cada novo projeto. O que aprendi ao longo do tempo é que a verdadeira habilidade em escrever código limpo vem com a experiência e a capacidade de perceber o que pode ser melhorado.

Além disso, como nos ensina Kent Beck, um projeto de software "simples" deve seguir algumas regras fundamentais para garantir a qualidade e a clareza do código:

Efetuar todos os testes
Evitar duplicação de código
Expressar claramente o propósito do programador
Minimizar o número de classes e métodos

Essas regras são apresentadas em ordem de relevância, e são um guia valioso para quem busca escrever código que seja não apenas funcional, mas também limpo, eficiente e de fácil manutenção. Aplique essas práticas no seu dia a dia e veja como seu código vai se tornar mais claro e robusto com o tempo!

Usando Strategy Pattern para evitar condicionamento exagerado

Paulo Cesar Jr — Sat, 11 Jan 2025 17:34:41 +0000

Há algumas semanas, trabalhei em soluções para o Player da Globo, onde era necessário ativar e desativar comportamentos específicos no software durante a execução. Esse tipo de necessidade é comumente resolvido com condicionais encadeadas, como if-else e switch, mas essa abordagem nem sempre é a ideal.

Neste artigo, apresento uma solução que atendeu perfeitamente a esse desafio e que pode ser aplicada a diversos cenários na programação.

Qual estratégia devo usar?

Imagine que você acabou de chegar a um destino desconhecido. Ao sair do aeroporto, você tem algumas opções para se locomover até o hotel. A alternativa mais econômica é alugar uma bicicleta, mas isso levaria mais tempo. Pegar um ônibus seria um pouco mais caro, mas te levaria com mais agilidade e segurança. Por fim, alugar um carro seria a opção mais rápida, mas também a mais cara.

O ponto mais importante nessa situação é entender que, independentemente da estratégia escolhida, o objetivo final é o mesmo: chegar ao hotel.

Essa analogia pode ser aplicada ao desenvolvimento de software. Quando lidamos com cenários onde diferentes processos buscam alcançar o mesmo objetivo, podemos utilizar o padrão de projeto Strategy (Strategy Design Pattern) para nos ajudar.

Quando se programa sem estratégia...

Imagine que precisamos desenvolver um sistema bancário capaz de calcular taxas com base no tipo de conta do cliente, como corrente, poupança ou premium. Esses cálculos precisam ser realizados em tempo de execução, o que exige uma implementação que direcione corretamente o fluxo do código para o cálculo apropriado.

A princípio, uma abordagem comum seria usar uma estrutura simples de condicionais encadeadas para resolver o problema de forma rápida e funcional:

class Banco {
  calcularTaxa(tipoConta, valor) {
    if (tipoConta === "corrente") {
      return valor * 0.02; // 2% de taxa
    } else if (tipoConta === "poupanca") {
      return valor * 0.01; // 1% de taxa
    } else if (tipoConta === "premium") {
      return valor * 0.005; // 0,5% de taxa
    } else {
      throw new Error("Tipo de conta não suportado.");
    }
  }
}

const banco = new Banco();
const taxa = banco.calcularTaxa("corrente", 1000); // Exemplo: R$1000
console.log(`A taxa para sua conta é: R$${taxa}`);

Embora essa solução funcione bem para cenários simples, o que acontece se o banco precisar adicionar mais cinco tipos de conta no futuro?

calcularTaxa(tipoConta, valor) {
  if (tipoConta === "corrente") {
    return valor * 0.02; // 2% de taxa
  } else if (tipoConta === "poupanca") {
    return valor * 0.01; // 1% de taxa
  } else if (tipoConta === "premium") {
    return valor * 0.005; // 0,5% de taxa
  } else if (tipoConta === "estudante") {
    return valor * 0.001; // 0,1% de taxa
  } else if (tipoConta === "empresarial") {
    return valor * 0.03; // 3% de taxa
  } else if (tipoConta === "internacional") {
    return valor * 0.04 + 10; // 4% + taxa fixa de R$10
  } else if (tipoConta === "digital") {
    return valor * 0.008; // 0,8% de taxa
  } else if (tipoConta === "exclusiva") {
    return valor * 0.002; // 0,2% de taxa
  } else {
    throw new Error("Tipo de conta inválido!");
  }
}

Agora, o código começa a mostrar sérias limitações. Vamos explorar os problemas dessa abordagem:

1. Baixa escalabilidade

Toda vez que um novo tipo de conta precisa ser adicionado, o método calcularTaxa precisa ser modificado. Isso aumenta continuamente o número de condicionais, tornando o código mais complexo e difícil de gerenciar.

2. Alta dependência

A lógica de cálculo das taxas está completamente acoplada ao método calcularTaxa. Alterações em um tipo de conta podem impactar outros inadvertidamente, elevando o risco de introduzir bugs.

3. Repetição de código

Trechos similares, como valor * taxa, são duplicados para cada tipo de conta. Isso reduz a reutilização de código e viola o princípio DRY (Don't Repeat Yourself).

No próximo passo, veremos como o Strategy Pattern pode resolver esses problemas, promovendo um código mais limpo, escalável e modular.

Uma estratégia de cada vez!

Para evitar os problemas mencionados anteriormente, vamos tratar cada tipo de conta como uma entidade isolada no software. Isso ocorre porque cada tipo de conta possui um cálculo específico de taxa e pode ter outros futuros comportamentos associados.

Em vez de criar uma classe Banco com um método calcularTaxa que resolva todas as operações, vamos criar uma classe para cada tipo de conta:

class ContaCorrente {
  calcularTaxa(valor) {
    return valor * 0.02; // 2% de taxa
  }
}

class ContaPoupanca {
  calcularTaxa(valor) {
    return valor * 0.01; // 1% de taxa
  }
}

class ContaPremium {
  calcularTaxa(valor) {
    return valor * 0.005; // 0,5% de taxa
  }
}

Isso garante que cada operação de cálculo seja mantida dentro de um escopo específico para o seu tipo de conta. Agora, temos comportamentos isolados e focados em cada tipo de conta:

Arquitetura da solução baseada em estratégias.

Mas, onde ficará a seleção da conta desejada?

class Banco {
  constructor(conta) {
    this.conta = conta;
  }

  setConta(conta) {
    this.conta = conta;
  }

  calcularTaxa(valor) {
    if (!this.conta) {
      throw new Error("Nenhuma conta definida.");
    }
    return this.conta.calcularTaxa(valor);
  }
}

Observe que, em vez de criarmos estruturas de decisão encadeadas (if-else), optamos por passar uma conta, estratégia no construtor da nossa classe Banco. Isso permite que, ao instanciar o banco, o método setConta selecione o tipo de conta desejado em tempo de execução. O cálculo da taxa será executado por meio de this.conta.calcularTaxa(valor).

const banco = new Banco(new ContaCorrente());
console.log(`Taxa para conta corrente: R$${banco.calcularTaxa(1000)}`); // R$20

banco.setConta(new ContaPoupanca());
console.log(`Taxa para conta poupança: R$${banco.calcularTaxa(1000)}`); // R$10

banco.setConta(new ContaPremium());
console.log(`Taxa para conta premium: R$${banco.calcularTaxa(1000)}`); // R$5

Com esse modelo, conseguimos aplicar o Strategy Pattern de forma simples, garantindo uma implementação mais flexível, escalável e com baixo acoplamento.

Posso usar estratégia em tudo?

O Strategy Pattern é uma solução poderosa quando se precisa variar o comportamento de uma operação em tempo de execução, sem acoplar diretamente o código de execução a diferentes condições ou tipos. Esse padrão é ideal para cenários onde o comportamento de uma operação pode variar conforme o contexto e onde as alternativas são independentes entre si.

Quando usar o Strategy Pattern

Comportamentos variantes: Quando o comportamento de um sistema precisa ser alterado dinamicamente, dependendo de condições específicas (como diferentes tipos de conta no exemplo bancário).
Evitar condicionais complexas: Quando a lógica de decisão é baseada em muitas estruturas de controle de fluxo, como múltiplos if-else ou switch, o que torna o código difícil de manter.
Facilidade de manutenção e expansão: Quando você deseja adicionar novos comportamentos sem modificar o código existente, simplesmente criando novas classes de estratégia.
Desacoplamento de comportamentos: Quando você quer isolar comportamentos específicos em diferentes classes, tornando o código mais modular e flexível.

Ao utilizar o Strategy, garantimos que o código se torne mais limpo, modular e flexível, além de promover uma melhor manutenção e expansão do sistema.

Testes end-to-end e sua real utilidade

Paulo Cesar Jr — Wed, 10 Apr 2024 13:16:11 +0000

Implementar testes durante o desenvolvimento de um software é sempre um assunto delicado. Apesar de serem apreciados por muitos e odiados por outros, a prática de testar é uma garantia de funcionamento e qualidade. Além disso, testes contribuem potencialmente para eventuais refatorações no código.

Neste artigo, busco questionar a necessidade de implementações de testes end-to-end (ponta a ponta) em sistemas reais e discutir os melhores casos para sua aplicabilidade.

A verdade sobre o end-to-end

Recentemente, junto ao meu time de Player Web na Globo, discutimos a necessidade de incluirmos testes end-to-end ao nosso fluxo de desenvolvimento. Após algumas pesquisas e a criação de uma POC feita em Cypress, ficamos bem impressionados com as facilidades da ferramenta.

Evoluindo as discussões, chegamos à pergunta mais relevante: O que devemos testar? De fato, qualquer player de vídeo possui uma infinidade de cenários que podem ser testados. Comportamentos simples como iniciar um vídeo, pausar, avançar, retroceder podem ser bons casos para iniciar a criação de testes. Mas até que ponto essas funcionalidade só são garantidas através de testes ponta a ponta?

Eis que surge a verdade sobre o teste end-to-end: Eles nem sempre são necessários!

Pirâmide dos testes.

Analisando a clássica Pirâmide dos Testes, podemos perceber que os testes end-to-end representam o custo mais alto de implementação e têm uma velocidade mais lenta de resposta. Considerando um cenário empresarial, onde tempo e dinheiro são recursos valiosos, é evidente que esse tipo de teste deve ser evitado. No entanto, esse ainda não é o único motivo pelo qual chegamos à conclusão de que o end-to-end nem sempre é necessário.

Voltando a base da pirâmide, encontramos os testes unitários. Esses, por sua vez, exigem menos esforço e retornam uma validação mais rápida. Foi aí que surgiu o ponto relevante dessa discussão. Nosso player de vídeo possui uma cobertura considerável de testes unitários, muitos dos quais testam comportamentos que seriam plenamente aplicáveis em testes end-to-end.

Dado esse cenário, a decisão do nosso time foi priorizar a construção de testes de unidade em vez dos end-to-end. Mas será que os testes unitários testam tudo que precisamos?

O dilema dos tipos de teste

Um bom exemplo para mostrar esse contraste entre os dois tipos de teste é levarmos ao cenário do Player de vídeo. Considere que devemos escrever um teste para garantir o funcionamento de assistir ao vídeo ao no Player: Quando o usuário clicar no botão de play, o vídeo deve ser iniciado.

Criando um teste end-to-end para esse caso utilizando Cypress, teríamos algo nesse sentido:

Agora, usando alguma biblioteca de teste unitário como Jest ou Jasmine, por exemplo, essa seria a implementação do teste:

it('video should start when play button is clicked', () => {
  const player = new Player('test.mp4')
  player.playButton.click()
  expect(player.isPlaying).toBe(true)
})

Note que os dois exemplos testam o mesmo comportamento. Obviamente, cada tipo de teste dentro dos seus limites. Enquanto o teste end-to-end valida o comportamento na aplicação final, simulando a interação do usuário, o teste de unidade valida o comportamento isolado do componente de play.

Se ambos os tipos de teste cumprem o objetivo esperado, podemos optar pela estratégia que consome menos recursos da stack de desenvolvimento, o que nesse caso é o teste de unidade.

Então os testes end-to-end são descartáveis para todos os sistemas? A resposta é não!

Vamos considerar um segundo cenário para teste: Garantir que pelo menos uma publicidade seja exibida antes do vídeo começar.

Seguindo a lógica do menor recurso, é possível criar testes de unidade que simulem a exibição de anúncios no Player de vídeo por meio de mocks. No entanto, essa decisão traz consigo um dilema: Como garantir que a publicidade seja realmente exibida se ela parte de uma simulação?.

Esse é um exemplo do limite que os testes unitários não ultrapassam e a oportunidade definitiva para a implementação de um teste end-to-end, que por sua vez, testa a aplicação real, sem simulações.

A partir dessa reflexão, destaco alguns pontos importantes sobre a utilização desses tipos de teste:

Se um comportamento pode ser validado através de um teste unitário, deve-se dar preferência a esse tipo de teste em vez do teste end-to-end;
Testes end-to-end são ótimos para evitar o uso de mocks e dados simulados;
Para cenários onde é difícil simular ou que exigem a interação do usuário diretamente, testes end-to-end são a melhor opção;
Em determinados cenários, um teste end-to-end pode garantir a mesma cobertura que um conjunto de testes de unidade e integração.

Cypress pode me ajudar?

Entre as várias ferramentas de testes automatizados do mercado, algumas consolidadas como o Selenium, o Cypress se destaca por atuar diretamente no navegador, permitindo interação direta com a DOM.

Para os sistemas que utilizam a stack JavaScript, a combinação pode ser perfeita, uma vez que o framework não exige instalações complexas e muito menos automações externas para sua execução. Um dos pontos altos dessa ferramenta é a capacidade de realizar testes em tempo real, proporcionando uma abordagem mais prática para identificação de falhas. Além disso, ela conta com uma funcionalidade específica de "time travel" de depuração.

Como mencionado anteriormente, o cenário de entrega de publicidade dentro do Player da Globo foi uma boa oportunidade para experimentar esse framework. Considerando a complexidade para a construção de um possível teste de integração e a necessidade de validar a entrega por completo, o Cypress atendeu às expectativas.

Por outro lado, cenários mais simples, como a validação de comportamento de componentes isolados, não justificam sua utilização, uma vez que podem ser facilmente testados com testes de unidade.

Descomplicando a Busca Binária

Paulo Cesar Jr — Wed, 20 Mar 2024 14:02:20 +0000

Recentemente, tenho dedicado uma parte significativa dos meus estudos à compreensão de estruturas de dados e algoritmos. Apesar de ter passado a maior parte da minha carreira como desenvolvedor front-end, focado principalmente em design e interface do usuário, sempre nutri uma curiosidade intrínseca pela manipulação eficiente de dados.

Neste artigo, busco explicar os conceitos básicos de uma busca binária, suas aplicações e, por fim, apresentar um modelo prático em JavaScript.

O custo de uma busca

Quando começamos a lidar com conjuntos de dados em programação, especialmente através de listas, é comum não nos preocuparmos muito com o desempenho. Afinal, os principais objetivos ao optarmos pelo uso de uma lista são organização, consulta e remoção dos dados.

Tomemos como exemplo a lista abaixo, onde temos uma estrutura armazenando o nome de 5 frutas. Nesse contexto, é relativamente simples aplicar um laço de repetição para encontrar o índice de uma fruta pelo nome. Do ponto de vista computacional, o custo para encontrar qualquer fruta nessa lista seria mínimo.

const frutas = ['Uva', 'Abacaxi', 'Melão', 'Morango', 'Laranja'];

function buscarIndiceDaFrutaPeloNome(frutas = [], nome) {
  for (let i = 0; i < frutas.length; i++) {
    console.log(`Operação: ${i + 1}`);

    if (nome === frutas[i]) {
      return i;
    }
  }
}

const indiceUva = buscarIndiceDaFrutaPeloNome(frutas, 'Uva');

Entretanto, é importante questionar se o custo operacional para retornar o índice da fruta Uva é o mesmo para Laranja. A resposta é não. Embora neste exemplo os índices sejam apresentados quase que instantaneamente para cada item da lista, o custo operacional tende a aumentar à medida que o item desejado está mais próximo do fim da lista. Portanto, encontrar o índice de Laranja é mais demorado para o computador do que encontrar o índice de Uva.

Isso se torna evidente quando contamos as operações executadas pela função buscarIndiceDaFrutaPeloNome na tentativa de encontrar o índice correspondente à fruta desejada.

Encontrar o índice da Uva:

Operação	Execução
1	👉 Verifica se `Uva` é igual a `Uva`

Encontrar o índice da Laranja:

Operação	Execução
1	Verifica se `Uva` é igual a `Laranja`
2	Verifica se `Abacaxi` é igual a `Laranja`
3	Verifica se `Melão` é igual a `Laranja`
4	Verifica se `Morango` é igual a `Laranja`
5	👉 Verifica se `Laranja` é igual a `Laranja`

Podemos observar que encontrar o índice da Uva requer apenas uma operação, já que este é o primeiro elemento da lista. Portanto, podemos dizer que o custo dessa operação é $O (1)$ na notação Big O.

Por outro lado, encontrar o índice da Laranja requer 5 operações, já que este é o último elemento da lista. Assim, podemos representar o custo dessa operação como $O (n)$ , onde $n$ é o número de elementos na lista.

Em buscas lineares, quanto mais distante o elemento procurado maior o custo computacional.

Claro, em um contexto com apenas algumas operações, como o exemplo das frutas, o custo computacional de cinco operações é praticamente negligenciável para um computador. No entanto, ao considerarmos um sistema com uma lista significativamente maior, como, por exemplo, 1.500 frutas, a história muda.

Se imaginarmos que cada operação leva 0.5 segundos para ser concluída, encontrar o índice da última fruta na lista levaria aproximadamente 750 segundos. Isso se traduz em cerca de 12 minutos e meio de tempo de resposta do sistema. Portanto, embora o custo de cada operação seja pequeno, quando multiplicado pelo número total de operações necessárias, o tempo total de processamento pode se tornar substancial.

Diante desse cenário, surge a pergunta crucial: como podemos otimizar essa busca?

Ordenação é o segredo

Geralmente, ao procurarmos um documento em uma pasta ou um contato em uma agenda, observamos que esses itens estão ordenados para facilitar sua localização. Na programação, não é diferente.

Imagine uma lista com 7 números:

const numeros = [10, 23, 53, 87, 24, 2, 61]

Baseando-nos no exemplo anterior das frutas, uma busca linear (verificando item a item) para encontrar o índice do número 2 custaria um total de 6 operações computacionais. E se ordenarmos essa lista?

const numeros = [2, 10, 23, 24, 53, 61, 87]

Após a ordenação, precisaríamos de apenas 1 operação para o sistema encontrar o índice do número 2. Mas será que essa redução no custo operacional se aplica a todos os itens?

Vamos analisar o cenário do número 61. Na busca linear, precisaríamos de 6 operações para encontrar seu índice, mesmo com a lista ordenada. No entanto, ao invés de começarmos a busca pelo começo, por que não começar pelo meio?

Para determinar o meio da lista, devemos considerar onde ela começa e onde termina. Com essas informações, podemos fazer um simples cálculo somando o início e o fim e dividindo por 2 para encontrar a metade exata. Assim, temos:

const baixo = 0
const alto = numeros.length - 1
const meio = Math.floor((baixo + alto) / 2)

Onde na lista de números o meio será o índice 3, correspondente ao valor 24.

Dessa maneira, se considerarmos o índice 3 como ponto de partida para a lista, podemos iniciar nossa busca a partir desse elemento, uma vez que os valores estão ordenados:

Operação	Execução
1	Verifica se 24 é igual a 61
2	Reduz a lista pela metade, agora o meio é 61
3	Verifica se 61 é igual a 61

Começando a busca pelo meio da lista, reduzimos o número de operações de 6 para 3 até encontrarmos o número 61. Esse é o primeiro exemplo prático de como uma busca binária funciona.

Com a pesquisa binária, você seleciona o número intermediário de uma lista e elimina a metade dos números restantes a cada operação.

A metade dos elementos também significa metade das operações.

Isso faz com que você não precise ler todos os elementos da lista para encontrar o elemento desejado, uma vez que, a cada operação, a lista é reduzida pela metade. Analisando os valores lidos da lista a cada operação binária, temos o seguinte comportamento:

Operação	Execução
1	`[2, 10, 23, 24, 53, 61, 87]` (verifica o meio 24)
2	`[53, 61, 87]` (divide a lista)
3	👉 `[53, 61, 87]` (verifica o meio 61)

Novamente, se considerarmos apenas uma lista com 7 elementos, talvez a diferença entre realizar 6 ou 3 operações em uma busca não pareça tão significativa para o sistema. No entanto, se ampliarmos o escopo para uma lista ordenada com 100 números, a busca linear exigiria 100 operações para encontrar o último elemento. Por outro lado, a busca binária levaria apenas 7 operações!

Enquanto a busca linear opera na notação $O (n)$ , a busca binária demonstra alto desempenho, reduzindo pela metade o número de leituras a cada operação. Isso se traduz em:

O(log⁡n)O(\log n)

Um belo algoritmo para buscar

Dado que em cada operação dividimos a lista e verificamos se o elemento no meio é o valor desejado, podemos simplesmente aplicar essa lógica em um loop de repetição para obter nosso algoritmo:

function pesquisaBinaria(lista, item) {
  let baixo = 0;
  let alto = lista.length - 1;
  let meio, chute;

  while (baixo <= alto) {
    meio = Math.floor((baixo + alto) / 2);
    chute = lista[meio];

    if (chute === item) {
      return meio; // Retorna o índice se o item for encontrado
    }

    if (chute > item) {
      alto = meio - 1; // Descarta a metade superior da lista
    } else {
      baixo = meio + 1; // Descarta a metade inferior da lista
    }
  }

  return -1; // Retorna -1 se o item não for encontrado na lista
}

Dessa forma, ao fornecermos uma lista ordenada para a função pesquisaBinaria e especificarmos o valor desejado, receberemos o índice correspondente como retorno:

const indice = pesquisaBinaria([1,3,5,7,9], 5)
console.log(indice) // 2

Por fim, vale ressaltar alguns pontos importantes sobre a implementação da busca binária:

A busca binária requer que a lista esteja previamente ordenada.
Em cada operação, a busca binária encontra a metade da lista e verifica se este é o elemento desejado.
Ao contrário da busca linear, a busca binária opera em tempo logarítmico.
Quanto mais longa a lista, mais evidente se torna a vantagem da busca binária em relação à busca linear.

Teste A/B em larga escala: Como testar uma aplicação com 1 milhão de usuários?

Paulo Cesar Jr — Sat, 25 Nov 2023 00:09:30 +0000

Antes de entrar na Globo como Engenheiro de Software, eu sempre imaginava que o Teste A/B era coisa de Designer. Talvez pelo fato de ter iniciado minha carreira como Web Designer e ter lido em algum lugar que essa técnica era muito difundida entre os estudiosos de UI & UX. Bem... Eu estava errado. Não em dizer que um designer não possa realizar um Teste A/B, mas deixar de vincular essa técnica ao mundo dos softwares me parece um desperdício.

O que é um Teste A/B?

Imagine o seguinte cenário: Uma loja virtual de roupas deseja criar um tutorial (passo a passo guiado) para auxiliar seus usuários no processo de compras. O time de desenvolvimento, empolgado com a nova feature, partiu logo para a codificação. O mais otimista dos devs exclamou: "Isso vai aumentar muito o número de vendas!". Entretanto, o mais pessimista retrucou com um questionamento: "Prove-me!"

Sentindo-se desafiado, o mais otimista decidiu fazer uma comparação após o tutorial ter sido implementado:

Sem tutorial	Com tutorial
1.300 vendas no mês	1.930 vendas no mês

E para o bem de seu ego, ele estava certo. As vendas aumentaram em 48% após a adição do tutorial na página. O mais interessante é que o dev otimista tinha a ciência ao seu lado. O que ele implementou foi um Teste A/B.

Um teste A/B é uma maneira de comparar duas versões de um produto e medir qual entrega a MELHOR HIPÓTESE.

Existem 3 componentes chave que compõe um Teste A/B:

Hipótese
Grupo de controle
Significância

A Hipótese trata-se de uma ideia a ser validada. Pode estar relacionada a uma nova funcionalidade, atualização de dependência ou até correção de um problema. O que é imprescindível é que ela não seja única. Um Teste A/B deve ter pelo menos duas hipóteses a serem comparadas, com o objetivo de que pelo menos uma alcance a significância.

Mas o que é ser significante? Pode-se dizer que é aquilo que trouxe informação, positiva ou negativamente. Nem todo Teste A/B traz ações imediatas; muitas vezes, a Significância acaba mostrando que você não deve implementar algo no seu produto.

E quem participa do A/B? O Grupo de controle. Todos os usuários que testarem alguma das hipóteses fazem parte do grupo de controle, que, em linhas gerais, são os participantes do Teste A/B.

Como criar um Teste A/B?

Não existe um consenso sobre quais são as etapas para construir um Teste A/B, muito menos sobre qual ferramenta utilizar. No entanto, procurei separar as 5 etapas que considero indispensáveis em todo experimento:

Criar as hipóteses
Disponibilizar essas hipóteses a um grupo pequeno de usuários
Definir as métricas que serão mensuradas
Ajustar o grupo de controle Comparar a significância

Criar as hipóteses está diretamente relacionado à origem do produto a ser testado. Muitas vezes, comparamos uma funcionalidade já em produção (H0) com uma mudança (H1), com o objetivo de descobrir qual é a mais eficiente, como uma página de venda sem tutorial e com tutorial, por exemplo.

Uma vez criadas, você deve entregar essa hipótese modificada a um grupo pequeno de usuários, como 5% ou 10% dos usuários. Imagine se essa alteração causar um efeito colateral ou bug no seu sistema? Afinal, os testes servem para isso.

É fundamental que você defina quais são as métricas responsáveis por comparar a significância entre as hipóteses. E mais importante é que você tenha fácil acesso a essas métricas. Na história da loja de roupas, temos o número de vendas como norte de comparação.

Hora ou outra, você precisará ajustar a entrega do seu experimento ao grupo de controle. Não quero dar spoilers, mas um 6º componente chave surgirá em breve.

Por fim, quando seu experimento tiver dados relevantes, é hora de comparar a significância e avaliar as hipóteses.

A influência do tempo

"Para agora o que você está fazendo e pegue uma moeda. Jogue-a 3 vezes para cima e diga qual face caiu mais vezes. Coroa 3 vezes? Cara 2 vezes?

Se você fizesse um Teste A/B nessa moeda, concluiria que todas as vezes que ela cai sempre será Coroa? Ou Cara? E se você jogar a moeda 10.000 vezes? Ficará surpreso em saber que a quantidade será quase equivalente.

Esse é um dos erros comuns do Teste A/B: ignorar o tempo. O tempo é o responsável por influenciar suas hipóteses, de maneira que as torne convergentes ou divergentes.

Durante o tempo em que seu A/B estiver disponível, novas hipóteses poderão surgir e, inclusive, métricas que antes estavam escondidas podem tornar-se relevantes.

E quanto tempo meu A/B deve ficar no ar? Até você atingir uma significância confiável.

Como testar uma aplicação com 1 milhão de usuários?

Trabalho no time de Player de Vídeos da Globo. Meu time é responsável por desenvolver o Player que atende a produtos que vão desde sites de notícias até uma plataforma gigante de streaming, como Globoplay, G1 e Globo Esporte, todos utilizando um Player feito em JavaScript baseado no Clappr, um projeto open-source que permite criar players de vídeo de forma extensível numa arquitetura baseada em plugins. Fique à vontade para colaborar!

Atualmente, o Player da Globo possui cerca de 10 bilhões de plays ao ano e uma média de 4 bilhões de horas assistidas, tudo isso em um pequeno e poderoso Player em JavaScript.

Surge então o questionamento: como testar uma aplicação de 1 milhão de usuários? Simples, passando aos usuários a responsabilidade de testar! A mágica do Teste A/B está nisso, testar cenários reais com usuários reais. No Player, criamos Testes A/B para diversos cenários, como mudanças de interface, atualizações de dependência e até configurações de reprodução de vídeo. O Teste A/B nos garante tomar decisões baseadas em dados e não apenas no instinto.

Para implementar os testes, utilizamos uma solução interna desenvolvida pelo time de Backstage da Globo. Ela é responsável por versionar o Player e garantir que os usuários recebam hipóteses compatíveis do experimento. Existem algumas ferramentas famosas no mercado para implementar A/B, como o Split Hero e o próprio Firebase.

Recentemente, o Player aumentou a entrega de propagandas (advertising) em mais de 1.47% graças à exibição de Ads após o replay dos vídeos. Tal implementação só foi possível de ser confirmada graças à comprovação estatística proporcionada por um experimento A/B, onde comparamos uma versão do Player sem Ads após o replay e uma com ads. O aumento foi de 0.98% de impressões nos Ads. Falando de uma aplicação que tem bilhões de plays, trouxe retorno monetário relevante.

Por que fazer um Teste A/B?

Se mesmo chegando até aqui você não foi convencido a implementar um Teste A/B, vou reforçar trazendo uma frase que acredito resumir bem a essência dessa técnica:

Um Teste A/B remove a subjetividade das decisões em virtude das EVIDÊNCIAS ESTATÍSTICAS. Priorize os dados e menos o instinto.

Além de tomar decisões baseadas em dados, você reduz o risco da mudança e conhece de verdade o impacto do seu trabalho, utilizando usuários para testar seu sistema.