DEV Community: Ricardo Mello

O código não se tornou commodity após a AI. Ele sempre foi

Ricardo Mello — Tue, 24 Feb 2026 01:00:17 +0000

Recentemente eu li algumas notícias apocalípticas sobre a profissão de desenvolvimento após o advento da AI, como esse post do Chris Messina dizendo que código se tornou uma commodity, ou o CEO da Microsoft AI dizendo nesse artigo da Fortune que dá 18 meses pra automatizar todas as profissões de colarinho branco, incluindo a nossa.

Não adianta, basta surgir uma tecnologia disruptiva que os profetas do apocalipse e a galera do hype surgem em pé de guerra. Na prática, toda ferramenta que reduz fricção na criação de software gera um certo pânico no mercado, mas depois vira uma infraestrutura invisível.

O mercado de tecnologia é feito de ciclos, e quem tá nessa há mais tempo sabe bem do que eu estou falando. Delphi, Visual Basic, Dreamweaver, WordPress, low-code, no-code... Todos eles prometeram a mesma coisa: permitir que um único desenvolvedor faça o trabalho de um time inteiro.

E aqui estamos, 20 anos depois, ouvindo a mesma história de novo.

A commodity código

Um dos exemplos mais conhecidos sobre comoditização é o sal, que era considerado um artigo precioso, causou guerras e ergueu impérios, mas hoje é baratinho no mercado e qualquer um pode comprar.

O sal se tornou barato, mas cozinhar não se tornou uma commodity. A skill de saber o que fazer com os ingredientes é o que realmente importa.

O código sempre foi algo básico. Qualquer aluno de primeiro período de faculdade ou de curso técnico consegue criar instruções básicas, rodar um algoritmo e criar um software pequeno. Eu programava desde os treze anos de idade, enquanto meu irmão mais novo o faz desde os oito.

Engenheiros, por exemplo, já usam o tal "disposable software" há muito tempo, criando algoritmos pra resolver cálculos quando o matlab não consegue. Pessoas criavam sistemas inteiros na década de 90 usando MS Access, Delphi, VB e similares.

O que mudou de lá pra cá foi que software se tornou algo muito complexo, e na maioria das vezes um complexo totalmente desnecessário.

O que a IA realmente reduziu foi o custo da produção de código sintático, como boilerplates. O custo de decisão arquitetural continua o mesmo, senão maior.

Os vendedores de complexidade

Eu nunca escrevi aplicações em Ruby, mas tive que ver esse keynote do DHH na RubyConf onde ele mencionou um termo que eu achei sensacional: "merchants of complexity".

Desenvolver código se tornou algo muito complicado e a culpa também é nossa. Muitas empresas acham que precisam separar frontend e backend porque todo mundo tá fazendo e elas não querem ficar pra trás. Isso faz algumas empresas precisarem de um arquiteto, 2 devs backend, 1 dev frontend, DevOps, dois ciclos de QA, PM, entre outros, pra subir uma tela de login básica em 3 meses pra um volume ridículo de usuários.

Se os LLMs vão mudar isso? Com certeza vão, mas não é o fim do mundo.

As mesmas empresas que criaram essa complexidade desnecessária agora estão vendendo a solução. Enquanto o Suleyman disse que vai automatizar tudo em um ano e meio, o mesmo artigo da Fortune traz um estudo da METR que diz que a AI está causando o efeito contrário e deixando os devs 20% mais lentos. Na prática são executivos vendendo um produto. A Borland fez isso com o Delphi, enquanto a Microsoft fez a mesma coisa com o VB.

O que não é commodity

Se código sempre foi commodity, o que não é commodity de fato?

Saber o que fazer, por que fazer, e como fazer isso sobreviver em produção no longo prazo.

A AI pode criar o melhor código pra uma situação, quando na verdade a decisão deveria ter sido remover aquele código, ou em outro cenário ela pode criar uma implementação redundante que vai causar gargalos de desempenho em produção.

Mesmo um dev senior usando AI precisa de julgamento técnico pra tomar as decisões certas. Ela não conhece todas as suas regras de negócio, seus SLAs, ou por que aquele "refactoring bobo" vai quebrar três outros serviços. Nunca foi sobre code vs no-code, mas ser um dev ou um mero digitador.

Um novo ciclo

Devs generalistas vão ascender e ter novamente a possibilidade de criar software em escala para problemas reais, enquanto devs backend que não fazem a mínima ideia de como funciona a aplicação pra qual eles criam APIs, ou devs frontend que não sabem o básico de como o backend funciona vão perder espaço. Um dev fullstack usando Claude Code ou Cursor consegue prototipar em dias (ou horas) o que antes precisava de um squad inteiro durante semanas.

Eu enxergo essas mudanças como o início de um novo ciclo, onde saber fazer código não é o suficiente. Mas pra mim e pra vários desenvolvedores do mercado, nunca foi. A nossa profissão sempre foi mais intelectual do que braçal e isso meus amigos, não é commodity.

Eu uso LLMs diariamente e realmente enxergo a AI como uma ferramenta poderosa para potencializar o desenvolvimento de aplicações por parte de desenvolvedores que levam ao mercado a sério. Porém, eu enxergo esta mesma AI como uma bomba nas mãos de quem não entende os conceitos básicos de desenvolvimento de software. Simplesmente porque quando a gente atinge o limite de até onde ela consegue ir, é o primeiro grupo que vai saber o que fazer, enquanto o segundo vai precisar abrir um ticket de suporte no lovable.

Então basicamente o que está acontecendo não é uma desvalorização acentuada do código ou da profissão de desenvolvedor, mas um novo ciclo que está começando seguindo os mesmos princípios que já vivemos antes. Essa ferramenta é mais poderosa do que todas as outras, mas todas as outras também foram as mais poderosas de suas épocas.

Se você sobreviveu ao Delphi, ao jQuery, ao Angular 1 vs 2 (ou ao React), ao hype do blockchain, você vai sobreviver a esse também.

AI Agents, Comandos de Voz e uma nova forma de criar software

Ricardo Mello — Thu, 19 Jun 2025 03:33:09 +0000

A forma que a gente trabalha há muito tempo não me parece a ideal. Eu posso até não ter achado a forma ideal ainda, mas eu continuo nessa procura. Eu realmente acho que depois de a tecnologia evoluir tanto, a gente não precisa mais trabalhar como datilógrafos do século passado.

Se você parar pra observar o quanto o nosso modelo de trabalho evoluiu nos últimos anos comparado às tecnologias que a gente desenvolve, você vai notar um gap muito grande. A gente desenvolveu aplicações distribuídas, blockchain, inteligência artificial, visão computacional, e muitas outras coisas absurdamente incríveis, ao mesmo tempo que nós continuamos fazendo isso sentados (alguns de pé) escrevendo em uma tela branca – pode me zoar, eu não uso dark mode.

Os softwares de reconhecimento de voz eram horríveis sim, mas o Ditado do Mac não é mais aquela coisa primitiva que rodava em um Symbian. E se você não conhece o Symbian, me avisa pra eu parar de usar exemplos velhos.

Eu imagino que essas ferramentas só vão melhorar ao longo do tempo, e sinceramente eu não quero ficar parado no tempo fazendo coisas como eu fazia lá em 2010. Te convido a fazer o mesmo.

Tenho testado algumas formas diferentes de trabalhar nesses últimos anos. Isso inclui inteligência artificial, comandos de voz, e até o amado/odiado vibe coding. Quero compartilhar dois pontos que estão mudando a minha forma de trabalhar, e talvez mude a sua também.

