Forem: Romildo Junior

Práticas para projetos javascript robustos

Romildo Junior — Tue, 14 Oct 2025 13:51:16 +0000

Javascript é uma linguagem interessante - ou no mínimo diferente. Você talvez tenha uma visão de que é pura gambiarra, em especial se vem de algum ecossistema mais "consistente" como C#, ou Java.

Embora o autor desse texto seja certamente uma pessoa com um viés positivo, dado que alguns boletos são recorrentemente pagos utilizando essa linguagem, é fato que ela te permite fazer muitas coisas estranhas - o wtfjs tem um lista bem completa.

Um grande colega de trabalho, ao qual me refiro como "o primeiro senior de verdade que conheci", sempre reclamou da falta de bons padrões centralizados. Ele veio do ecossistema C#, em que algo como a biblioteca polly é lugar comum. Uma outra crítica recorrente era destinada a vícios no fluxo de desenvolvimento bem característicos de quem utiliza a stack: console.log no lugar de um debugger decente; medo de utilizar design patterns corretamente, em especial Dependency Injection; desleixo com tratamento de exceptions. Isso pra citar alguns.

O Javascript das Ruas

Como um verdadeiro canivete suíço, existem coisas que apenas JS tem. A começar que a linguagem em si se tornou uma espécie de bytecode nativo para web com o tempo. O código em produção dessa página, por exemplo, é algo mais ou menos assim:

(self.webpackChunk_N_E = self.webpackChunk_N_E || []).push([
      [8261], {
        1421: (e, t) => {
          "use strict";
          Object.defineProperty(t, "__esModule", {
            value: !0
          }), ! function(e, t) {
            for (var r in t) Object.defineProperty(e, r, {
              enumerable: !0,
              get: t[r]
            })
          }(t, {
            getAppBuildId: function() {
              return u
            },
            setAppBuildId: function() {
              return n
            }
          });
          let r = "";
// e assim continua, para o infinito e além

Mas qual seria a linguagem para humanos? A resposta hoje é simples, Typescript. Mas esse posto já teve outros concorrentes no passado: coffeescript, elm e flow, pra citar alguns.Talvez esse seja justamente o primeiro passo para ter um projeto minimamente pronto para produção: utilizar typescript.

Eu poderia incluir aqui uma série de debates que surgiram durante os anos - alguns bem filosóficos, que adentram a discussão entre tipagem estática vs dinâmica - porém vou recorrer a argumentos pragmáticos:

As melhores ferramentas, desde ORMs a Frameworks (e.g. TypeORM, Prisma, NestJS) são melhores e mais ergonômicas com Typescript.
A documentação do código se torna um subproduto.

Um caso de estudo sobre utilização de Typescript

Um exemplo prático bem interessante diz respeito a um dos temas básicos que precisam ser decididos em qualquer projeto: como realizar a validação de payload de entrada? Embora pareça algo simples, verificar de forma confiável se os dados estão corretos (seja tipo, valor, ou algo mais complexo) pode rapidamente virar um gargalo de performance ao incrementar a escala do problema.O clássico dos clássicos sempre foi utilizar o joi:

import { array, object, string } from "joi";

export const signUpData = object({
  nome: string().required(),
  email: string().email().required(),
  senha: string().required(),
  telefones: array().items(object({
    numero: string().length(9).required(),
    ddd: string().length(2).required(),
  })).required(),
});

export const signInCredentials = object({
  email: string().email().required(),
  senha: string().required(),
});

Se você já implementou o zod em alguma aplicação, certamente esse snippet é bem familiar - com efeito, ele se tornou um sucessor espiritual do joi com melhor suporte a tipagem. Essa abordagem realiza as validações em tempo de execução, em que a magia consiste em uma interface fluente agnóstica. O desenvolvedor define o que quer validar e isso funciona muito bem.

Mas sabe o que pode ser ainda melhor? Definir uma interface normal e a própria linguagem garantir o formato dos dados.

// usuario.ts
interface Usuario {
  nome: string;
  email: string & tags.Format<"email">;
  senha: string;
  //...
}

// server.ts
assert<Usuario>(
  request.body // um objeto ainda não validado
);

E se apenas a ergonomia como argumento possa ser vista como algo purista (afinal, é apenas "syntax suggar"), talvez os benchmarks disponíveis na documentação do typia, que permite esse tipo de técnica, sejam mais impactantes:

O fato de ter um compilador na toolchain, com um intermediário entre o que você escreve e o que executa no browser (ou na v8, de forma mais geral), permite abordagens agressivas como Ahead Of Time (AOT) Compilation. O que isso significa? Que usando uma etapa intermediária, é possível extrair de uma interface typescript todos os metadados para validar o payload e gerar funções de validação inline muito mais otimizadas que algo genérico, como é o caso do zod/joi. Algo que o typia usa como principal truque. Isso pode ser estendido para outros casos relevantes, desde schemas graphql, até especificações OpenAPI - sem esquecer de coisas mais tradicionais, como docs funcionais das classes.

Um projeto com typescript, no mínimo, tem uma camada de metadados incrivelmente útil, seja para humanos (que vão ler um código mais explícito), ou para ferramentas (que podem fazer inferências e extrair contexto de forma mais robusta).

Considerando que Typescript é um ponto pacífico, a abordagem de ser um superset da linguagem original é uma via de mão dupla: enquanto os padrões ECMAScript são compatíveis (com alguns poucos casos em que essa regra não se mantém, a exemplo da implementação de decorators), a linguagem em si não blinda um projeto de ter diversos anti-patterns clássicos.

Erros como dados

Uma das principais dificuldades é fugir de algo fortemente baseado em fluxos de try/catch. Não é difícil encontrar algo assim:

async execute(personId: string): Promise<ProfileEntity | null> {
  try {
    const profile = await this.repository.getByPersonId(personId);
    if (!profile) throw new NotFoundProfileException('api.errors.profileNotFound')
    return profile
  } catch (error) {
    if (!(error instanceof NotFoundProfileException)) {
      throw new GetProfileException(`Error when try to get a person by personId: ${ personId }`);
    }
    throw error;
  }
}

O principal problema é que diferente de linguagens como Java, em que é possível forçar o consumidor a validar quais exceptions um método pode lançar, no JS isso é uma verdadeira Caixa de Pandora.

Essa situação, especialmente quando o tipo de erro é algo conhecido (provavelmente pela familiaridade com a lib por parte de quem desenvolve), tende a levar ao uso de try/catch para gerenciar fluxos normais da aplicação. Uma forma de simplificar isso é justamente considerar que fluxos de erro conhecidos e tratáveis devem ser controlados por estruturas lógicas estruturadas, como if/else, o que leva naturalmente ao conceito de error as data - algo comum em GraphQL e outras linguagens como rust ou go.

Fluxos de erro conhecidos e tratáveis devem ser controlados por estruturas lógicas estruturadas, como if/else

Falando de forma mais prática, o seguinte código é mais simples de manter e descreve de forma mais direta a regra de tratamento do erro:

async execute(personId: string): Promise<Result<ProfileEntity>> {
  try {
    const profile = await this.repository.getByPersonId(personId);
    const isValidProfile = profile instanceof ProfileEntity;
    return isValidProfile
      ? Result.success<ProfileEntity>(profile) 
      : Result.fail<string>('api.errors.profileNotFound') 
  } catch (error) {
    return Result.fail<string>('api.errors.profileApiException')
  }
}

Um exemplo um pouco mais complicado

Em algo similar ao callback hell, estenda essa abordagem para quando múltiplas chamadas são realizadas, sobretudo com fluxos alternativos em casos de erros específicos que podem ser recuperados. O seguinte código seria um exemplo com try/catch:

async getCalendar(personId: string): Promise<Calendar> {
  try {
    const profile = await this.repository.getByPersonId(personId);

    if (!profile) {
      throw new Error("MISSING_PROFILE");
    }

    let calendar: Calendar;
    try {
      const structure = await this.repository.getStructure(personId);
      calendar = await this.repository.getCalendar(structure.code);
    } catch (e) {
      calendar = await this.repository.getGlobalCalendar();
    }

    return calendar;
  } catch (error) {
    const errorMessage =
      error instanceof Error ? error.message : String(error);

    switch (errorMessage) {
      case "MISSING_PROFILE":
      case "INVALID_PROFILE":
      case "INVALID_STRUCTURE":
      case "INVALID_CALENDAR":
        throw error;
      default:
        const unknownError = new Error("UNKNOWN");
        unknownError.cause = error;
        throw unknownError;
    }
  }
}

Observe como a lógica tende a entrar e sair de blocos contextuais. Em especial, é difícil encadear operações de modo consistente e a utilização dessa função em um controller, por exemplo, seria igualmente complexa.

A mesma operação pode ser reescrita do seguinte modo:

type Reasons = "INVALID_PROFILE"
  | "MISSING_PROFILE" 
  | "INVALID_STRUCTURE"
  | "INVALID_CALENDAR"
  | "UNKNOWN"

async getCalendar(personId: string): Promise<
  Result<Calendar, Failure<Reasons>>
> {
  try {
    const profile = await this.repository
      .getByPersonId(personId);

    if (profile.hasError || !profile.value) {
       return Result.fail("INVALID_PROFILE", profile.error)
    }

    const structure = await this.repository
     .getStructure(personId);

    const calendar = structure.hasError 
      ? this.repository.getGlobalCalendar()
      : this.repository.getCalendar(structure.value.code);

    if (calendar.hasError) {
      return Result.fail(
        "INVALID_CALENDAR", 
        calendar.error
      )
    }

    return Result.ok(calendar.value);
  } catch (error) {
    return Result.fail("UNKNOWN", error)
  }
}

Em que se torna mais simples entender como os erros conhecidos são tratados.

Muito embora o fluxo de desenvolvimento já seja melhor com uma simples classe de resultado, a solução de fato as vezes está em uma camada anterior. Pode ser o caso de tratar de forma mais estruturada questões de resiliência como um todo, aplicando padrões como retry, fallback, bulkhead, cache, ou circuit break.

Erros Transitórios

De forma geral, esses padrões resolvem um tipo de erro conhecido como transitórios (transient errors). A já citada polly é talvez o exemplo mais completo de uma abordagem flexível baseada em políticas de resiliência, que acabam sendo um misto desses padrões de projeto aplicados conforme for necessário para o problema específico.

Em algo que é relativamente comum (basta observar como NestJS/Angular e Spring Boot são similares, por exemplo), quando um time de desenvolvedores migram de stack e implementam um análogo do que utilizavam na sua linguagem do coração, a cockatiel traz literalmente o mesmo para o ecossistema JS.

Policies na prática

A partir das funções de alto nível disponíveis na cockatiel, é possível encapsular lógicas customizadas e criar uma pipeline de resiliência a nível de aplicação:

import {
  bulkhead,
  circuitBreaker,
  CircuitState,
  ConsecutiveBreaker,
  ExponentialBackoff,
  handleAll,
  retry,
} from "cockatiel";
import { env } from "./env";
import { getLogger } from "./logger";

const { resiliency } = env;

const logger = getLogger("resiliency");

export const circuitBreakerPolicy = circuitBreaker(handleAll, {
  halfOpenAfter: resiliency.circuitBreaker.halfOpenAfter,
  breaker: new ConsecutiveBreaker(
    resiliency.circuitBreaker.maxConsecutiveFails,
  ),
});

circuitBreakerPolicy.onStateChange((state) =>
  logger.info({ policy: "Circut Breaker", state: CircuitState[state] }),
);

export const retryPolicy = retry(handleAll, {
  maxAttempts: resiliency.retry.maxAttempts,
  backoff: new ExponentialBackoff({
    maxDelay: resiliency.retry.maxDelay,
  })
})

retryPolicy.onRetry(event => {
  logger.warn({
    policy: 'retry',
    attempt: event.attempt,
    delay: event.delay,
  })
})

export const bulkheadPolicy = bulkhead(
  resiliency.bulkhead.size,
  resiliency.bulkhead.queue,
);

Em alguns como bulkhead, circuit breake e retry, essa configuração acaba sendo global, porem outros padrões como fallback são mais comuns durante a requisição/operação local:

const fallbackPolicy = fallback(handleAll, async () => {
  HttpClient.logger.info({
    policy: "fallback",
    fallbackUrl,
  });
                                                                                          
  return fetch(url, payload).then((r) => {
    this.config.validateStatus(r.status);
    return r;
  });
});

Por fim, a função wrap permite conectar todas as políticas:

const response = await wrap(
  circuitBreakerPolicy,
  bulkheadPolicy,
  fallbackPolicy,
  retryPolicy,
).execute(async () => {
  if (bulkheadPolicy.executionSlots === 0) {
    HttpClient.logger.warn({
      policy: "bulkhead",
      executionSlots: `${bulkheadPolicy.executionSlots}/${env.resiliency.bulkhead.size}`,
      queueSlots: `${bulkheadPolicy.queueSlots}/${env.resiliency.bulkhead.queue}`,
    });
  }
                                                                                          
  return fetch(url, payload).then((r) => {
    this.config.validateStatus(r.status);
    return r;
  });
});
                                                                                          
return [
  response.status, url, response.json() as Promise<TData>
];

Caso você tenha alguma necessidade em específico, por fim, é possível criar novas implementações a partir da classe Policy - um exemplo comum é uma política de cache, que administre toda a lógica de hit/miss e possa ser utilizada em cadeia com fallbacks.

Dito isso, tratar erros transitórios de forma intencional é evitar uma das clássicas falácias da computação distribúida: a rede é confiável. Certamente existirão momentos de indisponibilidade e confiar cegamente em recursos externos trará um efeito dominó mais cedo ou mais tarde.

Confiar cegamente em recursos externos trará um efeito dominó mais cedo ou mais tarde.

Um outro problema que precisa ser resolvido, diz respeito ao "erro de 1 milhão de dólares" de Tony Hoare: referências nulas.

Mas o que é null? É melhor ou pior que undefined?

A existência do tipo primitivo null é um caso em que a linguagem poderia ser chamada de Java Script, dado que foi inspirado no conceito de Java. Tem como significado "algo que foi iniciado com valor nenhum". Já undefined surge em uma evolução da linguagem, com a semântica de "algo que não foi inicializado ainda".

Em um nível fundamental, ter coisas que podem não existir é uma fonte de problemas - em alguns casos, como Kotlin, isso é atacado frontalmente, de modo que o design da própria linguagem força o desenvolvedor a lidar com valores opcionais explicitamente. O fato de existirem duas formas de representar isso é um agravante adicional.

Se por um lado é importante evitar utilizar um dado sem verificar sua existência, por outro pode ser uma fonte problemas. Uma análise interessante é o artigo The bloat of edge-case first libraries, do Jamer Garbutt, que analisa a forma com que uma cultura de criar código focado em edge cases leva a "micro bibliotecas" como is-arrayish ou is-odd, gerando um problema generalizado de supply chain, o calcanhar de Aquiles das comunidades python e Javascript no que diz respeito a segurança.

Resta, então, o dilema: o que fazer? Criar uma cultura de validação extrema assumindo que em qualquer momento algo pode ser inexistente (possivelmente fazendo over engineering ou usando bibliotecas atômicas de terceiros), ou ter uma aplicação simples, legível, sem dependências e a uma linha do famoso can't access property "..." of undefined? A resposta está em dividir corretamente as responsabilidades.

Técnicas para lidar com valores nulos

O primeiro passo é mais simples: escolha uma das formas e limite o uso da outra, seja com linter, formatadores ou apenas convenções. Ter um tipo de valor vazio já traz problemas o suficiente, manter uma duplicidade trará ainda mais confusão.

Além disso, não tente acessar propriedades, métodos e índices de variáveis não validadas. Utilize optional chaining (.?). Se fizer sentido um fallback (e não seja necessário algo estruturado, como já mencionado na seção em que falamos sobre cockatiel), nullish coallescing (??) é uma forma consistente e evita problemas envolvendo booleanos, algo comum ao utilizar um operador lógico ou (||).

O exemplo abaixo certamente é teórico, porém serve para ilustrar como esses operadores são poderosos. Em especial, mostra como o optional chaining pode ser utilizando também para métodos e índices de arrays.

const data = maybe?.get(0) 
  ?? maybe?.[0]
  ?? maybe?.first
  ?? { message: "not found" }

Embora seja possível realizar esses tratamentos, inclua uma camada de validação bem estruturada e utilize valores imutáveis sempre que possível, para garantir que a confiabilidade dessa verificação não é perdida durante a execução. A keyword const e tipos auxiliares como Readonly evitam que o valor possa ser "zerado" de formas implícitas pelo código.

A melhor forma de lidar com valores nullable é evitar que se propaguem: ter uma camada de validação bem estruturada e tratar dados confiáveis como imutáveis.

Uma base estável

Em resumo, se for necessário deixar uma mensagem a partir dessa discussão, lembre-se do seguinte:

Um projeto com typescript, no mínimo, tem uma camada de metadados incrivelmente útil, seja para humanos (que vão ler um código mais explícito), ou para ferramentas (que podem fazer inferências e extrair contexto de forma mais robusta).
Fluxos de erro conhecidos e tratáveis devem ser controlados por estruturas lógicas estruturadas, como if/else;
Confiar cegamente em recursos externos trará um efeito dominó mais cedo ou mais tarde;
A melhor forma de lidar com valores nullable é ter uma camada de validação bem estruturada e tratar dados confiáveis como imutáveis.

Times que resolvam esses problemas terão eliminado uma fonte recorrente de instabilidade dentro da stack que domina a web. Além disso, adicionar uma suíte de testes robusta e escolher corretamente padrões de projeto que se encaixam no contexto podem ser citados, uma vez que merecem artigos dedicados.

A passionate post about Neovim

Romildo Junior — Fri, 09 May 2025 23:50:44 +0000

I'm gonna be honest: Neovim is not the most common tool you will want to have. If you're searching for a fancy agentic mode? Zed and Cursor got you covered. What about an "enterprise level" tool belt? You know, the IntelliJ multiverse is your way of doing things (except for C#, then you're a Visual Studio passionate). For every other use case? VS Code for the win.

But there's something, even addictive, about (neo)vi(m): it makes you think about doing less.

Writing less code;
Opening fewer tabs;
Using fewer resources;
Using fewer "magic" things.

Having more control.

Act 1: Chess

Playing chess (or any "modern 3D chess game with tons of new pieces and an Excel-like UI" aka RTS Games) is one of my hobbies. It's amazing how you get your brain to have three "modes": operational, tactical, and strategic.

It's important to know the micro: how pieces move, how to capture. Then you need to take a look at your strategy and tactical patterns – openings, uncovered checks, and how to apply a check with a surname (checkmate, bat dum tsss) at the end of the game. How do you learn those things? By doing puzzles.

I love puzzles.

As a matter of fact, Neovim had the same feeling: you need to learn how to move the cursor, through motions. How to select things, rename, yank ("+y to copy the selection to the system clipboard, in case you need it. "+p to paste from it. Hi future me!). Then you need to take a look at how the different modes work (and that's why Neovim is a multi-modal editor). And, of course, how to exit (:wq).

It's like learning every day how to be more "expressive" through your code, until the day you just forget you're using something to make software – you just create the software. No pop-ups, no file indexing taking 5 minutes. No JVM eating 16GB of RAM. No ads to enable the new fancy AI tool.

And you can always study a bit more about how to do more with fewer irrelevant steps. You learn how to shorten the gap between thinking and running the code.

Act 2: Vinyl

Now you can be 100% sure about my "classic stuff" passion. I'm also a vinyl collector (proud of my Tim Maia's World Psychedelic Classics disc). But vinyl isn't about old stuff. In fact, you need to choose a good turntable, amp (and possibly pre-amp), and audio monitors. Part of the cool thing about this hobby is just building your setup, seeking the perfect experience.

Neovim also gives this kind of pleasure.

You can change every aspect, choose any extensions you like. From big UI things like the file tree, the search mechanism, LSP and AI integration, or the plugin manager to commands, keybindings, colors – you will probably find the works of tpope and junegunn.

You just have the control. And no company can take it from you.

The Encore: Mastery Through Challenge

Beyond the initial hurdle, Neovim offers a continuous path of increasing depth. It presents a constant, engaging challenge that scales with your ambition. You can delve as deep as you desire, even venturing into creating your own plugins and crafting custom UI components. This inherent potential for boundless growth and personalized optimization is precisely why I've embraced Neovim. It's not just a tool; it's a journey of continuous refinement and mastery.

Quais as melhores ferramentas para trabalhar com Node?

Romildo Junior — Thu, 01 May 2025 01:47:26 +0000

Utilizar boas ferramentas é algo que transcende a sua área de atuação. Desde um jogador de futebol ou músico profissional, até um desenvolvedor de software. Nesse artigo, proponho algumas boas opções para desenvolvedores trabalhando com node, javascript e typescript.

Package Managers

Ferramentas para gerenciar pacotes e dependências, realizar publicação de libs e versionamento.

npm

O npm é a opção padrão, que está sempre acompanhando o node em qualquer instalação, de modo que tem a vantagem de ser a referência.

Em algum momento, a falta de desempenho e funcionalidades focadas na DX (Developer Experience) motivaram o surgimento do yarn, porem isso não é algo que é mais tão relevante - desde resolução customizada de dependências, até suporte a monorepos, o npm possui uma boa estabilidade e sempre está ali disponível. Provavelmente, também será o que as automações de cicd vão se basear na maior parte dos projetos.

https://docs.npmjs.com/about-npm

bun

O bun acaba sendo uma solução completa, pois também pode ser utilizado para outros fins além de gerenciamento de dependências. Nesse ultimo quesito, ele disputa espaço com o pnpm - uma vez que ambos possuem foco em performance.

O fato de ser possível utilizar o bun também para outras partes da toolchain (bundler, runtime) acaba sendo um fator importante de desempate, algo que estou testando com a lib samless

https://bun.sh

Lerna

O lerna existe há bastante tempo, tendo passado a utilizar nx como base. Para monorepos, ele se integra perfeitamente com a funcionalidade de workspaces do npm, além de facilitar estratégias avançadas de versionamento com bump independente de versões, utilização de tags (git), versionamento semântico baseado em conventional commits.

Inclusive, utilizei antes dessa mudança para o nx e o estado atual é simplesmente muito superior (caso você tenha traumas dessa época em que tudo era mato na hora de utilizar monorepos).

Configuração de ambiente

Ferramentas que permitem gerenciar versões do node globalmente

nvm

O bom e velho Node Version Manager. Extremamente popular, bom no que se propõem, é sem dúvidas um must-have (sem contar no fato de que grande parte dos desenvolvedores da comunidade javascript estão familiarizados).

Uma opção igualmente interessante é o fnm, que faz parte da leva de ferramentas desenvolvidas em rust, sendo o uso bastante próximo.

https://github.com/nvm-sh/nvm

Bundlers

Ferramentas que permite transpilar código em ts/tsx para js, aplicando otimizações diversas como ofuscação, bundle em arquivo único, etc.

esbuild

Ver algo com a qualidade do esbuild é sem dúvidas fantástico - ainda mais se você viveu os anos de reinado do webpack, com configurações complexas e performance questionável.

Várias das ferramentas de build modernas, em especial o vite (que irei comentar abaixo), foram criadas a partir do esbuild, de modo que pode ser útil caso você queira "escovar bits" para extrair o máximo de performance.

https://esbuild.github.io/

vite

O Vite me foi apresentado em um contexto de front-end web, embora creio que seja possível utilizá-lo também no backend.

É a minha ferramenta de escolha para subir aplicações, bastando algo como:

$ npm create vite

E selecionar algumas opções para subir algo que utilize react, vue, svelte ou até mesmo HTML, css e javascript puros.

https://github.com/vitejs/vite?tab=readme-ov-file

tsup

A magia do tsup é entregar bons padrões e velocidade. É possível subir uma aplicação com typescript sem precisar configurar nada, bastando apenas:

$ tsup src/index.ts

Para gerar um output em dist/index.js. Rápido e direto.

https://tsup.egoist.dev/

Testes

Ferramentas para escrever e executar testes, coletar coverage, etc

jest

O jest se tornou o padrão de fato dentro do ecossistema javascript, algo que é comprovado pelas alternativas nativas do node, deno e bun que copiam o design e a DX de forma idêntica.

Apache jmeter

Dentre as ferramentas mais clássicas, eu poderia listar jmeter como o Eclipse dos testes de performance. Basta adicionar o gerenciador de plugins para ter um canivete Suíço que consegue simular usuários com qualquer tipo de comportamento estatístico, gerar diversos tipos de gráficos e ser adicionado a qualquer pipeline de CI/CD.

Vale comentar que existem ferramentas com um foco maior em uma abordagem "as a code", das quais o locust e o artillery se destacam.

Uma abordagem interessante com o jmeter consistem em integrá-lo com o Grafana, de modo a ter uma visão em tempo real dos resultados dos testes (via InfluxDB).

Stryker Mutator

O stryker permite fazer testes de mutação de forma automatizada. Ele se integra de uma forma muito prática ao jest, permitindo avaliar se a suíte de testes em si possui qualidade. É uma boa forma de testar se as aplicações possuem testes unitários apenas pelo coverage, ou se estes de fato agregam valor na estabilidade do software.

https://stryker-mutator.io/

Pact

O pact acaba sendo outra ferramenta para testes menos comuns. Nesse caso, seria "o stryker dos testes de contrato". Caso você utilize uma abordagem "consumer first" na hora de construir APIs, pode ser uma ferramenta crucial.

Se torna possível, por exemplo, criar testes na aplicação cliente que geram automaticamente um "contrato", o qual pode ser utilizado no backend para validar modificações nas APIs. Isso evita que breaking changes passem despercebidas.

Como criar uma CLI com React

Romildo Junior — Fri, 25 Apr 2025 02:54:00 +0000

Não é novidade que existem CLIs. Nem que elas podem ser criadas das mais diversas formas, desde algo pequeno e objetivo como um simples ls, até editores complexos e poderosos como o Neovim.

Recentemente estive pesquisando sobre as novas ferramentas de IA e percebi um detalhe bem interessante sobre o Claude Code, Codex, Copilot... Todos utilizam React!

E é isso que vou mostrar como fazer nesse artigo.

TL;DR

Nesse artigo vamos focar no mínimo necessário e o código final está disponível em jrmmendes/ink-cli-minimal-app.

Caso procure uma aplicação um pouco mais completa, com alguns padrões adicionais e testes unitários, há um template disponível em jrmmendes/create-cli-app, que pode ser testado localmente:

npm i -g @jrmmendes/create-cli-app

create-cli-app --shell

Veja a demo.

Learn Once, Write Anywhere

O meu objetivo não é falar sobre react de forma filosófica aqui, porem é útil refletir sobre a ideia central dessa tecnologia: leve o conhecimento sobre como criar interfaces de um lugar, para outro.

Dado que a tecnologia é a mesma (React), em cada plataforma existe uma forma de utilizar os componentes básicos sobre os quais algo pode ser construído.

Se está trabalhando com web, você utiliza o react-dom e elementos HTML como div e span; se está criando algo mobile, React Native e e suas tags serão Views. CLI? É aí que entra o ink - e vale comentar: não se trata de uma versão adaptada ou menor do React.

Veja um exemplo:

import { Box, Text } from 'ink';

export const Banner = (props: { name: string, version: string, cwd: string }) => {

  const ORANGE_COLOR = "#FE9900";

  return (
    <Box 
      borderStyle="round" 
      paddingX={1} 
      borderColor={ORANGE_COLOR}  
      flexDirection="column"
    >
      <Box paddingBottom={1}>
        <Text bold color={ORANGE_COLOR}>React + Ink Example Application</Text>
      </Box>
      <Text>cwd: {props.cwd}</Text>
      <Text>{props.name}</Text>
      <Text>version: {props.version}</Text>
    </Box>
  )
};

Construindo a aplicação

Vamos começar da forma mais direta possível: qual é o mínimo necessário para executar algo com Ink?

Bem, você certamente vai precisar de um projeto javascript/jsx (e typescript, nesse caso), o que implica em ter um sistema de build com todas as etapas configuradas - a magia que o create-react-app e seus sucessores entregam em um único comando.

Felizmente, estamos em 2025. Isso significa que o 7x1 foi há 11 anos, mas também que o bun, que resolve tudo de forma simples e performática, pode ser utilizado. Com efeito, executando:

bun init -y

Temos o esqueleto do projeto:

.
├── bun.lock
├── index.ts
├── package.json
├── README.md
└── tsconfig.json

A partir disso, alguns itens precisam ser ajustados para que o build funcione corretamente no caso de uma aplicação CLI:

Instalar dependências do React/Ink.
Definir um (ou mais) caminhos de execução, através da chave bin;
Definir quais arquivos serão utilizados para gerar o pacote npm durante a fase de publicação;

Dependências

É necessário instalar, além de ink e react, alguns pacotes para escrita de testes unitários (ink-testing-library) e as respectivas definições de tipo. Também utilizaremos o rimraf, para permitir limpar arquivos de build no futuro:

bun i ink react@18

bun i -D @types/{ink,ink-testing-library,react} ink-testing-library rimraf react-devtools-core

Configurações

Crie um arquivo bin.js com o seguinte conteúdo:

#!/bin/env node
import('./dist/bundle.js');

Após isso, marque o arquivo como executável, o que pode ser feito em sistemas unix por meio do chmod:

chmod +x bin.js

Ajuste o package.json, adicionando o nome do executável e os arquivos do build:

{
  "bin": {
    "ink-cli-app": "./bin.js"
  },
  "files": [
    "dist",
    "bin.js"
  ]
}

Também inclua alguns scripts para build, test e execução da aplicação:

{
 "scripts": {
   "clear": "rimraf dist",
   "test": "FORCE_COLOR=0 NODE_ENV=test bun test",
   "build": "bun run clear && bun build src/application.tsx --outfile=./dist/bundle.js --target=node --format=esm --minify",
   "start": "node ./bin.js",
   "start:dev": "bun ./src/application.tsx",
   "prepublishOnly": "bun run build",
 }
}

Remova o arquivo index.ts e crie uma nova pasta src, com o arquivo application.tsx:

import { exit } from 'process';
import { Box, render, Text } from 'ink';
import pkg from '../package.json';

type ApplicationProps = {
  name: string;
  version: string;
}

export const Application = ({ name, version }: ApplicationProps) => {
  const ORANGE_COLOR = "#FE9900";

  return (
    <Box width={80} paddingX={1} flexDirection="column">
      <Box 
        borderStyle="round" 
        paddingX={1} 
        borderColor={ORANGE_COLOR}  
        flexDirection="column"
      >
        <Box paddingBottom={1}>
          <Text bold color={ORANGE_COLOR}>React + Ink Example Application</Text>
        </Box>
        <Text>{name}</Text>
        <Text>version: {version}</Text>
      </Box>
    </Box>
  )
}

try {
  const { waitUntilExit } = render(
    <Application 
      name={pkg.name}
      version={pkg.version}
    />
  )
  await waitUntilExit();
} catch(error) {
  console.error({ status: 'app exited with error', error });
  exit(1);
}

Por fim, basta executar os scripts build e start para ter a aplicação funcionando:

Conclusão

A partir desse ponto, não existe mais nada muito específico do ink: você pode utilizar o que já conhece de react para construir a aplicação.

Talvez seja útil dar um passo atrás e ler este guideline sobre como criar aplicações CLI com qualidade (escrito por autores de ferramentas populares, como docker compose).

Um outro componente que pode ser útil é um parser para os argumentos, bem como geração de documentação (o famoso --help). Uma das soluções mais completas é o Commander, que abstrai grande parte desse trabalho.

Dynamodb em aplicações node

Romildo Junior — Sun, 02 Mar 2025 16:16:36 +0000

Recentemente, voltei a precisar utilizar dynamodb como base de dados em algumas aplicações. Há alguns anos, a abordagem mais simples que tinha encontrado, até mesmo por já possuir algum contato com mongodb, foi por meio do Dynamoose - que sim, é uma ferramenta fortemente inspirada no Mongoose, como o nome sugere.

Antes de partir para o que já era conhecido, decidi testar a sdk padrão da aws e cheguei a algo interessante, então vou deixar registrado por aqui.

Overview do DynamoDB

O dynamodb é um banco de dados não relacional, baseado em tabelas. É bem similar ao scylla/cassandra, no sentido de que a parte mais importante da modelagem é escolher bem as chaves da tabela.

Nesse caso, podem existir até duas chaves (algo que não é o caso no scylla): uma chave de partição (hash key) e outra chave de ordenação (sort key). Esses dois valores, além das configurações de capacidade para escrita e leitura e o próprio nome, são os únicos requisitos ao criar uma tabela.

Como a figura abaixo ilustra, a chave de partição pode ser ambigua, quando for utilizada em conjunto com a chave de odernação. Isso permite, por exemplo, filtrar todos os valores do estado de PE de forma performática (caso você precise de mais do que dois filtros, é necessário criar um índice secundário)

O restante dos dados não precisam ser definidos de forma rígida (a famosa magia do NoSQL), o que também traz a necessidade de verificar se o registro na base possui o formato esperado antes de utilizá-lo.

Por fim, os custos são definidos a partir da leitura (Read Capacity Unit, RCU) e escrita (Write Capacity Unit, WCU), com algumas pequenas variações relacionadas a provisionamento automático e consistência das operações.

Você pode ver os preços na página dynamodb: preços, bem como uma descrição de como as unidades são utilizadas em Capacity unit consumption for read operations (documentação da aws)

Um setup mínimo

A forma mais simples de subir um projeto é utilizar a propria SDK da aws, em conjunto com a versão local (para desenvolvimento) do dynamodb.

A SDK pode ser instalada a partir do npm:

npm i @aws-sdk/client-dynamodb

Para o segundo item, recomendo o instructure/dynamo-local-admin-docker. Os autores do repositório disponibilizaram uma imagem docker com dynamodb-local e dynamoadmin, facilitando bastante o setup:

docker run -p 8000:8000 -it instructure/dynamo-local-admin

caso você queira persistir os dados após finalizar o container, é necessário utilizar volumes

No caso da minha aplicação, utilizei o fastify e o suporte nativo para typescript e execução de testes, disponível nas versões mais recentes do node. O projeto base pode ser obtida em jrmmendes/fastify-ts

Tendo um projeto como base, a inicialização pode ser feita com a classe DynamoDBClient:

import { DynamoDBClient } from "@aws-sdk/client-dynamodb";

const client = new DynamoDBClient({
  endpoint: "http://localhost:8000",
  region: "localhost",
  credentials: {
    accessKeyId: "fakeMyKeyId",
    secretAccessKey: "fakeSecretAccessKey",
  },
})

Em que utilizei os parâmetros necessários para uso local (em especial, endpoint). Dependendo da forma como a sua aplicação lida com acesso à AWS, esses valores são dispensáveis.

A SDK disponibiliza também uma série da classes, correspondentes às operações possíveis, que seguem o padrão *Command (e.g. QueryCommand, PutItemCommand, etc).

Uma dúvida comum está relacionada a dois comandos em particular: Query e Scan, uma vez que ambos permitem ler dados da base. Esse tópico sozinho já poderia render um novo artigo, mas trazendo de forma breve, as operações de Query sempre são mais eficientes (e baratas), uma vez que usam as chaves de hash e partição para reduzir a quantidade de dados consultados de forma performática.

Caso queira se aprofundar nesse tema, recomendo ler Dynamodb Scan vs Query (por Dynabase) e Best practices for querying and scanning data in DynamoDB (documentação da aws),

Exemplo mais estruturado

Para ter uma visão de como isso fica na prática, vamos construir uma API de listagem, que obtem uma lista de preferências do usuário. Cada preferência terá o seguinte formato:

class Preference {
  name: string;
  value: string | boolean | number;
}

Outro ponto é que ela precisa ser atrelada a um usuário (por meio do seu ID) e uma plataforma (android, ios, web).

A partir disso, é possível criar a tabela preferences-db, com o seguinte conteúdo:

hash key: userId - id do usuário
sort key: platform - android, ios, web

E adicionar um item que possua a propriedade preferences (array de objetos do tipo UserPreference:

Esses dados podem, então, ser obtidos dentro da aplicação:

const command = new QueryCommand({
  TableName: "preferences-db",
  KeyConditionExpression: ":userId = userId AND :platform = platform",
  ExpressionAttributeValues: {
    ":userId": { S: "123" }, 
    ":platform": { S: "web" },
  },
});

// os items retornados estarão em `response.Items`
const response = await this.client.send(command)

Validação e formato dos dados

Caso você execute uma query diretamente, como no exemplo, vai perceber que o valor do response.Items é do tipo Record<string, AttributeValue>. Em outras palavras, o resultado será algo como o seguinte:

{
  "preferences": {
    "L": [{
      "M": {
        "name": { "S": "theme" },
        "value": { "S": "dark" }
      }
    }]
  }
}

Em que todos os atributos são opicionais. Isso torna necessário realizar algumas verificações, para garantir que a aplicação não quebre ao tentar acessar algum dado.

Uma forma de resolver ambos os problemas (interpretar e validar os resultados) é definir um schema centralizado, uma ideia bem próxima ao que o dynamoose utiliza:

//schema.ts
export type Schema<T> = {
  table: string,
  keys: {
    hash: string,
    range: string,
  },
  parse: (items: Record<string, AttributeValue>[])=> T[]
}

Seria possível ter, então, o seguinte schema para as preferências:

//preferences.schema.ts
const validate = (preference: any) => {
  return preference?.M?.name?.S && preference.M?.value ;
};

export const PreferencesSchema: Schema<Preference> = {
  table: "preferences",
  keys: {
    hash: "userId",
    range: "platform"
  },
  parse: (items: Record<string, AttributeValue>[]): Preference[] => {
    baseLogger.info(items);
    return items
      .filter((item) => item.preferences?.L)
      .flatMap((item) => item.preferences.L)
      .filter((pref) => !!pref?.M)
      .filter(validate)
      .map(
        (preference) =>
          new Preference({
            name: preference.M.name.S!,
            value: preference.M.value.BOOL!,
          }),
      );
  },
};

Em que Preference é uma classe que criamos para manipular dentro da aplicação.

O fato de ter essa abstração (schema), permite que exista uma implementação unica para acesso ao banco de dados, independente da tabela, chaves e tipos de dados retornados:

export class DynamodbAdapter<Result> {
  client: DynamoDBClient;
  schema: Schema<Result>;

  constructor(schema: Schema<Result>) {
    this.schema = schema;
    this.client = new DynamoDBClient({
      endpoint: "http://localhost:8000",
      region: "localhost",
      credentials: {
        accessKeyId: "fakeMyKeyId",
        secretAccessKey: "fakeSecretAccessKey",
      },
    });
  }

  async listByKey(
    keys: Record<string, string>,
  ): Promise<Result[]> {
    const hasHashKey = Object.keys(keys).includes(this.schema.keys.hash);
    const hasRangeKey = Object.keys(keys).includes(this.schema.keys.range);

    const hashKey = this.schema.keys.hash;
    const rangeKey = this.schema.keys.range;

    if (!hasHashKey) {
      throw new Error("You must provide the hash key");
    }

    const condition =
      `:${hashKey} = ${hashKey}` +
      (hasRangeKey ? ` AND :${rangeKey} = ${rangeKey}` : "");

    const attributes = {
      [`:${hashKey}`]: { S: keys[hashKey] },
    };

    if (hasRangeKey) attributes[`:${rangeKey}`] = { S: keys[rangeKey] };

    const command = new QueryCommand({
      TableName: this.schema.table,
      KeyConditionExpression: condition,
      ExpressionAttributeValues: attributes,
    });

    const response = await this.client.send(command);

    if (!response?.Items) return [];

    return this.schema.parse(response.Items);
  }
}

Que poderia ser utilizado de forma agnóstica em um repository, por exemplo:

export class DynamodbPreferencesRepository implements PreferencesRepository {
  adapter: DynamodbAdapter<Preference>;

  constructor(adapter: DynamodbAdapter<Preference>) {
    this.adapter = adapter;
  }

  async getConsultantPreferences(params: {
    userId: string;
    platform: string;
  }): Promise<Preference[]> {
    return this.adapter.listByKey({
      userId: params.userId:,
      platform: params.platform,
    });
  }
}

const repository = new DynamodbPreferencesRepository(
  new DynamodbAdapter(PreferencesSchema),
);

//... em algum handler/service
const preferences = await repository.getConsultantPreferences({
  platform: "web",
  userId: "123"
});

Conclusão

Utilizar nosql é sempre uma experiência específica, uma vez que cada implementação possui seus proprios objetivos e particularidades. Um outro ponto que sempre acaba sendo relevante é como resolver a interpretação desses dados, bem como a definição de tipos, uma vez que não existem garantias sobre o formato dos dados - e dai surgem problemas, como o famoso Cannot read properties of undefined.

Nesse artigo trago uma possibilidade, fortemente inspirada no que algumas bibliotecas padrão fazem, bem como uma visão gerão de algumas particularidades do dynamodb, para os que estão fazendo aplicações simples. Em futuros artigos, devo abordar mais o uso do dynamoose, uma vez que ele resolve vários dos problemas comentados.

Test data builders em Typescript

Romildo Junior — Tue, 18 Feb 2025 00:32:34 +0000

Há alguns meses, tenho tido um problema cada vez maior: gerar objetos para testes unitários. Isso certamente começou como algo irrelevante, mas quando se possui um repositório com algumas dezenas de endpoints e uma suite que tende a ser mais refinada (em relação a ter uma variedade de casos de sucesso e erro), um tempo precioso tem que ser gasto após alguns ciclos de desenvolvimento para organizar a bagunça.

Vejamos um exemplo:

const TestDefaults = {
    structure: {
        code: 12342,
        name: 'Setor Norte',
    },
    country: 'BR',
    user: {
        name: 'Mendes',
        registerNumber: 12554,
        experienceInYears: 32,
        birthdayIsoDate: '15/02/1999T00:02:00.000Z'
    }
}

Esse objeto é a forma mais simples que encontrei para ter esse setup nos meus testes:

import { GetUserUseCase, Repository, User } from '@domain/user'

describe('User Domain -> Unit Tests', () => {
  const TestDefaults = {...}

    it('when repository has data, expect users without changes', () => {
        const user = new User(TestDefaults.user);
        const useCase = new UseCase(new Repository({ mocks: [user] }));

        const result = useCase.execute(TestDefaults.country);

        expect(result).toMatchObject([user])
    })  
})

Funciona, correto? Simples, direto. Apenas um objeto javascript, sem mais boilerplate. Que tal adicionar mais alguns casos?

import { GetUserUseCase, Repository, User } from '@domain/user'

describe('User Domain -> Unit Tests', () => {
    const TestDefaults = {...}

    it('when data from repository, expect users without changes', () => {...}

    it('when data without register, expect users with draft flag', () => {
        const user = new User({
            ...TestDefaults.user
            registerNumber: null,
        });
        const useCase = new UseCase(new Repository({ mocks: [user] }));

        const [user] = useCase.execute(TestDefaults.country);

        expect(user.isDraft).toBe(true);
    });
})

Um caso envolvendo outra classe, que utiliza a primeira:

import { GetUserUseCase, GetStructureUseCase, Repository, User, Structure } from '@domain/user'

describe('User Domain -> Unit Tests', () => {
    const TestDefaults = {...}

    describe('GetUserUseCase', () => {
        it('When data from repository, expect users without changes', () => {...});
        it('When data without register, expect users with draft flag', () => {...});
    })

    describe('GetStructureUseCase', () => {
        it('When structure with leader and members, expect only non-draft users and correct structure entity', () => {
            // hmmmm
        })
    })
})

E agora?

O problema

Criar dados para testes unitários é fácil durante o início. Alguns objetos, spreads, um pouco de javascript, tudo certo. Durante um bom tempo, é o que precisa mesmo. Eis, então, as duas coisas que eu diria para você ter em mente:

os testes unitários precisam conter toda a informação para entender o setup dos dados, a forma de execução e as validações (o famoso padrão AAA: Arange, Act, Assert);
passar muito tempo criando objetos para validar as unidades vai se tornar algo custoso com o tempo (e provavelmente serão dados bem viciados)

Quando um arquivo de testes passar a ter dezenas de casos, centenas de linhas, essa falta de controle irá impactar ainda mais.

Um padrão

Se você chegou aqui, certamente sente isso que comentei: como consigo resolver esse problema? Será que alguém já fez? Foi assim que descobri um padrãozinho bem simples, os test data builders - que na verdade é o bom e velho builder.

Primeiro comecei a pesquisar em alguns lugares sobre, dos quais indico o artigo do Robson Castilho, Test Data Builders: você está usando corretamente?. Ele coloca link para mais referências e já apresenta uma visão mais qualitativa da coisa, que pode ser util caso você queira mesmo usar esse padrão. Também foi bastante útil o que está no repositório devfullcycle/test-data-builder, escrito em typescript (serviu de base para a minha implementação).

No fim, criei uma versão mais compacta, que parte da seguinte classe abstrata:

type FactoryOrValue<T> = T | (() => T);
type TargetConstructor<T> = new(...args: any[]) => T;

export abstract class TestDataBuilder<Target> {
  protected customValues: { [key: string]: FactoryOrValue<any> } = {};
  protected propertyNames: string[]
  protected readonly cls: TargetConstructor<Target>;
  protected readonly defaultValues: { [key: string]: FactoryOrValue<any> };

  protected constructor(params: {
    cls: TargetConstructor<Target>,
    props: { [key: string]: FactoryOrValue<any> },
  }) {
    this.defaultValues = params.props;
    this.cls = params.cls;
    this.propertyNames = Object.keys(params.props);
  }

  build(): Target {
    return new this.cls(this.propertyNames.reduce((prev, cur) => ({
      ...prev,
      [cur]: this.generate(cur)
    }), {}) as any);
  }

  protected clean() {
    this.customValues = {};
    return this;
  }

  withCustomAttribute(key: string, value: unknown) {
    this.customValues[key] = value;
    return this;
  }

  protected generate(key: string): any {
    const factoryOrValue = this.customValues[key] ?? this.defaultValues[key];

    if (typeof factoryOrValue === "function") {
      return factoryOrValue();
    }

    return factoryOrValue;
  }
}

Em que, no projeto que estou, utilizamos uma convenção: ter todas as propriedades da entidade em um objeto props, similar ao seguinte:

abstract class Entity<Props, PlainObject> {
    props: Props;
    serialize(): PlainObject;
}

O que significa tudo isso?

O primeiro ponto são os tipos auxiliares. FactoryOrValue se trata do tipo de mock. A ideia é que cada campo será configurado para ter um valor padrão, que pode ser um valor fixo ou uma função (como chance.string(), por exemplo, ou qualquer gerador de dados aleatórios).

type FactoryOrValue<T> = T | (() => T);
type TargetConstructor<T> = new(...args: any[]) => T;

TargetConstructor já é algo um pouco menos ortodoxo: um construtor. Isso será util, pois permite que o builder receba a classe de entidade com um parâmetro e crie instâncias (similar ao que o class-transformer permite através da função plainToInstance).

O segundo conceito importante está relacionado aos objetos defaultValues e customValues. Eles serão utilizados no método generate, para conseguir resolver cada campo da entidade:

protected generate(key: string): any {
    const factoryOrValue = this.customValues[key] ?? this.defaultValues[key];

    if (typeof factoryOrValue === "function") {
      return factoryOrValue();
    }

    return factoryOrValue;
}

Em que os valores padrões são passados no construtor e os valores customizados podem ser informados pelo método withCustomAttribute:

withCustomAttribute(key: string, value: unknown) {
    this.customValues[key] = value;
    return this;
}

Como existe um atributo sendo manipulado, uma escolha foi ter o método clean. Em alguns momentos, ter um objeto customValues que pode ser reutilizado é interessante (como mostrarei mais a frente).

 protected clean() {
    this.customValues = {};
    return this;
}

O ultimo método, que também é o ultimo da cadeira, é o build. Ele consegue ser totalmente genérico graças a uma série de convenções:

Todas as entidades possuem um objeto props;
Os objetos defaultValues e customValues seguem o formato do objeto props;
O construtor da classe, do tipo TargetConstructor, é repassado como parâmetro;

O uso do reduce, que geralmente assusta um pouco, se deve ao objetivo de converter uma lista de propriedade num objeto, o que encaixa perfeitamente. No fim, ele apenas itera entre as chaves das props, utilizando a função ou valor que foi definido para gerar cada propriedade durante o processo.

build(): Target {
    return new this.cls(this.propertyNames.reduce((prev, cur) => ({
      ...prev,
      [cur]: this.generate(cur)
    }), {}) as any);
  }

Retornando ao exemplo

Agora é possível escrever o seguinte builder para a classe User:

class UserDataBuilder extends TestDataBuilder<User> {
    constructor() {
        super({
            cls: User,
            props: {
                name: () => chance.name(),
                registerNumber: () => chance.integer(),
                experienceInYears: () => chance.integer({ min: 18, max: 30 }),
                birthdayIsoDate: '15/02/1999T00:02:00.000Z',
            }
        })
    }
}

E reescrever os testes:

import { GetUserUseCase, Repository, User } from '@domain/user'

describe('User Domain -> Unit Tests', () => {
    const country = 'BR';
    const userBuilder = new UserDataBuilder();

    it('when repository has data, expect users without changes', () => {
        const user = userBuilder.build();
        const useCase = new UseCase(new Repository({ mocks: [user] }));

        const result = useCase.execute();

        expect(result).toMatchObject([user])
    })  
})

Para as variações nos dados, basta incluir alguns métodos derivados do withCustomAttribute:

class UserDataBuilder extends TestDataBuilder<User> {
    constructor() {...}

    aUserWithoutRegisterNumber() {
        return this.withCustomAttribute('registerNumnber', null).build()
    }   
}

...

it('when data without register, expect users with draft flag', () => {
    const user = userBuilder.aUserWithoutRegisterNumber();
    const useCase = new UseCase(new Repository({ mocks: [user] }));

    const [user] = useCase.execute(TestDefaults.country);

    expect(user.isDraft).toBe(true);
});

O que também se aplica ao ultimo teste, que combina essa ideia:

it('When structure with leader and members, expect only non-draft users and correct structure entity', () => {
    const leader = userBuilder.withExperienceInYears(20).build();

    const draftUser = userBuilder.aUserWithoutRegisterNumber();
    const user = userBuilder.withExperienceInYears(3).build();

    const members = [
        draftUser, 
        user,
    ];

    const structure = structureBuilder
        .withLeader(leader)
        .withName('Setor Norte')
        .withCode(123)
        .withMembers(members)
        .build();

    const getStructureUseCase = new GetStructureUseCase(new StructureRepository({ mocks: [structure] }))

    const result = getStructureUseCase.execute({ country: 'BR' });

    expect(result.leader).toBe(leader);
    expect(result.members.length).toBe(1);
    expect(result.members[0]).toBe(user);
})

Conclusão

Com os Test Data Builders, criar mocks passa a ser algo mais expressivo, permitindo reutilizar a lógica com mais segurança do que alguns padrões de nomes e combinação de objetos permitiria. Quando existem diversas pessoas mantendo uma base de código, esse passo será útil na manutenção de uma padronização, em que todo mock precisa ter um "nome" (a partir do método criado no builder).

Gostou do tema ou quer compartilhar algum relato? Deixe um comentário no bluesky!

Starting the Gaia console web front-end and BFF

Romildo Junior — Wed, 23 Oct 2024 00:00:03 +0000

In this post, I'll introduce the first component of the Rainbow Platform. If you’ve just found this article, check out the original idea explained here. If you're here for the code, you can access it on mjsdevs/rainbow on GitHub.

To begin, it's worth taking a look at the first draft for Gaia. Just to recap from the last post, it will have three major components:

Console – gaia.console: the "AWS Console"-like front-end, built with React and TypeScript.
Registry – gaia.registry: the function registry, acting as a custom package registry (as the name suggests).
Proxy – gaia.proxy: the gateway for active functions (more on this concept will be covered later).

Gaia will be built with TypeScript and tRPC, following the microkernel architecture. Given this choice, it's natural to use a single monorepo for the UI, BFF, and all the modules as well.

Gaia Console Web

To build the admin, I’ve chosen to use a standalone React SPA. Since Gaia modules will be accessible through different clients (CLI, console, chatbot, etc.), each client must implement its own BFF, also using tRPC.

This is the first mockup of the admin page, which currently includes the only available feature: managing the function registry.

Why tRPC?

I’ve used both GraphQL and REST in the past. From json:api to Relay, each approach for building APIs has its pros and cons. However, a constant challenge is choosing between code-first and schema-first approaches.

Take GraphQL as an example—REST APIs have a similar challenge, often using something like OpenAPI as the "schema." If you want your code to be the source of truth, you can use something like TypeGraphQL, which generates the GraphQL schema based on decorators in your classes. On the other hand, you can use the reference GraphQL server implementation (graphql-js) with raw Schema Definition Files as your contract—then generate TypeScript types using something like GraphQL Codegen.

In both scenarios, you have to add complexity to your toolchain by "extracting" types. In other words, you either generate interfaces from your schema or build a dynamic schema (a language-agnostic interface) from your code.

This is fine if you have a Java backend and an iOS app, but with TypeScript, the goal is to share the same interfaces and types between front-end and back-end. So why not use the language itself? That's the use case for tRPC.

The general idea of using tRPC is simple: build your server with the @trpc/server package, export the TypeScript interface to the front-end application, and consume it using @trpc/client. No schema or JSON format conventions—you just focus on the code, and it integrates through the language itself. In this case, where we are building both the web application and its BFF using a monorepo structure, tRPC is the perfect fit.

Using tRPC feels like a hybrid approach, combining the best of both GraphQL (with queries and mutations) and REST concepts. It also significantly improves developer experience (DX) for full-stack development.

Monorepo

The monorepo structure is another topic that could fill an entire article, but I’ll give a brief explanation.

Instead of having one repository per project, we use a single repository for all the source code. This choice leads to some interesting questions:

How do you manage dependencies and build workflows?
What can be reused between projects (if anything)?

For dependency and workflow management in Gaia, we can use any tool available in the Node ecosystem. You might suggest Lerna or even Turborepo. For our needs, the default npm workspaces will suffice.

As for reusability, it mainly involves using tRPC across all components.

In the upcoming posts, I'll dive into the front-end application itself (gaia.console.web). Spoiler: it will be based on Cloudscape, the design system currently used by AWS.

Building my own Zero Dawn platform

Romildo Junior — Fri, 18 Oct 2024 09:38:15 +0000

WARNING: THIS POST CONTAINS MINOR SPOILERS TO THE ORIGINAL HORIZON GAME.

Some weeks ago, I started thinking about bots due to the Brazilian software developers' community migration from X to Bluesky. This was motivated by the flexibility of the platform, which gives back that good old feeling of "you can create your own Jarvis if you know how."

At first, my idea was to create a lot of bots: a thread "unroller" (which would build a markdown page with all posts from a given thread), maybe a Pocket-like bookmark helper, etc. However, soon the "big picture" popped into my mind: what about making a whole ecosystem of bots? Something like Gaia and the subordinate functions from Horizon Zero Dawn? Here's the original "blueet" at Bluesky (in pt-BR):

[1/N] Eis a ideia número #2, que vou começar a pensar como fazer: um ecossistema de bots, bem inspirado (pra não dizer parodia) em Horizon zero dawn. O próximo posto que vou fazer disso vai ser literalmente um teste em prod, mas vou deixar aqui como tô matutando essa parada:
— Mendes (@mendes.software) September 7, 2024 at 10:28 AM

That's how the idea of the Rainbow Platform started.

The Concept (So Far)

Even though it all started with bots and Bluesky, the overall concept is broader: a complete ecosystem based on Microkernel Architecture that can be plugged into any platform with social interaction and some bot SDK (e.g., Slack, Discord, Bsky, Telegram). This platform would have some "global back-office," something close to the AWS Console. The core functionalities would include user interface (chat, LLM, CLI), moderation (abuse reporting, spam control), connection with the platforms (i.e., SDK adapters), and extensibility itself.

The Lore

Horizon Zero Dawn is one of the greatest games of the last 10 years, mostly due to its brand new "tech post-apocalyptic" world. You can read about Zero Dawn at the fandom page, but I'll give you some TL;DR bullet points (spoiler alert):

The world is ending (a.k.a. Skynet has been created).
The best engineers and specialists alive are reunited to create the "good Skynet" to fight for us.
This good AI is called "Zero Dawn" and has several modules, which include:
- Minerva, which has control over all the global communication infrastructure.
- Apolo, which stores all the knowledge generated by humanity (the database of databases);
- Hades, which has the ability to reboot the Earth through volcanic eruptions and earthquakes when necessary;
- Gaia, the "brain" that controls everything and has the ability to understand human feelings—at least, it can communicate in natural language, similar to the current hype around LLMs.

First scope

The platform will be called Rainbow - beacuse theres more in the sky than blue. Bluesky. Yep, thats the reason.

The initial modules will be

Minerva (with Bluesky and Discord adapters),
Hades (with basic moderation tools for spam and moderation)
Gaia (which includes the core microkernel architecture implementation concepts, a chatbot, a proxy to other functions and some nice admin UI)

With Apolo being the first "feature based" function, that will be added latter.

All the progress will be updated through my dev.to blog, and the code open-sourced at mjsdevs github.

Let me know if you have any ideas about the tech stack that could fit each need (I'll probably start with Deno/ts/React for Gaia and Golang for the other services, but that's for another post). You can reach-me on Bluesky (@mendes.software).

Thanks for reading!

Entendendo arquitetura de software #0

Romildo Junior — Tue, 01 Mar 2022 23:31:23 +0000

Durante alguns anos estive envolvido com o desenvolvimento de software, em especial infraestrutura e back-end. Mesmo já tendo a oportunidade de trabalhar no desenvolvimento de aplicações front-end com e sem frameworks (sim, eu já usei HTML, CSS e JS puros e não faz mais que 2 anos), todo o processo que envolve, desde definir os recursos de cloud computing que serão usados, até encontrar uma stack que cumpre os requisitos e por fim tornar real com uma boa implementação sempre me trouxe um nível de empolgação maior. Criar a funcionalidade por debaixo dos panos sempre foi mais interessante.

Nesse tempo, eu considerei que o papel de um arquiteto de software não seria necessário. Seria apenas um nível de hierarquia. De fato, isso pode ser uma realidade em alguns projetos, mas foi trabalhando em um bom time que entendi o principal desafio de um software complexo: manter a consistência e permitir evolução.

Antes de mais nada, explico melhor o motivo de dizer isso. Trabalhei em uma equipe que possuía pessoas com experiência, além de proativas e responsáveis. Com parceria e profissionalismo bem além da média, diversos problemas de comunicação eram facilmente solucionados, quando eventualmente existiam. O que de fato trazia problemas? APIs de outras frentes que não estavam bem documentadas. Soluções que eram complicadas de entender (e aqui não falo sobre complexidade, pois são coisas diferentes). Falta de uma linguagem única. Tudo isso forçava o time a usar de sua bagagem para suprir essa deficiência, mas era como um peso a ser carregado.

Um outro ponto é que as decisões não estavam organizadas. Não foi criada documentação para diversos itens - nada além dos registros nos chats. Cabe dizer que, se você pensa que isso tem algo a ver com agilidade, lembre-se: ter um software funcionando não exclui documentar minimamente o que for primordial.

Nesse meio tempo, comecei a procurar entender o motivo de existir um arquiteto de software. O primeiro gatilho surgiu ao tentar responder um provocação de um colega de trabalho: como iniciar um projeto? Como definir uma estrutura que escala? Como converter entendimento de negócio em algo que traga orientação para as pessoas que ficarão responsáveis por implementar e quais as técnicas que podem ser utilizadas para isso?

Bem, essas são algumas das atribuições que um arquiteto de software pode ter. Seja isso uma posição ou papel dentro do time, ter alguém que tome decisões e olhe para aspectos de médio e longo prazo pode ser essencial para o sucesso do projeto.

Esse é um caminho que decidi trilhar: melhorar o meu entendimento sobre arquitetura de software. Dessa forma, será através dessa série de artigos, com fim ainda indefinido, que irei registrar meu progresso. Serão textos curtos, mas que formam uma sequência útil para outras pessoas que estejam partindo desse mesmo lugar.

--
Tem alguma sugestão ou comentário? Parte fundamental de aprender é a troca de experiências, então deixa um comentário e vamos tornar, esse, um espaço para crescer!

Making a dead simple configuration service with Typescript

Romildo Junior — Mon, 07 Jun 2021 20:11:41 +0000

If you're working with NodeJS applications, you probably has process.env.VARIABLE statements all around your code base. The most simple method to configure an application is installing dotenv and creating that lovely .env file on the root folder of your project.

This approach, however, has some pitfalls and is error prone. What if you don't set that process.env port? You'll probably have a default value (maybe 3000?), but you will need to run your application to discover such type of thing.

That same problem has been solved by typescript for almost anything. When you have the help of static typing, you can discover some errors a lot faster. That said, how can you use Typescript to have a type-safe way to access configurations?

Show me the code!

Take a look at that short snippet:

export class EnvironmentService<Environment> {

  public constructor(
   private readonly variables: Environment
  ) {
    // some logic to assign process.env to this.variables
    // you can use, for instance, 
    this.variables = Joi.attempt<Environment>(process.env))
  }

  public get<T>(name: keyof Environment) {
    return <T><unknown>this.variables[name];
  }
}

In a nutshell,

First, you need to define an interface for you environment;
Then, you do pass it as a type parameter to the EnvironmentService class when instantiating a new object;
Finally, use something like class-validator, Joi or you library of choice to assert if the process.env object has all required variables and assign its value to the variables attribute;

After those simple steps, you can use the method get to fetch all possible environment variables with the help of typescript to guide your choice - and if you need, you can cast the value to some desired type:

Conclusion

That's all folks! If you liked that simple content, don't forget to comment and share with someone you might help. Also, that's my first attempt to write something in english: if you see something wrong, just message me on Twitter (@dotmendes).

References

Typescript Handbook: Keyof

Minio como alternativa ao S3 em aplicações Node

Romildo Junior — Thu, 11 Jun 2020 22:13:14 +0000

A facilidade em criar buckets e enviar arquivos para o S3 da Amazon é algo fantástico. Armazenar objetos, ao invés de ter um sistema de arquivos, diminui a complexidade e traz uma eficiência à esse tipo de operação.

Um dos problemas da Amazon é o seu valor. Em projetos menores, que não se beneficiam da grande disponibilidade da plataforma, é comum adotar - pelo menos para hospedar a aplicação - a Digital Ocean. Nesse artigo, vamos utilizar uma "s3 própria" por meio do Minio em uma API básica para upload de arquivos, feita com Node.js e Javascript.

Curte uma trilha sonora? Eu fiz esse artigo ouvindo essa playlist no spotify.

O que é o Minio?

Segundo a própria documentação, o Minio é uma tecnologia de armazenamento baseada em objetos, de alta performance. Ele é escrito em Go e tem uma API compatível com o AWS S3.

Vale destacar a questão da compatibilidade. Como veremos, é possível até configurar o cliente do S3 da SDK para Javascript de modo que ele utilize, na verdade, o minio.

Criando a API

Aqui, suponho que você possua um projeto configurado para utilizar ES6 Modules - uma forma simples é por meio do Babel. Caso precise, utilize este template.

O primeiro passo é criar uma API para que possamos testar, no futuro, a funcionalidade. Utilizando express, teríamos algo assim:

import express from 'express';
import { S3 } from 'aws-sdk';
import cors from 'cors';
import morgan from 'morgan';

const app = express();
app.use(cors());
app.use(morgan('dev'));

app.listen(3000, () => console.log('[READY]'));

Depois disso, é necessário criar uma rota que trate o upload de arquivos individuais. Aqui faremos uso do Multer:

app.route('/upload').post(
  multer({ storage: multer.memoryStorage() }).single('file'),
  uploadHandler,
);

Upload Handler

É nessa função em que utilizamos a API da S3:

const uploadHandler = async (req, res) => {
  try {
    await s3.putObject({
      Bucket: 'tests',
      Key: req.file.originalname,
      Body: req.file.buffer,
    }).promise();
    return res
      .status(201)
      .send({
        message: `File "${req.file.originalname}" uploaded`
      });
  } catch (e) {
    console.log(e);
      return res
        .status(500)
        .send({ error: e.message })
  }
}

E assim criamos o objeto s3:

const s3 = new S3({
  endpoint: 'http://play.minio.io:9000',
  accessKeyId: 'Q3AM3UQ867SPQQA43P2F',
  secretAccessKey: 'zuf+tfteSlswRu7BJ86wekitnifILbZam1KYY3TG',
  sslEnabled: false,
  s3ForcePathStyle: true,
});

Nesse caso, as credenciais são para o servidor de testes do Minio.

Por que não usar a SDK do Minio para JS? Diga-se de passagem, por design, não existe muita diferença, mas aqui estou fazendo isso para mostrar como adaptar, sem basicamente nenhuma mudança na estrutura do projeto, o serviço utilizado. Isso também é útil para utilizar pacotes como o multer-s3.

Dessa forma, o código completo seria o seguinte:

import express from 'express';
import { S3 } from 'aws-sdk';
import cors from 'cors';
import morgan from 'morgan';

const s3 = new S3({
  endpoint: 'http://play.min.io:9000',
  accessKeyId: 'Q3AM3UQ867SPQQA43P2F',
  secretAccessKey: 'zuf+tfteSlswRu7BJ86wekitnifILbZam1KYY3TG',
  sslEnabled: false,
  s3ForcePathStyle: true,
});

const app = express();
app.use(cors());
app.use(morgan('dev'));

const uploadHandler = async (req, res) => {
  try {
    await s3.putObject({
      Bucket: 'tests',
      Key: req.file.originalname,
      Body: req.file.buffer,
    }).promise();
    return res
      .status(201)
      .send({
        message: `File "${req.file.originalname}" uploaded`
      });
  } catch (e) {
    console.log(e);
      return res
        .status(500)
        .send({ error: e.message })
  }
}

app.route('/upload').post(
  multer({ storage: multer.memoryStorage() }).single('file'),
  uploadHandler,
);

app.listen(3000, () => console.log('[READY]'));

Utilizando a API própria do Minio

Caso você não precise utilizar a API da S3, algumas alterações seriam necessárias. A primeira é a própria definição do objeto "s3". Poderíamos substituir pelo seguinte:

const minioClient = new Minio.Client({
    endPoint: 'play.min.io',
    port: 9000,
    useSSL: true,
    accessKey: 'Q3AM3UQ867SPQQA43P2F',
    secretKey: 'zuf+tfteSlswRu7BJ86wekitnifILbZam1KYY3TG'
});

A segunda seria na utilização desse cliente para realizar o upload, dentro da função uploadHandler, para a seguinte forma:

//...
await minioClient.putObject(
  'tests',
  req.file.originalname,
  req.file.buffer,
);

Considerações

Caso você execute o código criado, é possível realizar upload de arquivos por meio de requisições http para localhost:3000/upload utilizando multipart/form-data. O multer faz o trabalho pesado de modo que temos total acesso ao arquivo na memório (atravez do memoryStorage).

Dito isso, utilizamos a SDK da AWS da maneira convencional, contudo o objeto que nos dá acesso à API da S3 é criado com alguns parâmetros importantes - sobretudo o endpoint, que recebe a URL do servidor minio de interesse. Observe que quase nenhuma alteração é necessária, uma vez que o Minio foi estruturado para permitir esse tipo de compatibilidade.

Referências

Enviando SMS com Amazon SNS

Romildo Junior — Sat, 23 May 2020 21:44:44 +0000

Enviar mensagens de texto, mum mundo em que os celulares dominam, é uma das formas mais simples e usuais de confirmação para login ou registro. Embora implementar algo assim tenha cara de complexo - afinal, envolve telefonia móvel, tipos de rotas e coisas obscuras para o cidadão médio - veremos nesse artigo como lançar mão da AWS para isso, com o Simple Notification Service (SNS) e um pouco de Javascript.

O que eu espero

Que você já tenha uma familiaridade mínima com a AWS;
Que você tenha acesso à credenciais (access key id e secret access key) para uma conta na AWS com acesso a SNS.
Que você já tenha utilizado Node (e mais especificamente express).

Conceitos

Já percebeu que o número daquela mensagem de confirmação do Uber ou iFood é bem curto?

Esses números são os chamados short code. O seu número, por outro lado, é um exemplo de long code. E por que isso é importante?

Short codes são destinados à comunicação em massa, podendo enviar cerca de 100 mensagens por segundo. Os long codes, além de destinados para comunicação pessoal, podem enviar apenas uma mensagem por segundo (e quase sempre são identificados como spam).

Um segundo conceito importanté diz respeito ao tipo da mensagem. As mensagens promocionais (Promotional Messages) são otimizadas para reduzir custos. Quando se trata de algo não crítico, em que reenviar o conteúdo é aceitável, esse é o tipo mais interessante. O outro se trata de mensagens transacionais (Transactional Messages), que são mais caras, mas garantem maior confiabilidade na entrega.

Codando um exemplo

Obs.: Por simplicidade, vamos omitir alguns passos relativos à segurança da aplicação durante o exemplo.

Vamos utilizar o express para construir uma API simples de envio de SMS e a própria sdk da AWS (aws-sdk) para ter acesso à plataforma.

TL;DR

O código abaixo resume como criar a API:

import express from 'express';
import AWS from 'aws-sdk';

// Função para envio da mensagem
async function sendSMS({ sns, Message, PhoneNumber }) {
  // Definições sobre o tipo de mensagem
  await this.sns.setSMSAttributes({
    attributes: {
      DefaultSMSType: 'Promotional'
    }
  }).promise();

  // Envio da mensagem
  sns.publish({
    Message,
    PhoneNumber, 
  }).promise();
}

// Configuração da SDK
const {
  AWS_ACCESS_KEY_ID: accessKeyId,
  AWS_SECRET_ACCESS_KEY: secretAccessKey,
 } = process.env;

AWS.config.update({
  region: 'us-east-1',
  accessKeyId,
  secretAccessKey,
});

const sns = new AWS.SNS({apiVersion: '2010-03-31'});

// Criação da API
const app = express();
app.use(express.json());
app.post('/send-sms', (req, res) => {
  const { PhoneNumber, Message } = req.body;
  sendSMS({ sns, PhoneNumber, Message });
  return res
    .status(201)
    .end();
});

app.listen(process.env.PORT || 3000);

Agora que tal ver isso em detalhes?

Configuração da SDK

Caso já tenha utilizado a SDK da AWS para javascript, essa é uma parte bem simples e sem mistérios. De todo modo, vale a pena explicar rapidamente o que é feito.

Ao trabalhar com os serviços da Amazon, é necessário ter, como dito no início, credenciais válidas - uma chave secreta e seu ID. Tendo isso em mãos, basta utilizar o método update dentro do pacote AWS.config:

AWS.config.update({
  region: 'us-east-1',
  accessKeyId,
  secretAccessKey,
});

Observe que existe também um parâmetro chamado "region". Ele se refere a qual região será escolhida para fornecer os serviços solicitados na aplicação, uma vez que a Amazon possui data-centers em diversos países. Nesse caso estamos utilizando a us-east-1, mas existem outras regiões compatíveis. [2]

Função `sendSMS`

Nessa função, implementamos a lógica para envio das mensagens. Ela espera receber um objeto sns, criado a partir da classe AWS.SNS, o número para envio e a mensagem.

await this.sns.setSMSAttributes({
    attributes: {
      DefaultSMSType: 'Promotional'
    }
  }).promise();

Definimos o tipo da que será enviada como "Promotional". Observe que o método setSMSAttributes por si utiliza um esquema de callbacks, mas pode ser facilmente convertido em promise utilizado o método promise em cadeia.

sns.publish({
    Message,
    PhoneNumber, 
  }).promise();

Para de fato enviar a mensagem, basta chamar o método publish. Novamente, observe que utilizamos o método promise, mas desta vez não bloqueamos a execução da aplicação pelo fato de não ser importante monitorar a entrega do SMS.

Criação da API

Tendo configurado a SDK e criado a função para enviar as mensagens de texto, resta construir uma API para a aplicação, o que é feito no ultimo trecho do código de exemplo:

const app = express();
app.use(express.json());
app.post('/send-sms', (req, res) => {
  const { PhoneNumber, Message } = req.body;
  sendSMS({ sns, PhoneNumber, Message });
  return res
    .status(201)
    .end();
});

Conclusão

Enviar SMS utilizando o Amazon SNS é uma tarefa simples, que pode ser feita sem muitas complicações. Contudo, é interessante estar atento aos custos (aprox. USD 0.02/sms no momento em que escrevo este artigo) e ao tipo de mensagem.

Gostou do artigo? Tem algum feedback? Quer sugerir algum tema? Deixa seu comentário e vamos trocar uma ideia. E claro, se acredita que mais alguem pode achar esse conteúdo relevante, não pense duas vezes antes de compartilhar.

Referências

[1] Why use a short code instead of a long code?

[2] Regiões e países compatíveis (SNS)

Forem: Romildo Junior

Práticas para projetos javascript robustos

O Javascript das Ruas

Um caso de estudo sobre utilização de Typescript

Erros como dados

Um exemplo um pouco mais complicado

Erros Transitórios

Policies na prática

Mas o que é null? É melhor ou pior que undefined?

Técnicas para lidar com valores nulos

Uma base estável

A passionate post about Neovim

Act 1: Chess

Act 2: Vinyl

The Encore: Mastery Through Challenge

Quais as melhores ferramentas para trabalhar com Node?

Package Managers

npm

bun

Lerna

Configuração de ambiente

nvm

Bundlers

esbuild

vite

tsup

Testes

jest

Apache jmeter

Stryker Mutator

Pact

Como criar uma CLI com React

TL;DR

Learn Once, Write Anywhere

Construindo a aplicação

Dependências

Configurações

Conclusão

Dynamodb em aplicações node

Overview do DynamoDB

Um setup mínimo

Exemplo mais estruturado

Validação e formato dos dados

Conclusão

Test data builders em Typescript

O problema

Um padrão

O que significa tudo isso?

Retornando ao exemplo

Conclusão

Starting the Gaia console web front-end and BFF

Gaia Console Web

Why tRPC?

Monorepo

Building my own Zero Dawn platform

The Concept (So Far)

The Lore

First scope

Entendendo arquitetura de software #0

Making a dead simple configuration service with Typescript

Show me the code!

Conclusion

References

Minio como alternativa ao S3 em aplicações Node

O que é o Minio?

Criando a API

Upload Handler

Utilizando a API própria do Minio

Considerações

Referências

Enviando SMS com Amazon SNS

O que eu espero

Conceitos

Codando um exemplo

TL;DR

Configuração da SDK

Função sendSMS

Criação da API

Conclusão

Referências

Função `sendSMS`