1. AI Agents

A menos que você esteja vivendo em uma caverna, você já deve ter ouvido falar de AI Agents. Resumindo de uma forma bem rasa, um AI agent é um ChatGPT turbinado que executa tarefas de forma autônoma direto na sua IDE. Ele cria features, altera arquivos e roda comandos com um único prompt, o que te permite realizar mudanças significativas em segundos.

AI Agents são o presente, e eu recomendo fortemente que façam parte do seu workflow. Dependendo da linguagem você pode querer usar uma IDE com o AI Agent e outra que você se sentir mais confortável pra programar, mas vale muito a pena. O ganho de produtividade é absurdo, e do momento que você cria o seu próprio framework com o Cursor Rules ou similar, o Agent começa a gerar um código bem parecido com o que você escreveria.

Pensando em time, você também consegue adicionar essas regras ao repositório, e outras pessoas do time usando AI Agents terão resultados parecidos. Você também pode pedir uma revisão de código pro seu Agent baseado nas regras antes de submeter pra revisão do time.

A lista de prós é extensa, e vale o teste. Minha lista de AI Agents favoritos tem: Cursor, GitHub Copilot e WindSurf. O Claude Code é muito bom, mas ele roda no terminal e não na IDE.

P.S.: Se alguém usa a AI da JetBrains, defende ela aqui porque eu não curti muito.

2. Ditado e comandos de voz

Algo relativamente antigo, genérico e que funciona em várias aplicações diferentes é o Ditado. A proposta é bem simples: você consegue escrever falando. Isso serve pra mandar mensagens, pedir pra inteligência artificial criar alguma coisa, ou pedir pra Siri tocar uma música. Isso vai te fazer pensar duas vezes antes de mandar aquele áudio que poderia ser uma mensagem.

Eu não sou um heavy user da Siri, tenho conhecimento muito básico de assistentes, e mantenho o "Hey Siri" desativado porque eu ainda sou meio bolado com um celular ou computador me ouvindo o tempo todo, mas tenho mudado minha cabeça quanto isso porque eu acho algo inevitável.

"Ah mas o ChatGPT tem modo voz". Concordo totalmente, mas o modo de voz do ChatGPT não vai abrir o seu WhatsApp e mandar uma mensagem (ainda), ou escrever algo dentro da sua IDE. Se você aliar o ditado do mac ou do Windows a uma IDE com AI Agent, você vai simplesmente abrir uma classe de entity, e dizer em voz alta "create a repository for this entity". Voilà. O AI Agent vai começar criar.

Eu não sei dizer a qualidade dos prompts em português, mas no teste que eu fiz funcionou perfeitamente. Até porque os modelos usados são o Claude, GPT, Gemini, e outros grandes que a gente já usa no dia a dia.

Aqui vão os links sobre como habilitar o modo de ditado: macOS e Windows.

Conclusão

Falar com uma AI, ver ela programando e só revisar o resultado me faz sentir o Homem de Ferro falando com o Jarvis. Eu acho algo incrível e que só tem a melhorar no futuro.

A maioria dessas ferramentas possuem um período de testes gratuito, então vale muito a pena fazer um teste. Te garanto que você vai curtir um bocado. Dica: O Claude é meu modelo favorito mesmo no GitHub Copilot, mas embora eu tenha usado o Copilot desde os betas, hoje eu tô no time do Cursor.

Ainda me vejo escrevendo prompts muito mais pelo costume do que pela facilidade. Mudar a forma de trabalhar depois de mais de uma década é complicado. E se você tem LER, que são aquelas lesões por esforço repetitivo, isso vai te ajudar um bocado a digitar menos e aliviar elas também – mas não esqueça da fisioterapia.

Web Components com Preact

Ricardo Mello — Fri, 26 Apr 2024 01:14:44 +0000

O Preact se intitula como "Fast 3kB alternative to React with the same modern API". E na minha opinião, ele tá se subestimando. Não é minha intenção entrar em uma comparação de React vs Preact, mas a performance dele a possibilidade de criar web components são duas grandes vantagens. É esse segundo ponto que vamos abordar hoje.

Eu escolhi o Preact ao invés de outras libs como Lit ou Stencil porque além de ele ser muito leve e possuir uma ótima performance, os componentes são iguais aos do React, o que significa uma curva de aprendizado muito pequena caso o seu time já conheça React. Você consegue criar uma lib agnóstica sem abrir mão do TSX/JSX, hooks, e tudo aquilo que faz o React ser o que ele é, o que na minha opinião faz o Preact ser o melhor dos dois mundos no desenvolvimento de bibliotecas.

Por último, mas não menos importante, o Preact já oferece suporte nativo aos Signals, que te permite criar um gerenciamento de estado atômico e, mais uma vez, muito performático.

O projeto

O nosso objetivo vai ser bem simples, que é transformar um componente de counter em um web component. Sabe aquele counter que aparece quando você gera uma aplicação com o vite? Ele mesmo. Vamos usar uma técnica simples pra transformar esse cara em um web component que pode ser utilizado em qualquer lugar, inclusive em um HTML comum.

Mão na massa

Pra esse exemplo eu criei um projeto Preact no Stackblitz e vou alterá-lo para exportar e renderizar os web components. Se preferir, você também pode criar um projeto local usando o getting started.

Eu deletei o app.tsx e o app.css. Também removi o render() do main.tsx. Como nós vamos exportar o web component pra ser usado diretamente no HTML, não faz sentido renderizar o preact como aplicação.

Pra começar, crie um componente counter.tsx com o seguinte conteúdo:

import { FunctionalComponent } from 'preact';
import { useCallback, useState } from 'preact/hooks';

export const Counter: FunctionalComponent = () => {
  const [count, setCount] = useState(0);

  const increment = useCallback(() => {
    setCount(count + 1);
  }, [count]);

  return <button onClick={increment}>count is {count}</button>;
};

O pulo do gato

Qualquer componente preact pode ser registrado como web component usando o mini wrapper preact-custom-element. Esse cara transforma o componente em Web Component seguindo a V1 da especificação Custom Elements.

Pra instalar o wrapper, rode o seguinte comando:

npm install preact-custom-element

E se você está usando typescript, instale os types também:

npm i @types/preact-custom-element --save-dev

Agora, é só usar o wrapper no componente e o código do seu counter deve ficar assim:

import { FunctionalComponent } from 'preact';
import { useCallback, useState } from 'preact/hooks';
import register from 'preact-custom-element';

export const Counter: FunctionalComponent = () => {...};

register(Counter, 'ric-counter');

Por último, exporte o componente no main.tsx. Como removemos a maior parte desse arquivo, ele deve ficar assim:

import './index.css';

export * from './counter';

A partir daí você já consegue utilizar o seu web component no index.html:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/vite.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Vite + Preact + TS + Web Components</title>
  </head>
  <body>
    <ric-counter></ric-counter>
    <script type="module" src="/src/main.tsx"></script>
  </body>
</html>

Com isso, o web component será renderizado normalmente:

Você deve ter notado que eu declarei a tag <ric-counter></ric-counter> antes do import do main.tsx. Isso é pra mostrar que ele consegue detectar tags que já foram declaradas antes de ele ser inicializado, o que significa que você não precisa se preocupar em carregar o js antes das tags.

Atributos

Os atributos são essenciais pra permitir que a aplicação possa controlar o comportamento dos componentes, ao mesmo tempo que nós como desenvolvedores de componentes definimos o que pode ser controlado.

Os web components recebem os atributos como string por padrão, então é importante ter em mente que os seus dados podem precisar ser convertidos antes da utilização. Eu considero uma boa prática fazer isso já nas primeiras linhas do componente, e trabalhar internamente com a variável no tipo que eu quiser pra sempre converter tudo em um lugar único:

import { useCallback, useState } from 'preact/hooks';
import register from 'preact-custom-element';
import { FunctionalComponent } from 'preact';

interface CounterProps {
  label?: string;
  steps?: string;
}

export const Counter: FunctionalComponent<CounterProps> = ({
  label = 'Count is',
  steps: rawSteps = '1',
}) => {
  // Converto o atributo steps (rawSteps) pra number e uso como steps internamente
  const steps = Number(rawSteps);
  const [count, setCount] = useState(0);

  const increment = useCallback(() => {
    setCount(count + steps);
  }, [count]);

  return (
    <button onClick={increment}>
      {label} {count}
    </button>
  );
};

register(Counter, 'ric-counter', ['label', 'steps'], { shadow: false });
//          ^            ^           ^                       ^
//          |         tag HTML       |                   shadow-dom
//     Componente           Atributos observados

Sempre que um atributo observado for alterado, o componente vai ser atualizado. Os atributos que não estiverem nessa lista só serão detectados caso sejam passados na inicialização.

Já o shadow, é um booleano que indica se o seu componente deve usar ou não o Shadow DOM.

O HTML com os atributos:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/vite.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Vite + Preact + TS + Web Components</title>
  </head>
  <body>
    <ric-counter label="Custom count:" steps="2"></ric-counter>
    <script type="module" src="/src/main.tsx"></script>
  </body>
</html>

Agora é só testar e ver um novo label e incrementando de dois em dois:

Callbacks

Os callbacks são um tipo importante de atributo, afinal as pessoas que vão utilizar o nosso componente precisam saber se um botão foi clicado e/ou se o estado do componente mudou.

Como os atributos de um web component são passados como strings, é preciso passar as funções de callback de uma forma diferente: via JavaScript.

E pra tornar isso possível vamos adicionar uma nova propriedade ao nosso componente chamada onChange e executar esse callback dentro a função de increment:

import { useCallback, useState } from 'preact/hooks';
import register from 'preact-custom-element';
import { FunctionalComponent } from 'preact';

interface CounterProps {
  label?: string;
  steps?: string;
  onChange?: (count: number) => void;
}

export const Counter: FunctionalComponent<CounterProps> = ({
  label = 'Count is',
  steps: rawSteps = '1',
  onChange,
}) => {
  const steps = Number(rawSteps);
  const [count, setCount] = useState(0);

  const increment = useCallback(() => {
    setCount(count + steps);
    onChange && onChange(count + steps);
  }, [count, onChange]);

  return (
    <button onClick={increment}>
      {label} {count}
    </button>
  );
};

register(Counter, 'ric-counter', ['label', 'steps', 'onChange']);

E agora no HTML, basta usar o querySelector e atribuir a propriedade com a nossa função de callback:

<body>
  <ric-counter label="Custom count:" steps="2"></ric-counter>
  <script type="module" src="/src/main.tsx"></script>
  <script type="module">
    const counter = document.querySelector('ric-counter');
    counter.onChange = () => {
      console.log('counter changed');
    };
  </script>
</body>

Agora é só testar e ver um console.log sendo executado cada vez que clicar no botão. Você também pode ver o resultado final no meu Stackblitz.

Conclusão

Poder utilizar um web component direto no HTML abre portas pra muitos casos reais de uso. Você pode exportar os seus componentes pra serem incluídos em sites wordpress, ou até mesmo criar wrappers pra outros frameworks e reutilizar o seu código em diferentes interfaces.

Como eu disse antes nesse post, eu não acho que valha a pena desenvolver aplicações inteiras usando web components podendo usar direto o preact ou outro framework, mas se o seu contexto é libs, widgets, ou qualquer tipo de componente que é incorporado em outro website (por exemplo um chat), essa abordagem vai fazer muito sentido.

Se você curte o assunto e gostaria de ver mais posts desses por aqui, me avisa porque é algo que eu tenho gostado bastante de estudar, e acho que realmente vale a pena o investimento.

E se você não gostou de alguma coisa, ou tem alguma sugestão que possa fazer esse e os próximos artigos menores, lança aqui nos comentários também. Todo comentário é bem vindo e as críticas vão me ajudar a aprimorar os próximos posts 🙂

Web Components e a minha opinião sobre o futuro das libs front-end

Ricardo Mello — Thu, 04 Apr 2024 12:50:36 +0000

Eu tô ficando velho. E como todo velho, eu ganho licença poética pra prever eventos futuros baseados em eventos passados. Tem dia que eu sei que vai chover, tem dia que eu sei que vai ser bom, e tem dia que eu consigo escrever.

Eu tenho trabalhado bastante com web components nos últimos anos, e tô realmente impressionado com o quanto eu consegui escalar o desenvolvimento das minhas libs depois que eu passei a utilizá-los, então esse post é pra compartilhar minha experiência e explicar por que eu acredito que o futuro das libs é por esse caminho.

Tá, mas o que são web components?

Eu copiei essa definição do site da Mozilla (MDN): Web Components é uma suíte de diferentes tecnologias que permite a criação de elementos customizados reutilizáveis — com a funcionalidade separada do resto do seu código — e que podem ser utilizados em suas aplicações web.

E a minha explicação de dev simplão é: Web Components são componentes similares aos do react, angular, etc, mas que rodam em qualquer lugar e são nativos do browser. Você cria um componente <ric-header></ric-reader> e pode usar em qualquer lugar que vai funcionar, assim como o nosso bom e velho javascript.

Em qualquer lugar?

Sim. Na ~~p$#%@~~ coisa toda. Você pode usar o mesmo componente em um site wordpress, em um site HTML igual aos que eu fazia em 2010, ou em uma SPA react/angular/seuframeworkaqui.

Os Web Components são nativos do browser, e por isso você não precisa de nenhuma mágica para renderizar. Desde que um browser moderno seja utilizado, você realmente pode utilizar o web component em uma página HTML básica ou integrar ao seu site em React.

E sobre browsers modernos, aqui está a especificação do caniuse. Todos os browsers atuais são compatíveis, com exceção do nosso já conhecido Opera Mini e desse "bug" no Safari.

Bug no Safari?

Na verdade é a falta de suporte ao atributo is="", e que está categorizada como WONTFIX no bugzilla. Nessa especificação, nós poderíamos customizar as tags nativas do HTML com esse atributo. Porém, não vai impactar em muita coisa porque podemos alcançar o mesmo resultado de outra forma.

Em resumo, você poderia registrar usar um componente de parágrafo customizado assim:



customElements.define("word-count", WordCount, { extends: "p" });

E utilizar o componente com esse código:



<p is="word-count"></p>

Porém, o mesmo comportamento pode ser alcançado registrando um novo componente assim:



customElements.define("word-count", WordCount);

E usando o componente:



<word-count></word-count>

Eu sei que a gente perde um pouco da flexibilidade por precisar de uma tag nova, mas não tem muito o que fazer a não ser reclamar na issue pra ver se a galera do safari implementa.

Casos de uso

E se você está se perguntando pra que criar uma tag customizada nativa do browser se o seu React/Angular já faz isso dentro do framework, vamos entender onde esses componentes podem te ajudar um bocado:

Bibliotecas agnósticas

Se você também trabalha desenvolvendo libs que precisam rodar em diferentes tecnologias, vale a pena olhar com carinho pra uma abordagem baseada em web components.

Muitas libs do mercado já estão indo por esse caminho como o Ionic, o Swiper, o Material, entre outros. A ideia aqui é criar a sua lib usando web components e criar wrappers pros frameworks que você quiser manter, enquanto suporta todos os outros. No caso do Swiper eles estão abandonando os wrappers também e indo pra uma abordagem full web component.

Design Systems

Uma das coisas mais difíceis no desenvolvimento de design systems é conseguir manter uma base agnóstica que sobreviva ao longo do tempo sem sofrer com clones e adaptações.

Os devs da sua empresa usam Angular e a sua empresa compra uma outra empresa onde os devs usam React. Unificar as identidades visuais provavelmente vai girar em torno de clonar o Design System pra React, ou em casos mais doidos reescrever tudo pra Angular.

Já com web components seria basicamente criar wrappers pro react e ir substituindo os componentes mantendo a regra de negócio (quase) intacta.

Micro Frontends

Eu continuo sendo do time contra Micro Frontends (fique à vontade pra me chamar pra bater um papo e me mostrar um case maneiro), mas respeito quem usa. Exemplo similar ao de Design Systems, MFEs geralmente envolvem a utilização de mais de um framework ao mesmo tempo.

E aqui, de novo, unificar os estilos entre diferentes times com diferentes frameworks é muuuito complicado. Às vezes eu navego em 3 telas do mesmo app e vejo 3 layouts diferentes, e é por conta dessa dificuldade de manter um padrão entre diferentes times com diferentes stacks de tecnologia em empresas gigantes.

Os Web Components se aplicariam muito bem nesse mesmo cenário tendo uma lib de componentes única entre os times.

E como eu faço pra usar esse treco?

Bom, tem várias ferramentas por aí que vão te dar o mesmo resultado. Vale testar a que for melhor pro seu cenário, mas eu vou te dar algumas ideias:

Se o seu forte é Angular, o Angular Elements é a ferramenta oficial pra isso. Porém, eu te recomendo testar o Lit que tem uma sintaxe parecida mas é focado em Web Components. Outra opção é o Stencyl, que é feito pela galera do Ionic.

Agora, se o seu forte é React, o suporte nativo só vai vir na v19 (acompanhe essa thread aqui), mas existem alguns wrappers pela comunidade que prometem o mesmo resultado. Outra opção, que eu recomendo fortemente, é o preact que é super leve, possui a mesma sintaxe e já tem suporte nativo.

E se você não está familiarizado com nenhum desses dois, vale fazer uns testes e ver qual você se adapta melhor.

Opinião sobre o futuro do desenvolvimento front-end

Eu acredito fortemente que as bibliotecas que usamos serão mais focadas em web components e menos em frameworks. O Swiper e o Ionic são bons exemplo disso e têm evoluído bastante.

Isso permitiria à galera do Angular, por exemplo, usar vários componentes que hoje são exclusivos do React e vice-versa. Outro ganho é que as pessoas que hoje mantém libs para os dois frameworks poderiam concentrar os esforços em uma lib universal, usando o tempo livre pra tomar uma cerveja ou criar novas libs.

Eu não acho que valha a pena desenvolver uma aplicação comum com web components, porque os frameworks realmente aceleram o desenvolvimento e colocar mais uma camada no meio pode não ser muito inteligente.

Porém, se você trabalha com libs, times cross, e/ou precisa ter uma base sólida de componentes, esse é o caminho. Eu tenho usado o preact onde vários sites de clientes usam os mesmos componentes e o resultado tem sido muito bom.

Se você curte o assunto e gostaria de ver mais posts desses por aqui, me avisa porque é algo que eu tenho gostado bastante de estudar, e acho que realmente vale a pena o investimento.

Adicionando domínio customizado a uma Lambda com o API Gateway

Ricardo Mello — Wed, 27 Mar 2024 23:43:27 +0000

Já tem tempos que eu não escrevo então me desculpa porque perdi um pouco o jeito, mas hoje eu vou compartilhar algo super simples que eu nunca tinha feito: adicionar um domínio customizado pra uma AWS Lambda.

Se você nunca criou uma lambda, te recomendo esse post aqui que eu acabei de criar.

Agora, nós vamos adicionar um domínio customizado pra ela.

Mas por que usar um domínio customizado?

E por que não usar? Parece que um gato sobe no teclado sempre que a gente gera um link de uma lambda. Links como https://dz4y7rvv2az4iopdqzvgneefhy0jdfii.lambda-url.us-east-1.on.aws ou https://lh4j4sdpmljdcrcr34gqc6ddni0qvugg.lambda-url.us-east-1.on.aws são gerados e ficam beeem feios quando usados no frontend.

Plus, se você precisar apontar o seu link pra qualquer outro lugar (outra lambda, uma API, outra cloud...) será muito mais tranquilo e você não vai ter que atualizar a url da lambda em milhares de lugares onde ela pode estar sendo utilizada.

API Gateway

Pra atingir o nosso objetivo, vamos usar o API Gateway. Esse cara consegue organizar todas as nossas lambdas e criar mapeamentos pra elas definindo paths específicos. Isso te permite usar a lambda nomesuperultragigante.lambda-url.us-east-1.on.aws como um endpoint comum api.meuwebsite.com/v1/lambda.

Criando a API no API Gateway

Pra começar, vamos criar a API que vai mapear a lambda em um endpoint no api gateway. Para isso, ainda na tela do API Gateway, vá em APIs > Create API > REST API. Eu vou usar o nome faker-api pra esse tutorial:

Com a API criada, você deve ver essa tela:

Resources

No API Gateway você pode realmente brincar de criação de API. Em create resources você pode ir definindo os paths por exemplo /v1, depois /v1/domain até chegar em /v1/domain/endpoint. É uma ferramenta muito poderosa que te permite mapear todas as rotas e integrar com lambdas, apis, ou qualquer outro serviço.

No nosso caso, eu vou tentar manter mais simples e criar um único resource chamado persons. Para isso, vá em Create Resource, dê o nome persons pra ele, selecione a opção de CORS e clique em Create Resource.

Com o endpoint persons selecionado, vá em Create method e preencha as seguintes infos:

Method type: GET
Integration type: Lambda function
Em lambda function: Selecione a nossa lambda de teste

Depois de clicar em Create method, o resultado deve ser esse aqui:

Clique em Deploy API e crie um stage chamado development:

Você deve ser redirecionado pra essa tela com o stage criado, e mais uma URL gigante:

Criando o domínio

Pra criar o nosso domínio, vamos no painel do API Gateway -> Custom domain names -> Create.

Antes de começar, na configuração do endpoint, você vai precisar adicionar um certificado pro domínio que você deseja criar. Clique em Create a new ACM certificate e uma nova aba se abrirá.

Na tela do Certificate Manager, clique em Request a certificate -> Request a public certificate.

Na tela que vai se abrir, insira o domínio que você vai usar pra solicitar o certificado. No meu caso é o faker-api.ricmello.com, mas você pode adicionar mais de um domínio ou um wildcard como *.ricmello.com pra não precisar criar um certificado pra cada subdomínio.

O método de validação recomendado pela própria AWS é o de DNS.

Clique em request e depois view certificate.

Caso você já use o Route53, basta clicar em Create records in Route 53 e os registros serão criados automaticamente pra validação do domínio. Ou caso você use outro serviço é só criar um novo registro do tipo CNAME e colar os valores que vão aparecer pra você como no print abaixo.

Depois de configurar o DNS, o seu certificado vai estar disponível, mas isso pode demorar um pouco. Você pode usar a ferramenta whatsmydns pra ver se a sua configuração tá certa e aguardar até o certificado ser emitido como esse aqui:

Agora podemos voltar na criação do domínio no API Gateway e selecionar o certificado criado. No nome do domínio eu preenchi o mesmo faker-api.ricmello.com que eu usei pro certificado:

Clique em Create domain name para salvar e volte pra tela de configuração de domínio. Você deve criar um CNAME apontando o seu domínio pro API Gateway domain name, que no meu exemplo é o d-4ip5ycuy62.execute-api.us-east-1.amazonaws.com.

Associando o domínio

Na tela de Custom domain names, vá em API mappings > Configure API mappings > Add new mapping, e configure um mapeamento selecionando a sua API e o stage criado.

Feito! O seu domínio vai apontar pro api gateway e você vai conseguir utilizar a lambda pelo mapeamento como na imagem abaixo.

E aí, curtiu? Tem alguma dúvida? Se tiver qualquer coisa que eu possa fazer pra tornar esse artigo melhor, pode reclamar, elogiar ou sugerir outro artigo. Manda ver nos comentários porque feedbacks são sempre super bem vindos.

Como criar um backend pro seu frontend com AWS Lambdas

Ricardo Mello — Mon, 25 Mar 2024 03:20:11 +0000

Embora eu não seja o cara do backend, eu sempre tive muito contato com o desenvolvimento de APIs mesmo enquanto front, mas Lambdas foram algo que eu sempre ignorei.

Primeiro eu achava complicado, depois desnecessário porque eu achava mais fácil subir uma aplicação, até o dia que eu resolvi dar uma chance pro negócio e cara, vale a pena.

No youtube tem vídeo antigo falando sobre isso, mas se você é velho que nem eu e gosta de ler, vamo lá!

Ah, e pra esse exemplo eu vou criar uma lambda que busca os dados da Faker Api. É um exemplo básico, mas mais pra frente eu vou explicar alguns casos de uso reais onde ele pode ser útil.

Criando a lambda

A real é que você não precisa ser o bichão do backend pra trabalhar com lambdas. Criar uma é bem simples e pode ser criada direto do painel da AWS. Pra começar, acesse o painel das lambdas e clique em Create Function.

Ao criar, você pode usar um blueprint que já contém alguns exemplos como conectar ao DynamoDB ou ao S3, mas pro nosso caso nós vamos de Author from Scratch mesmo.

Dê um nome pra function, que eu vou chamar de faker-api, e altere o campo architecture pra arm64 que tem um custo menor do que a x86. Você pode conferir o meu setup aqui:

Implementando a Faker Api

Function criada, agora vamos implementar o nosso código pra buscar os dados da faker api. Você deve substituir o código padrão do index.mjs por esse aqui:

import * as https from 'https';

function getData() {
  const apiUrl = `https://fakerapi.it/api/v1/persons?_quantity=1&_gender=male&_birthday_start=2005-01-01`;

  return new Promise((resolve, reject) => {
    const req = https.get(apiUrl, {}, res => {
      let rawData = '';

      res.on('data', chunk => {
        rawData += chunk;
      });

      res.on('end', () => {
        try {
          resolve(JSON.parse(rawData));
        } catch (err) {
          reject(new Error(err));
        }
      });
    });

    req.on('error', err => {
      reject(new Error(err));
    });
  });
}

export const handler = async (body) => {
  const res = await getData();

  const response = {
    statusCode: 200,
    body: res,
  };
  return response;
};

Explicando o código acima:

Nós temos a arrow function handler, que é responsável por executar a lambda. Dentro dela, eu tô chamando a função getData que por sua vez faz uma requisição pra Faker Api utilizando a api https do Node. Em seguida, faz o parser da response e retorna os dados.

A essa altura a sua lambda deve estar assim:

Clique em deploy para publicar 🙂

Criando uma URL pública

Por último, vá na aba Configuration, clique em Function url e Create function url.

Vamos deixar o Auth Type como NONE e em Additional Settings, marque a caixa Configure cross-origin resource sharing (CORS). Depois, é só clicar em Save. Você vai ver uma URL criada similar a essa aqui:

Basta abrir o link no seu navegador que você vai conseguir ver os resultados. E com isso você tem um endpoint seu publicado pra utilizar no frontend. É só consumir com a função fetch.

const getData = async () => {
    fetch('https://dz4y7rvv2az4iopdqzvgneefhy0jdfif.lambda-url.us-east-1.on.aws')
      .then((response) => response.json())
      .then((data) => {
        console.log('success: ', data)
      })
      .catch((error) => {
        console.error('error: ', error);
      });
  };

Tá, agora vamos aos esclarecimentos

Você deve estar se perguntando: pra que diabos eu preciso de uma lambda pra chamar outra API pública se eu posso chamar ela diretamente? E a realidade é que você não precisa. Porém, existem alguns casos onde esse tipo básico de lambda vai te ajudar bastante:

Proxy de API

Nem sempre você vai querer que o frontend se conecte no seu endpoint ou possa manipular os resultados da pesquisa. No nosso exemplo, a lambda está filtrando os resultados da Faker Api pra sempre mostrar uma pessoa do gênero masculino nascida a partir de 01/01/2005, e o frontend (ou um usuário mal intencionado) não consegue mudar os filtros aplicados.

Em um caso de uso real, eu subi um servidor do Strapi e usei a lambda pra expor algumas collections sem expor a API inteira. Nesse caso, a minha lambda tinha a apiKey pra consultar o Strapi e só retornava o que era estritamente necessário pro frontend funcionar. Praticamente um BFF.

Mock

Se você precisar subir um serviço pra simular uma API que ainda não está construída, você pode usar essa mesma lambda retornando dados estáticos respeitando o contrato da API que ainda será feita. Em minutos você vai ter um endpoint pra trabalhar que vai estar acessível de qualquer lugar.

É isso! E aí, curtiu? Tem alguma dúvida? Se tiver qualquer coisa que eu possa fazer pra tornar esse artigo melhor, seja reclamar, elogiar ou sugerir outro artigo, manda ver nos comentários. Feedbacks são sempre super bem vindos.

Porque você não deveria usar funções de debounce o tempo todo

Ricardo Mello — Tue, 24 Oct 2023 15:23:09 +0000

E porque essa técnica muito legal é gambiarra.

Hoje eu vi outro post ensinando a criar uma função de debounce pra diminuir a quantidade de requisições desnecessárias.

Se você não viu, tem esse ótimo post do FreeCodeCamp ensinando.

O debounce é ~~uma gambiarra~~ um recurso super útil e que pode te ajudar bastante a controlar a quantidade de requisições feitas ao servidor, principalmente quando os recursos são limitados. Geralmente usado em campos de autocomplete, você espera até o usuário parar de digitar por determinado tempo (300 ou 500ms) pra fazer a requisição, assim você não faz uma requisição pra cada letra e diminui a quantidade de requests "desnecessários".

Isso faz sentido?

Hoje podemos escalar aplicações como nunca em horários de pico, e poupar grana enquanto elas não estão sendo utilizadas. A obsessão por performance do lado do backend é frequente. Será que a API não consegue resolver isso sozinha?

A resposta é: sim, deveria. Estratégias de cache, bancos em memória, indexação, e um mundo de ferramentas criadas para fornecer uma resposta super rápida sem onerar o banco principal. APIs respondendo em 50ms enquanto a gente vai lá e mete um debounce de 300ms 🤡

A experiência do usuário

Todo mundo, principalmente quem é heavy user, já passou por apps ou sistemas onde você precisa esperar um tiquinho depois de digitar pra ver os resultados. É pouco tempo, mas é irritante quando você compara com ferramentas como a busca da Amazon, Google Maps, ou outras do tipo.

Se você já colocou o delay e a API demora um pouco a mais pra responder, soma os tempos e você vai ver o usuário triste.

"Aí, travou essa *****"
– Usuário triste

Depois, abre o seu inspector e faz uma pesquisa no Google Maps pra você ver quantas requisições ele faz.

Ah, mas DDoS...

Se você confia no seu frontend pra te poupar de um DDoS, meu amigo... você tá em uma situação complicada. Acho que só outro post mesmo pra caber, mas me avisa aqui que eu faço.

Então eu não devo usar debounce?

Calma... depois de virar dev sênior, você aprende que é pago pra dizer "depende" pra tudo. E mais uma vez aqui: DEPENDE.

Se você trabalha em um frontend que consome uma API nova, e o backend não consegue dar conta de muitas requests, remove o debounce e pede pra ele consertar esse treco aí. Manda o print do inspector do site da Amazon e avisa quantas pessoas usam diariamente.

Agora, se você trabalha em um sistema legado onde a API não dá conta da quantidade de requests, ou se o chefe não deixar o backend consertar o bug, ou se vc quiser salvar dinheiro pq a API do Google Places tá comendo seu orçamento, aí sim vc usa o debounce, mas não acostuma com ele. Debounce é gambiarra, não deixa te convencerem do contrário.

O guia definitivo para hospedar uma SPA Angular/React com S3, Route 53 e CloudFront

Ricardo Mello — Wed, 22 Mar 2023 02:28:33 +0000

O combo S3 + CloudFront é uma ótima opção para hospedagem de aplicações Angular e React. Como dito antes nesse post, uma SPA é simplesmente um monte de arquivos HTML, CSS e JS que rodam no browser, então qualquer servidor de arquivos cumpre a responsa de hospedar esse tipo de aplicação.

O S3 (Simple Storage Service) é um serviço de armazenamento de objetos que pode ser usado para armazenar e recuperar qualquer quantidade de dados de qualquer lugar na web.

O CloudFront, por sua vez, é uma rede de entrega de conteúdo (CDN) que entrega dados, vídeos, aplicativos e APIs com segurança, baixa latência e alta velocidade de transferência. Ao usar o CloudFront com o S3, você pode melhorar o desempenho e a confiabilidade do seu site ou aplicativo distribuindo seu conteúdo globalmente para reduzir a latência, melhorar o tempo de carregamento das páginas e a quantidade de acessos ao bucket.

Pré-requisitos

Antes de começar, precisamos seguir o passo a passo para a criação do bucket no S3, e caso você queira ter deploys automatizados, configurar o Github Actions pra atualizar o bucket automaticamente, Por último, vamos configurar o CloudFront e o Route 53.

Importante: embora uma infinidade de artigos e tutoriais (incluindo o meu anterior) ensine, não é uma boa prática deixar o bucket público em produção. Logo, o CloudFront se torna super necessário, principalmente em ambientes corporativos.

Reconfigurando o bucket

Depois de seguir o passo a passo do tutorial anterior, vamos tornar o bucket privado novamente. Vá na aba permissions do seu bucket, remova a policy do tutorial anterior e marque a opção Block all public access. O resultado deve ser esse:

Criando a distribuição

Vá para o painel do CloudFront na AWS e clique em Create Distribution. Na criação de distribuição, iremos preencher alguns campos:

Origin domain: selecione o bucket com a sua aplicação
Origin access: selecione a opção Origin access control settings (recommended), que irá deixar o bucket acessível somente para o CloudFront.
Ainda em Origin Access: clique em Create Control Setting, e em seguida em create.
Default root object: preencha index.html
Clique em Create Distribution.

Após a criação você verá um aviso dizendo que a policy do bucket precisa ser atualizada. O processo é bem simples: clique em Copy Policy no próprio aviso, que irá deixar a policy na sua área de transferência, depois em Go to S3 bucket, e cole o conteúdo em Bucket Policy.

Voltando à sua distribuição do CloudFront, você verá o link onde ela foi publicada. A essa altura o seu app já estará rodando nesse link mesmo com bucket privado.

Configuração do domínio

Também é possível configurar um domínio personalizado no Route 53. Caso você ainda não tenha uma zona configurada, você tem duas opções:

Com a hosted zone criada, basta navegar até ela e clicar em Create Record para criar um novo registro, e setar como Alias to CloudFront Distribution e apontar para a URL da sua distribuição como no print abaixo:

Depois, precisamos voltar no painel do CloudFront > sua distribution > settings e:

Adicione o seu domínio como alternate domain name
Crie um certificado
- Clique em Request certificate
- Selecione Request a public certificate na janela que vai abrir
- Insira o seu domínio em Fully qualified domain name
- Clique em Request
- Na lista de certificados, clique no certificado recém-criado
- Em Domains, vá em Create records in Route 53 e confirme a operação
- Aguarde o certificado ficar com o status Issued (pode levar alguns minutos)
Selecione o certificado que você acabou de criar

O pulo do gato

Tanto o Angular quanto o React possuem o conceito de rota, o que significa que elas são tratadas no frontend. Se o usuário der um F5 ou tentar abrir uma rota diferente do seu app, o CloudFront vai tentar buscar essa rota no S3 e retornar um erro porque ele não vai encontrar nenhum objeto na roda solicitada.

A solução é redirecionar as requests para o index.html. Para isso, vá em Error Pages > Create Custom Error Response e crie a configuração abaixo:

Essa config redireciona todos os erros 403 para o index.html e retorna Http 200 (OK) para o browser. Assim, independente da rota que o usuário acessar, o CloudFront vai retornar o frontend e o próprio frontend é quem vai gerenciar se aquela rota existe ou não, além de realizar os redirecionamentos caso necessário, que é o comportamento correto.

GG

Agora temos a aplicação publicada, com o bucket seguro e em uma rede de alta disponibilidade que vai acelerar o carregamento independente da localização do usuário.

É isso! E aí, curtiu? Tem alguma dúvida? Se tiver qualquer coisa que eu possa fazer pra tornar esse artigo melhor, se quiser reclamar, elogiar ou sugerir outro artigo, manda ver nos comentários. Feedbacks são sempre super bem vindos.

Deploy de app Angular/React para o S3 via GitHub Actions

Ricardo Mello — Fri, 17 Mar 2023 12:00:00 +0000

Há um tempo atrás eu escrevi esse post sobre como criar e publicar uma aplicação Angular no S3. Como ambos os frameworks usam a pasta dist, basta seguir os mesmos passos no React.

Agora, nós vamos usar o GitHub Actions pra automatizar o nosso deploy e atualizar o ambiente automaticamente a cada commit na branch principal.

E se você chegou até aqui mas ainda não entendeu muito bem porque publicar uma SPA no S3 ao invés de um nginx ou apache da vida, a resposta é simples: é tudo HTML, CSS e JS. Uma SPA tem um monte de JS incorporado, regras de interface, libs, etc. mas no fim disso tudo o código é executado no browser, então a gente só precisa de um servidor de arquivos pra fazer a mágica acontecer.

Repo

Dessa vez vamos usar um app react como exemplo, e se você é do team Angular pode usar esse repo como base.

Criando a Action

No seu repositório, vá para a aba actions pra criar o seu primeiro workflow. Digite Node.js na caixa de pesquisa, procure por essa action aqui e clique em Configure.

Importante: GitHub Actions é o nome da ferramenta. Dentro dela, nós configuramos os workflows. Um workflow é um conjunto de instruções pra fazer o que você quiser com o seu projeto: rodar testes, buildar a aplicação, fazer o deploy ou tudo isso junto, se você consegue fazer no terminal é possível fazer via Github Actions. Ainda tem uma série de comandos predefinidos pra te ajudar no marketplace.

Após clicar em Configure, o GitHub vai gerar um workflow padrão para uma aplicação node:

# This workflow will do a clean installation of node dependencies, cache/restore them, build the source code and run tests across different versions of node
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-nodejs

name: Node.js CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: 18.x
        cache: 'npm'
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

Explicando o arquivo acima, ele é executado tanto em pushes quanto PRs para a branch main. Roda no ubuntu e executará nas versões 14, 16 e 18 do node. Como a gente não precisa suportar várias versões, eu vou fixar na versão 18.x. Essa é a parte de configuração do workflow.

Nas steps, que são as etapas, o actions/checkout baixa o repositório, enquanto o setup-node instala o nodejs. Com o node instalado, rodamos o npm ci pra instalar as dependências, depois o build e os testes. Como a nossa aplicação não tem testes, eu vou remover essa última linha.

A essa altura, o seu arquivo deve estar assim:

name: Deploy React app to S3

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build-and-deploy:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Use Node.js 18.x
      uses: actions/setup-node@v3
      with:
        node-version: 18.x
        cache: 'npm'
    - run: npm ci
    - run: npm run build

Agora que já temos o script de build, é hora de publicar no S3. Eu criei um bucket com o nome de my-react-s3-app usando as configurações do tutorial anterior. Com o bucket pronto, fica faltando configurar as credenciais da AWS e subir os arquivos.

Com isso, o meu arquivo final ficou assim:

name: Deploy React app to S3

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Use Node.js 18.x
      uses: actions/setup-node@v3
      with:
        node-version: 18.x
        cache: 'npm'
    - run: npm ci
    - run: npm run build

    - name: Setup AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ${{ secrets.AWS_REGION }}

    - name: Deploy to S3
      run: aws s3 sync dist/ s3://my-react-s3-app

A step Setup AWS credentials configura o workflow pra usar as credenciais de uma conta que eu criei com permissão no S3. Tanto as credenciais quanto a region do meu app estão em secrets, assim eu não deixo nenhuma informação sensível no repositório.

Você pode ver como gerar as credenciais nesse link e você pode encontrar mais informações sobre as secrets aqui. Para criar as secrets basta ir no seu repositório no github > Settings > Secrets and Variables > Actions.

E por último, mas não menos importante, a task Deploy to S3 sobe os arquivos pro nosso bucket. Após fazer o push para o repositório, a aplicação fica disponível automaticamente em alguns segundos. Você pode acessar o meu app nesse link

npm install vs npm ci: qual utilizar?

Ricardo Mello — Tue, 28 Feb 2023 23:45:55 +0000

O comando padrão pra instalar as dependências é o npm install. Se você usa o npm há certo tempo, provavelmente já utiliza esse comando sempre que precisa instalar as dependências de um projeto.

O que nem todo mundo sabe é que desde o npm v6, existe um comando similar ao npm install chamado npm ci.

Nesse artigo, vamos entender as principais diferenças entre eles e quando utilizar cada um.

npm install

O npm install instala os pacotes do package.json e suas dependências. Caso alguma dependência possua o ^ ou ou ~, ele procura novas versões e atualiza o package-lock.json com a árvore gerada.

npm ci

npm ci, ou "clean install" é utilizado para instalar as dependências do zero. Diferente do npm install, esse comando instala as dependências a partir do package-lock.json ou do npm-shrinkwrap.json.

Isso garante que você irá sempre instalar a mesma versão de cada pacote, não importa quantas vezes o comando for executado e nem se houver atualizações disponíveis. Ideal para ambientes de build automatizado ou integração contínua (CI).

Como ele pula certas etapas como atualizar o package-lock.json e resolver as dependências, esse comando também é muito mais rápido do que o npm install.

Qual usar?

No seu ambiente de desenvolvimento, ou sempre que você quiser atualizar as dependências elegíveis, vale continuar usando o npm install
Já no caso de instalar as dependências no seu servidor de integração contínua, ou até mesmo instalar local mas sem atualizar nada, vá de npm ci

Conclusão

Ambos os comandos são similares mas têm aplicações bem distintas. Eu uso o npm install no dia a dia, mas recomendo fortemente a utilização do npm ci no servidor de integração contínua. Além de ter builds mais confiáveis sem a possível atualização de versões, ele ainda vai ficar mais rápido.

Commitar ou não commitar o package-lock.json?

Ricardo Mello — Sat, 25 Feb 2023 15:44:12 +0000

Versão resumida:

Sim, você deve commitar
Sempre faça o commit do arquivo quando ele for alterado
Nunca delete o package-lock.json e nem coloque ele no .gitignore
O mesmo vale para o yarn.lock

Contexto

Ainda hoje eu vejo muita gente discutindo sobre porque não commitar o package-lock. Rola um misticismo danado em cima desse arquivo tão útil e hoje vamos entender se vale a pena ou usar.

Os problemas

Tem sido cada vez mais raro, mas ainda acontece: aquela dependência que você adicionou no package.json e colocou a versão com um circunflexo (Ex.: "typescript": "^4.0.0") atualizou pra versão 4.9 e sua aplicação começou a quebrar.

Isso acontece porque você permitiu o update da major pra essa dependência, permitindo a atualização de novas features. O problema é que um código que o desenvolvedor considera como feature, pode se tornar uma breaking change pra você.

Daí você pode ser malandro e tirar o circunflexo pra travar a versão, mas você sabia que a dependência da sua dependência também pode ter o tal circunflexo?

Outro caso acontece quando você desenvolve a sua feature, commita o seu código, e na hora do CI o build vai lá e quebra, mas local ele roda normalmente.

Ou pior, a versão de produção começa a apresentar um bug estranho que só acontece em produção, e depois de horas investigando você descobre que é a versão da lib que tá diferente.

A solução: package-lock.json

Todos esses problemas poderiam ter sido evitados com o package-lock.json. O lock, como seu próprio nome diz, é uma espécie de trava que descreve toda a árvore de dependências geradas pelo npm install e garante que todas as pessoas do projeto, incluindo o seu CI, vão instalar as mesmas dependências e suas respectivas versões.

Como cada commit tem seu snapshot do package-lock, você consegue voltar pra uma versão anterior da aplicação e reinstalar toda a árvore de dependências que funcionava quando o snapshot foi criado.

O package-lock.json também indica quando uma dependência foi atualizada, te dando uma ótima visibilidade da árvore de dependências do seu projeto.

Pra galera do yarn: yarn.lock

E se você usa o yarn, isso também vale pra você. O yarn.lock tem a mesma funcionalidade do package-lock.json e também deve ser versionado.

React para devs Angular

Ricardo Mello — Mon, 09 Jan 2023 01:45:59 +0000

Já dizia o narrador em Joseph Climber, a vida de dev é uma caixinha de surpresas. Um dia você é dev Angular, no outro você acha uma oportunidade em uma empresa que você sempre quis trabalhar e quando vê a stack: React 🤦

Em outro você é contratado pra uma consultoria para trabalhar com Angular, o seu projeto é cancelado na primeira semana e os caras perguntam "rola react?" 🤦 de novo.

Pois é, os dois cenários aconteceram comigo em menos de um ano. Se adaptar à mudanças é uma skill importante, e isso não significa que você é um profissional ornitorrinco não. Só começa a ficar preocupante se você tiver um conhecimento superficial da stack mas o mais importante, independentemente do framework, são os fundamentos. E é sobre isso que eu pretendo escrever hoje: Como aprender React sendo um dev Angular.

Cada tópico possui links para a documentação oficial para que você possa se aprofundar nos conceitos, mas é super importante saber que a curva de aprendizado é bem menor do que parece.

O que é o React

React é uma biblioteca JavaScript para a construção de interfaces. E aqui começa a primeira diferença: o Angular é um framework.

Por ser uma biblioteca, o React fornece uma série de funções para a construção de interfaces, mas deixa a cargo do desenvolvedor como usá-las em sua aplicação.

Parte do sucesso do React vem dessa flexibilidade de ser relativamente não opinativo. Isso resultou em um ecossistema gigante de ferramentas em torno da lib, porém, ao mesmo tempo, você pode precisar de um pouco mais de esforço pra desenvolver uma aplicação do zero, porque precisamos passar um pouco mais de tempo configurando a estrutura do projeto e definindo/escolhendo os padrões.

Isso pode ser bem esquisito pra quem vem do Angular já que o framework te dá uma série de guidelines a serem seguidos, mas é algo que se acostuma. Você também vai perceber que dá pra utilizar alguns padrões do Angular em um app React como rxjs, nx, etc. e a comunidade tem uma série de padrões próprios do React também.

Eu sempre lembro de quando eu estava procurando referências sobre como criar a estrutura do projeto e caí num post do Dan Abramov dizendo que essa é a estrutura ideal: http://react-file-structure.surge.sh. Isso mostra o quão livre nós estamos para criar nossos próprios padrões. Só não se esqueça: com grandes poderes vêm grandes responsabilidades.

Criação de um projeto

Diferente do Angular onde o ng new é quase um mantra, nós temos uma série de possibilidades diferentes ao criar um projeto react. Uma delas, inclusive, se resume em adicionar duas tags <script> em um arquivo HTML qualquer.

A forma recomendada pela documentação mais próxima da nossa realidade é o create-react-app, que gera um projeto configurado com scripts para executar a aplicação, rodar o build, etc. Pra isso, basta rodar o seguinte comando:

npx create-react-app my-app --template typescript

O comando acima gera o projeto React configurado, e o flag --template typescript adiciona a nossa linguagem do coração. Sem ele, o create-react-app gera um projeto javascript.

Vite

Uma opção ainda melhor do que o create-react-app e que a comunidade já considera um novo padrão é o Vite.

A proposta dos dois é parecida, mas enquanto o create-react-app usa o webpack, o vite usa o esbuild que é significativamente mais rápido, e essa diferença de velocidade vai crescendo junto com a aplicação.

Pra criar um projeto com o Vite, é só rodar o comando abaixo e seguir as instruções:

npm create vite@latest

Componentes

Provavelmente o conceito mais importante do desenvolvimento front-end, a boa notícia é que a estrutura básica de um componente não muda de um framework pro outro.

O ciclo de vida e os nomes das propriedades são diferentes, então você provavelmente vai ficar com a documentação debaixo do braço por algum tempo, mas não vai demorar muito pra acostumar. Dá uma olhada nessa comparação de um componente básico:

Componente React

import React from 'react';
import './App.module.scss';

function App() {
  return <div className='App'>Hello World</div>;
}

export default App;

Componente Angular

import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  template: `<div class="app">Hello World</div>`,
  styleUrls: ['./app.component.scss']
})
export class AppComponent {}

Enquanto a sintaxe é bem diferente, você pode perceber elementos muito similares. Ambos importam um arquivo scss, ambos possuem seus templates e ambos exportam seus componentes. Sendo assim, é possível usar o conhecimento que você já tem sempre que for criar um componente novo.

Ciclo de Vida

As funções do ciclo de vida eram amplamente utilizadas pelos componentes de classe, mas como os componentes de função ganharam o gosto da galera, os Hooks tomaram a cena e você pode pular direto pra estudar a utilização deles, principalmente o Effect Hook, que é o cara que substitui os métodos do ciclo de vida em componentes de função.

Services

Já sobre services, diretivas, pipes... eles não existem.

Nesse caso nós voltamos ao bom e velho JavaScript e criamos funções que serão utilizadas.

Existem os React Hooks, que você pode usar pra centralizar grande parte da sua lógica que iria para os services, mas eles são bem diferentes. Enquanto os services são injetáveis e possuem um conceito completamente diferente dos componentes, os hooks são uma forma de adicionar funcionalidades aos componentes, e são executados pelos próprios componentes.

JSX

Embora seja possível usar React sem JSX via React.createElement(), na minha opinião não faz o mínimo sentido porque o código fica muito mais verboso.

O JSX (JavaScript XML) é uma extensão do JavaScript que te permite usar uma sintaxe similar à do HTML dentro do código JavaScript. Quando o código JSX for convertido pra JavaScript, ele é transformado em chamadas da função React.createElement(). Isso significa que esse código:

const element = <h1>Hello, world!</h1>;

Será convertido pra esse código durante o build:

const element = React.createElement('h1',  'Hello, world!');

O JSX é o formato recomendado e torna muito mais fácil a escrita dos templates. Há algumas pequenas diferenças em relação ao HTML como a classe CSS, em que você usa a propriedade className ao invés de class que é uma palavra reservada do JS, mas o fato de poder utilizar funções JS enquanto monta o template ajuda muito. Na minha opinião um list.map(item =>{}) é bem mais fácil de se fazer e entender do que um *ngFor="let item of list".

Props e State

As props são equivalentes aos @Input do Angular, onde nós passamos as propriedades do componente. Cada prop estará disponível como um atributo do objeto props da função do componente.

// Passando a prop title para o componente hello world
<Header title="Hey!" />

// Utilizando a prop na função
const Header = ({ title }) => <h1>{title}</h1>

O React não possui um equivalente ao @Output, mas nós podemos passar uma função de callback que será utilizada:

// Passando o callback de click para o componente de call to action
<CtaButton label="Click me" onClick={() => alert('Hello World')} />

// Utilizando o callback no evento de clique do botão
const CtaButton = ({ label, onClick }) =>
  <button onClick={onClick}>{label}</button>

State

Além das props, cada componente possui o seu estado interno. Uma vez que esse estado é alterado, o componente renderiza novamente e o estado é mantido. Nós precisamos do hook useState() para acessar o estado de um componente de função.

function App() {
  // Declarando uma nova variável de estado, que chamaremos de "count" e definimos como 0
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>You clicked {count} times</p>
      {/* Ao clicar no botão, chamamos a função setCount com o novo valor */}
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}

Conclusão

Embora eu tenha lutado com todas as minhas forças nos últimos anos, o React me levou pro time e eu tenho gostado bastante de trabalhar com ele.

O React é mais simples que o Angular, isso é fato e a prova é que o Angular vem se tornando mais simples a cada release pra competir. Ter o conhecimento de Angular vai te fazer estar um passo à frente no quesito estrutura de projeto e padrões então o exercício maior é se aprofundar nos conceitos da lib enquanto põe alguns conceitos do Angular na geladeira.

Somando isso a uma comunidade hypada cheia de ferramentas pra agilizar o desenvolvimento, nós temos uma facilidade muito grande de desenvolver projetos rapidamente sem comprometer a qualidade.

Eu espero de verdade que você goste do framework e desse artigo, e se você chegou até aqui, tenta deixar um comentário com o que você gostaria de ver nos próximos posts e o que você achou do texto. Com isso, você me ajuda a definir os próximos temas :)