Forem: Eduardo Rabelo

Por que eu não uso bibliotecas de gerenciamento de estado no React

Eduardo Rabelo — Sat, 14 Dec 2024 01:18:44 +0000

Original source in English by Fabrizio Beccaceci
Why i no longer use a React state management library
https://medium.com/@ipla/why-i-no-longer-use-a-react-state-management-library-7bdffae54600

Índice

O que é uma Biblioteca de Gerenciamento de Estado Global?
Como o Redux Toolkit Resolve o Estado Global
As Duas Faces do Estado Global
A Abordagem Enxuta para Estado Global
- Para Estado do Servidor use TanStack Query
- Para Estado Compartilhado use Observables
Por que não usar React Context?
Conclusão

Quando comecei a aprender React anos atrs, havia duas coisas que voc precisava saber para se considerar um desenvolvedor React: TypeScript e Redux.

Hoje em dia, as coisas mudaram. Se voc est aprendendo React agora e se depara com o conceito de gerenciamento de estado, vai se sentir sobrecarregado com uma infinidade de bibliotecas: Redux, Redux Toolkit, MobX, Jotai, Zustand e a lista continua.

Mas antes de nos aprofundarmos, vamos responder pergunta bsica:

O que uma Biblioteca de Gerenciamento de Estado Global?

Mesmo se voc for relativamente novo no React, provavelmente sabe o que o termo estado. Voc cria um com o hook useState, e quando voc o atualiza, seu aplicativo renderiza novamente para refletir as mudanas.

No entanto, as coisas ficam complicadas quando voc precisa compartilhar alguma informao entre vrias partes no conectadas do seu aplicativo React.

Isso o que frequentemente chamamos de estado global , e o problema que as bibliotecas de gerenciamento de estado tentam resolver: como tornar o estado compartilhado acessvel a qualquer componente.

Vamos ver como o Redux Toolkit lida com isso.

Como o Redux Toolkit Resolve o Estado Global

Primeiro, voc cria uma store :

import { configureStore } from '@reduxjs/toolkit';

export const store = configureStore({
  reducer: {},
});

// Inferindo os tipos de RootState e AppDispatch usando a store
export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

Este o local central onde seu estado global ir existir. Em seguida, voc envolve seu aplicativo com um provider para tornar a store acessvel a todos os componentes:

import React from 'react';
import ReactDOM from 'react-dom';
import { Provider } from 'react-redux';
import App from './App';
import { store } from './app/store';

ReactDOM.render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById('root')
);

Agora, voc precisa definir os slices , que so partes individuais do seu estado global. Por exemplo:

import { createSlice } from '@reduxjs/toolkit';

interface CounterState {
  value: number;
}
const initialState: CounterState = { value: 0 };
export const counterSlice = createSlice({
  name: 'counter',
  initialState,
  reducers: {
    increment: (state) => { state.value += 1; },
    decrement: (state) => { state.value -= 1; },
    incrementByAmount: (state, action) => {
      state.value += action.payload;
    },
  },
});
export const { increment, decrement, incrementByAmount } = counterSlice.actions;
export default counterSlice.reducer;

Por fim, voc conecta este slicestore:

import { configureStore } from '@reduxjs/toolkit';
import counterReducer from './features/counter/counterSlice';

export const store = configureStore({
  reducer: { counter: counterReducer },
});

Neste ponto, voc pode usar seu estado global nos componentes da seguinte forma:

import React from 'react';
import { useSelector, useDispatch } from 'react-redux';
import { increment, decrement } from './counterSlice';

export function Counter() {
  const count = useSelector((state) => state.counter.value);
  const dispatch = useDispatch();
  return (
    <div>
      <button onClick={() => dispatch(increment())}>Increment</button>
      <span>{count}</span>
      <button onClick={() => dispatch(decrement())}>Decrement</button>
    </div>
  );
}

Embora o Redux Toolkit simplifique significativamente o Redux, ainda tem muito cdigo boilerplate para o que geralmente uma necessidade simples. E nem sequer falamos sobre aes assncronas como requisies ao servidor!

Alm disso, muitos iniciantes caem na armadilha de colocar todo o seu estado no Redux, levando a stores globais infladas que so mais difceis de gerenciar.

As Duas Faces do Estado Global

Quando voc para pra pensar, a maioria do "estado global" se enquadra em duas categorias:

Estado do Servidor : Dados obtidos de um servidor, como uma lista de clientes em um aplicativo CRM.
Estado da UI Compartilhado : Pequenos pedaos de dados necessrios em vrios lugares, como o usurio atualmente logado.

Vamos abordar cada um deles separadamente.

A Abordagem Enxuta para Estado Global

Com ferramentas modernas, voc pode lidar com estado global sem uma biblioteca dedicada de gerenciamento de estado:

1. Para Estado do Servidor use TanStack Query

TanStack Query (anteriormente React Query) feito especificamente para gerenciar estado do servidor. Ele lida com cache, recarregamento, dados obsoletos e muito mais, tudo pronto para uso, e voc definitivamente deveria usar isso porque voc realmente no vai querer reimplementar tudo isso do zero. Por exemplo, buscar uma lista de clientes to simples quanto:

import { useQuery } from '@tanstack/react-query';

function Customers() {
  const { data, error, isLoading } = useQuery(['customers'], fetchCustomers);
  if (isLoading) return <div>Loading...</div>;
  if (error) return <div>Error: {error.message}</div>;
  return <ul>{data.map((customer) => <li key={customer.id}>{customer.name}</li>)}</ul>;
}

O TanStack Query elimina a necessidade de gerenciar manualmente o estado do servidor e, como o estado que voc busca armazenado em cache, voc pode us-lo exatamente da mesma maneira em todos os componentes e ele ser buscado apenas uma vez.

2. Para Estado Compartilhado use Observables

Para estados menores e especficos do aplicativo, como o usurio logado, eu uso uma implementao leve do padro Observable :

export class Observable<T> {
  private _value: T;
  private subscribers = new Set<(value: T) => void>();

  constructor(initialValue: T) {
      this._value = initialValue;
    }
    get value() {
      return this._value;
    }
    set value(newValue: T) {
      this._value = newValue;
      this.notify();
    }
    subscribe(callback: (value: T) => void) {
      this.subscribers.add(callback);
      callback(this._value);
      return { unsubscribe: () => this.subscribers.delete(callback) };
    }
    private notify() {
      this.subscribers.forEach((callback) => callback(this._value));
    }
  }
}

Com isso, voc pode conectar Observables ao React usando useSyncExternalStore:

import { useSyncExternalStore } from 'react';

export function useObservable<T>(observable: Observable<T>) {
  return useSyncExternalStore(
    (callback) => observable.subscribe(callback).unsubscribe,
    () => observable.value
  );
}

Agora, voc pode criar e usar observables desta forma:

const loggedUser = new Observable<User>(user);

loggedUser.value // Para acessar o valor dentro do Observable fora do React

loggedUser.value = someOtherUser // Para definir o valor, tanto fora quanto dentro do React

Dentro de um componente React:

const user = useObservable(loggedUser);

Por que no usar React Context?

Embora o React Context funcione em alguns casos, ele tem desvantagens:

Escopo Limitado : Voc no pode acessar o Context fora dos componentes React.
Problemas de Performance : Context dispara uma nova renderizao para todos os componentes abaixo dele, at mesmo para os componentes que no usem o valor atualizado.

Usando Observables evitamos ambos problemas!

Concluso

Gerenciamento de estado global no precisa ser complicado. Combinando TanStack Query e um padro Observable leve, voc pode simplificar seu aplicativo evitando as armadilhas das bibliotecas tradicionais de gerenciamento de estado.

Entre em contato comigo se quiser discutir sobre React, React Native, Nextjs

Me contate no X (antigo Twitter)
Ou acesse Iplastudio

Bom desenvolvimento! 🎉

S3 virus scanning with TypeScript and Node.js 20.x AWS Lambda Container

Eduardo Rabelo — Wed, 06 Dec 2023 05:06:45 +0000

Searching the internet, you can find guides showing how to create a serverless virus scanning with ClamAV:

Even in the AWS Blog you can find good ideas:

However, a few aspects fell short of my expectations:

1) They are not using the latest version of ClamAV
The examples above are installing ClamAV directly from the OS package registry (e.g., yum install clamav).

They aren't always in sync with the latest release, and if you don't update or upgrade the OS package registry, you will install older versions.

Using yum install clamav for Amazon Linux 2, we receive the 0.100.x version, whereas the ClamAV release is already in the 1.x version.

2) Outdated Node.js runtime
Examples using Node.js use the outdated Node.js 14.x runtime. This runtime is already under Deprecation (Phase 1) in the AWS timeline for Node.js supported runtimes and is not part of the maintenance window of Node.js releases.

Using outdated and unsupported versions is a risk I try to avoid!

3) Using plain JavaScript
While not a deal-breaker, I don't use plain JavaScript in my production projects.

How would a TypeScript example look in the latest AWS Lambda runtime for Node.js?

4) How to use top-level await in Node.js handlers
Top-level await support in AWS Lambda is not new, but how can we configure it with everything else? (e.g., TypeScript, esbuild, etc). How can we output ESM code in the lambda handler?

Here it comes Amazon Linux 2023

Starting on Node.js 20.x runtime, the default operational system for the AWS Lambda base image is Amazon Linux 2023.

The AL2023 brings a new package management tool called dnf.

dnf is the successor to yum, the package management tool in Amazon Linux 2.

While many of the commands are compatible, for example, for the following Amazon Linux 2 yum commands:

$ sudo yum install packagename
$ sudo yum search packagename
$ sudo yum remove packagename

In AL2023, they become these commands:

$ sudo dnf install packagename
$ sudo dnf search packagename
$ sudo dnf remove packagename

Not everything stays the same. Be aware of changes! 🚨

You can check the page changes in dnf CLI compared to yum.

Let's build a newer example

We'll keep the example project similar to the guides listed at the beginning:

A S3 bucket with object notification to an AWS Lambda
When an object is created in S3, a notification triggers the AWS Lambda
The Lambda will read the file from the bucket, write it to /tmp, and run clamscan on it
The returned code from clamscan will be used to check the file status

There are a few constraints I want to define for our newer example:

Because we need to download the ClamAV virus database in our lambda source code, the uncompressed file size of 250MB can be an issue.
We will be using AWS Lambda Container image code, which enables us to have up to 10GB of uncompressed image size.
The Docker build process should take care of transpiling TypeScript to JavaScript and installing production-only dependencies.
We want to download and install the latest ClamAV during the Docker build process and update its virus definitions.

The Dockerfile

We can use Docker multi-stage builds to create these steps:

# ========================================
# Builder Image
# ========================================
FROM --platform=linux/x86_64 public.ecr.aws/lambda/nodejs:20 as builder

COPY package.json package-lock.json index.ts  ./

#
# 1) install dependencies with dev dependencies
# 2) build the project
# 3) remove dev dependencies
# 4) install dependencies without dev dependencies
#
RUN npm install && \
    npm run build && \
    rm -rf node_modules && \
    npm install --omit=dev

# ========================================
# Runtime Image
# ========================================
FROM --platform=linux/x86_64 public.ecr.aws/lambda/nodejs:20 as runtime

ENV CLAMAV_PKG=clamav-1.2.1.linux.x86_64.rpm
RUN <<-EOF
    set -ex

    #
    # install glibc-langpack-en to support english language and utf-8
    # this was required by clamscan to avoid error "WARNING: Failed to set locale"
    #
    dnf install wget glibc-langpack-en -y

    # 
    # 1) download latest ClamAV from https://www.clamav.net/downloads
    # 2) install using `rpm` and it requires full path for local packages
    # 3) remove the downloaded package and clean up for smaller runtime image
    # 
    wget https://www.clamav.net/downloads/production/${CLAMAV_PKG}
    rpm -ivh "${LAMBDA_TASK_ROOT}/${CLAMAV_PKG}"
    rm -rf ${CLAMAV_PKG}
    dnf remove wget -y
    dnf clean all

    #
    # the current working directory is "/var/task" as defined in the base image:
    # https://github.com/aws/aws-lambda-base-images/blob/nodejs20.x/Dockerfile.nodejs20.x
    #
    # 1) "lib/database" is the path to download the virus database
    # 2) "freshclam.download.log" and "freshclam.conf.log" are the log files for freshclam CLI
    #
    mkdir -p ${LAMBDA_TASK_ROOT}/lib/database
    touch ${LAMBDA_TASK_ROOT}/lib/{freshclam.download.log,freshclam.conf.log}
    chmod -R 777 ${LAMBDA_TASK_ROOT}/lib

    #
    # default configuration path for freshclam is "/usr/local/etc/freshclam.conf"
    # we create a symbolic link to the default configuration path and copy our custom config file
    #
    ln -s /usr/local/etc/freshclam.conf ${LAMBDA_TASK_ROOT}/lib/freshclam.conf
EOF

COPY freshclam.conf /var/task/lib/freshclam.conf

#
# freshclam CLI is a virus database update tool for ClamAV, documentation:
# https://linux.die.net/man/1/freshclam
#
RUN <<-EOF
    set -ex
    export LOG_FILE_PATH="${LAMBDA_TASK_ROOT}/lib/freshclam.conf.log"

    freshclam --verbose --stdout --user root \
        --log=${LOG_FILE_PATH} \
        --datadir=${LAMBDA_TASK_ROOT}/lib/database

    if grep -q "Can't download daily.cvd\|Can't download main.cvd\|Can't download bytecode.cvd" ${LOG_FILE_PATH}; then
        echo "ERROR: Unable to download ClamAV database files - your request may be being rate limited"
        exit 1;
    fi
EOF

#
# copy application files from the builder image
# 
COPY --from=builder /var/task/dist/* /var/task/
COPY --from=builder /var/task/node_modules /var/task/node_modules

CMD [ "index.handler" ]

The above Dockerfile covers:

Install and build the TypeScript Lambda to JavaScript with production dependencies using a multi-stage build. The first stage as builder creates the dist folder and node_modules folder used by the as runtime stage
Download the latest ClamAV from their release page, install it using rpm and remove cache for smaller final image
Download the ClamAV virus database definitions with freshclam
You can change the CLAMAV_PKG to be in sync with the latest version of ClamAV

🚨 Important: To update your database definition, you need to re-build this image every once in a while

The required freshclam.conf file contains the following:

CompressLocalDatabase yes
DatabaseDirectory /var/task/lib/database
DatabaseMirror database.clamav.net
DNSDatabaseInfo current.cvd.clamav.net
ScriptedUpdates no
UpdateLogFile  /var/task/lib/freshclam.conf.log

🚨 Important: The full path files (e.g., /var/task/* must match the Dockerfile definitions

The TypeScript AWS Lambda Handler

For a S3 notification event, we can write our handler similar to:

import { S3CreateEvent } from "aws-lambda";
import { GetObjectCommand, S3Client } from "@aws-sdk/client-s3";
import { spawnSync } from "node:child_process";
import { mkdir, writeFile } from "node:fs/promises";

const s3Client = await new S3Client({});

//
// directories for clamscan
// "/tmp/files_to_scan" where we will store the files from s3 to scan
// "/tmp/clamscan_tmp" required by clamscan to store temporary files during the virus scan
//
await mkdir("/tmp/files_to_scan", { recursive: true });
await mkdir("/tmp/clamscan_tmp", { recursive: true });

async function handler(event: S3CreateEvent) {
  console.log(JSON.stringify(event, null, 2));

  for (const record of event.Records) {
    const bucketName = record.s3.bucket.name;
    const objectKey = record.s3.object.key;

    const getObjectCommand = new GetObjectCommand({
      Bucket: bucketName,
      Key: objectKey,
    });
    const s3Object = await s3Client.send(getObjectCommand);
    const s3ObjectContent = (await s3Object.Body?.transformToString()) as string;

    const tmpFilePath = `/tmp/files_to_scan/${objectKey}`;
    await writeFile(tmpFilePath, s3ObjectContent, { encoding: "utf-8" });

    //
    // clamscan CLI documentation:
    // https://linux.die.net/man/1/clamscan
    //
    const clamavScan = spawnSync(
      "clamscan",
      ["--verbose", "--stdout", `--database=/var/task/lib/database`, `--tempdir=/tmp/clamscan_tmp`, tmpFilePath],
      {
        encoding: "utf-8",
        stdio: "pipe",
      },
    );
    console.log(JSON.stringify(clamavScan, null, 2));

    // You can find the return codes here:
    // https://linux.die.net/man/1/clamscan
    if (clamavScan.status === 0) {
      console.log("no virus found");
    } else if (clamavScan.status === 1) {
      console.log("virus found");
    } else if (clamavScan.status === 2) {
      console.log("some error(s) occured in clamscan");
    }

    await unlink(tmpFilePath);
  }
}

export { handler };

We use the top-level await feature and create two folders when the lambda container starts.

Later, we use spawnSync to trigger the clamscan binary installed via the Dockerfile.

Ensure you use full path definitions in the clamscan parameters, for example: /var/task/lib/database, to load the correct virus definitions.

We can test the ClamAV detection using any EICAR text files. The result should look like:

Now, we have our Dockerfile, ClamAV configuration, and Lambda handler.

Where do we deploy all of that?

The CDK TypeScript Project

Because Docker is building our lambda handler, we create its own package.json with dependencies:

{
  "name": "clamav-scan",
  "version": "1.0.0",
  "type": "module",
  "scripts": {
    "build": "rimraf dist && esbuild index.ts --format=esm --outfile=dist/index.mjs"
  },
  "devDependencies": {
    "@types/aws-lambda": "^8.10.130",
    "esbuild": "^0.19.8",
    "rimraf": "^5.0.5",
    "typescript": "^5.3.2"
  },
  "dependencies": {
    "@aws-sdk/client-s3": "^3.465.0"
  }
}

Using "type": "module" will tell TypeScript and Node.js that we are aiming to use ECMAScript Modules in our source code (ESM).

The build command asks esbuild to output our source code in the ESM format with the --format=esm flag.

The last piece of the puzzle, is the tsconfig.json:

{
  "compilerOptions": {
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "isolatedModules": true,
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "noEmit": true,
    "preserveConstEnums": true,
    "skipLibCheck": true,
    "sourceMap": false,
    "strict": true,
    "target": "ESNext"
  },
  "exclude": ["node_modules"]
}

Using NodeNext for moduleResolution / module and ESNext for target, will tell the TypeScript engine tsc to output code in ESM format.

The complete example can be found on GitHub:

oieduardorabelo / s3-virus-scanning-typescript-aws-lambda-container

S3 virus scanning with TypeScript and Node.js 20.x AWS Lambda Container

ClamAV 1.2.1 with AWS Lambda Container Images for Node.js 20.x

CDK project for deploying a ClamAV 1.2.1 with AWS Lambda Container Images for Node.js 20.x

This helps you to scan files for viruses using AWS Lambda functions

🚨 Important:

Virus definitions are updated during build
Ensure you are building the container regularly to keep your definitions up to date
You can update the Dockerfile to use a different version of ClamAV

View on GitHub

🚨 WARNING: You are being rate-limited

This is super important and caught me off guard multiple times.

Pay attention to the number of viruses your database is using:

During the build process of your Docker image, the ClamAV database mirror can rate limit your IP address and block you from downloading the virus definitions.

For example, visiting to https://database.clamav.net/main.cvd, can return the following:

Ensure your freshclam is downloading and loading the definitions:

daily.cvd

main.cvd

and bytecode.cvd

By default freshclam CLI will NOT throw an error when that happens.

That's why in the Dockerfile we are grepping the log file generated by the CLI and looking for errors:

    if grep -q "Can't download daily.cvd\|Can't download main.cvd\|Can't download bytecode.cvd" ${LOG_FILE_PATH}; then
        echo "ERROR: Unable to download ClamAV database files - your request may be being rate limited"
        exit 1;
    fi

And we manually throw an error when any of the rate-limiting messages are detected! 🏁

Understanding AWS CloudFormation Execution Permissions

Eduardo Rabelo — Mon, 17 Jul 2023 09:51:12 +0000

Do you know how CloudFormation generates permissions to provision resources in your account?

In my new article on the AWS Fundamentals blog, we walk through the CloudFormation lifecycle and how you can apply security concepts like the least privileged access in the deployment of your stack.

https://blog.awsfundamentals.com/aws-cloudformation-execution-permissions

AWS IAM Roles with AWS CloudFormation

Eduardo Rabelo — Sun, 09 Jul 2023 22:20:18 +0000

If you are starting with CloudFormation and IAM Roles, I wrote an introductory article on the AWS Fundamentals blog:

https://blog.awsfundamentals.com/aws-iam-roles-with-aws-cloudformation

If you enjoyed this post & you want to get 𝗯𝗶𝘁𝗲-𝘀𝗶𝘇𝗲𝗱 𝗔𝗪𝗦 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 straight to your inbox, feel free to check out our bi-weekly newsletter 📨

You can also browse our 𝗽𝗿𝗲𝘃𝗶𝗼𝘂𝘀 𝗶𝘀𝘀𝘂𝗲𝘀 to see what you'll subscribe to 📚

https://newsletter.awsfundamentals.com/

Parte 03 - Maximize a economia de custos e escalabilidade do DynamoDB com índice secundário otimizado

Eduardo Rabelo — Wed, 12 Apr 2023 11:34:13 +0000

Créditos

Escrito originalmente por Pete Naylor, em Maximize cost savings and scalability with an optimized DynamoDB secondary index.

Entenda projeções e medição de dados. Esqueça a sobrecarga de GSI.

Esta é a terceira parte de uma série de artigos sobre modelagem de dados do DynamoDB, criada principalmente para ajudar os desenvolvedores usando DynamoDB a entender as práticas recomendadas e evitar seguir um caminho lamentável com técnicas equivocadas de "design de tabela única". No episódio anterior - isso é um show agora? - introduzimos índices secundários locais e globais (LSIs e GSIs).

Hoje, vamos nos aprofundar para entender quais dados da tabela são projetados em um índice secundário e como isso contribui para o consumo de taxa de transferência. Também vamos separar uma das reviravoltas mais recentes no "design de tabela única" — sobrecarga de GSI — e explicar por que geralmente é uma péssima ideia sem nenhum lado positivo real. Preparado? Lá vamos nós!

Quais mudanças na tabela base são relevantes para projeção em um índice secundário?

Ao definir um índice secundário, você pode escolher quais atributos serão copiados (projetados) das alterações de itens relevantes na tabela base:

ALL — todos os atributos no item da tabela base serão copiados para o índice secundário
INCLUDE — somente a lista nomeada de atributos será copiada (e também os atributos de chave primária da tabela base e o índice secundário — estes são sempre incluídos)
KEYS_ONLY — somente os atributos de chave primária da tabela base e o índice secundário serão copiados

É assim que a medição funciona para índices secundários do DynamoDB: cada gravação feita em sua tabela base será considerada para a projeção de dados em cada um de seus índices secundários. Se a alteração do item na tabela base for relevante para o índice secundário, ela será projetada e haverá consumo da unidade de gravação - medido de acordo com o tamanho do item projetado. Haverá um custo de armazenamento para os dados projetados no índice secundário também. E lembre-se, conforme explicado no primeiro artigo desta série, Query e Scan (as únicas operações de leitura disponíveis para índices secundários) agregam o tamanho de todos os itens e, em seguida, arredondam para cima, para avaliar o total da medição da unidade de leitura. Se você mantiver a projeção de seus itens pequena, o índice custará menos e será dimensionado ainda mais antes de enfrentar qualquer tipo de preocupação importante.

Considere a projeção com muito cuidado para seu índice secundário. ALL parece simples, mas pode ser muito caro e pode inibir a escalabilidade de seu design em geral. Projete apenas os atributos que você realmente precisa.

Há mais detalhes nesta equação de eficiência para índices secundários. Você provavelmente está se perguntando por que continuo enfatizando a palavra relevante . Bem, é porque é realmente importante! Primeiro, como o DynamoDB oferece flexibilidade de esquema, os atributos definidos como a chave para seu índice secundário não precisam estar presentes em todos os itens de sua tabela (a menos que façam parte da chave primária dessa tabela). Se os atributos da chave do índice não estiverem presentes em um item da tabela, ele não será considerado relevante para projeção no índice. Você pode usar isso para criar um "índice esparso" — um poderoso mecanismo de filtragem — para localizar os dados necessários com o menor custo de armazenamento e taxa de transferência.

Um exemplo pode ser um banco de dados que armazena detalhes de status de milhões de tarefas - a grande maioria delas sendo concluída. Como podemos tornar as busca de tarefas que estão no status "enviado" mais fácil? Para tarefas que estão no status relevante da busca ("enviado"), crie um atributo que indique isso e adicione um índice secundário que seja definido por esse atributo. A presença do atributo efetivamente se torna um sinalizador - quando a tarefa for concluída, remova este atributo - a tarefa não estará mais visível no índice secundário quando a busca for realizada.

[Nossa tabela base que rastreia o status da tarefa]

[Índice secundário esparso que contém apenas tarefas aguardando atribuição]

Agora vamos imaginar que, como parte do fluxo de trabalho para tarefas com status enviado, o item de tarefa na tabela seja atualizado cinco vezes para adicionar vários detalhes em atributos não-chave. Se esses atributos forem projetados para nosso índice secundário esparso de tarefas enviadas, o índice também precisará ser atualizado cinco vezes, consumindo várias unidades de gravação. Mas nosso índice secundário esparso realmente não tem utilidade para esses atributos - eles não são relevantes para o padrão de acesso que precisamos que o índice atenda. Portanto, escolhemos uma projeção KEYS_ONLY para o índice — ela mantém baixo o consumo de unidade de leitura, maximiza a escalabilidade de busca de tarefas, economiza dinheiro em armazenamento e evita várias gravações desnecessárias na projeção do índice.

[O mesmo índice secundário, agora esparso com projeção KEYS_ONLY. Muito mais eficiente!]

O que é "sobrecarga de GSI" e por que é uma má ideia?

Em 2017, as equipes da Amazon estavam trabalhando duro para migrar suas cargas de trabalho mais críticas de bancos de dados relacionais para o DynamoDB. Eles estavam aprendendo a pensar de maneira diferente sobre a modelagem de dados, olhando além da familiar terceira forma normal (3FN) e desnormalizando dados em itens e coleções de itens no DynamoDB. Naquela época, o DynamoDB suportava no máximo 5 GSIs por tabela, limite máximo. Em alguns casos raros, haveria uma equipe com uma tabela que exigia mais de 5 GSIs para cobrir todos os seus padrões de acesso. Para aqueles de nós que trabalham para dar suporte a essas equipes, percebemos que algumas das necessidades de índice podem ser esparsas e não se sobrepõem. Talvez com alguma adaptação instável pudéssemos usar o mesmo GSI para cobrir vários requisitos de padrão de acesso - isso poderia nos ajudar a trapacear no limite do GSI? Sim: era o último recurso, tinha implicações terríveis de eficiência e operabilidade - mas às vezes funcionava. Nós nos referimos a isso como "sobrecarga de GSI".

Avançando para dezembro de 2018, o DynamoDB aumentou o limite de GSIs por tabela para 20. Alegria! Não há necessidade do hack feio de sobrecarga a partir de agora... certo? Bem, a equipe de engenharia pensou que sim, mas então surgiram algumas reviravoltas perturbadoras na fábula do "design de tabela única".

Acontece que, se você fizer coisas não naturais, desnecessárias, complexas e ineficientes para enviar dados completamente não relacionados para apenas uma tabela do DynamoDB sem motivo, acabará tendo que criar mais índices secundários para essa tabela.

Se você estiver projetando dados com o objetivo de ter exatamente uma tabela (em vez de priorizar eficiência, flexibilidade e escalabilidade), é mais provável que você encontre o limite de GSIs por tabela - e então a mesma obsessão de "exatamente uma tabela" gere um desejo equivocado ter exatamente um GSI, o que leva à sobrecarga. Isso cria uma série de problemas. Na verdade, essa técnica não traz nenhum benefício — é uma má ideia. Aqui está o porquê:

Você provavelmente precisará fazer compensações para a projeção de dados que lhe custará dinheiro e prejudicará a escalabilidade do seu design. O menor denominador comum é projetar ALL e padronizar strings para atributos de chave primária (quando números seriam mais eficientes). Ai!
Você perde a flexibilidade de poder varrer o índice secundário e recuperar apenas os dados de seu interesse. Essa é uma funcionalidade poderosa que se foi - sem nenhum motivo.
Uma das grandes vantagens dos GSIs é que você pode excluí-los e recriá-los conforme necessário. Excluir um GSI não custa nada. Se você misturou vários requisitos de índice em um único GSI e em algum momento percebeu que não precisa indexar um de seus padrões, você não pode simplesmente excluir esse GSI. Você terá que (cuidadosamente) voltar para o design da sua tabela e fazer atualizações em massa relativamente caras (e potencialmente arriscadas). Você realmente não quer lidar com isso.

Lições importantes

Resumindo, não há benefício na "sobrecarga de GSI" – apenas pontos negativos. Não faça isso! Além disso, se você se preocupa com a otimização de custos e a escalabilidade, considere a dispersão e a projeção mínima ao projetar índices secundários no DynamoDB.

No próximo artigo desta série, pretendo desenvolver o que aprendemos até agora para explicar onde as coisas deram errado com o "design de tabela única" e por que interpretá-lo exatamente como uma tabela é um erro terrível (que as equipes da Amazon não estão fazendo).

Se você quiser discutir esse tópico comigo, obter minha opinião sobre uma pergunta de modelagem de dados do DynamoDB que você tem ou sugerir tópicos para eu escrever em artigos futuros, entre em contato comigo no Twitter (@pj_naylor) ou envie-me um [e-mail diretamente]mailto:petenaylor@momentohq.com)!

Parte 02 - Qual tipo de índice secundário do DynamoDB você deve escolher?

Eduardo Rabelo — Wed, 12 Apr 2023 11:21:47 +0000

Créditos

Escrito originalmente por Pete Naylor, em Which flavor of DynamoDB secondary index should you pick?.

Use o poder dos índices secundários locais e globais.

Este é o segundo artigo de uma série curta sobre modelagem de dados no Amazon DynamoDB (sem os equívocos de "design de tabela única"). Se você não leu o primeiro artigo, eu o encorajo a dar uma olhada. Nele, discuto os conceitos mais importantes da modelagem do DynamoDB: flexibilidade de esquema e coleções de itens. Vou us essa base para discutir índices secundários, um dos meus recursos favoritos do DynamoDB. Observe que este artigo assume alguma familiaridade com os principais conceitos do DynamoDB, como partições, itens, tipos de chave primária e tipos de dados. Se você precisa se atualizar sobre eles, aqui está uma lista de vídeos que eu recomendo.

Índices secundários são poderosos! Você pode usá-los para fornecer automaticamente diferentes perspectivas para leituras dos dados em sua tabela. Eles ajudam você a definir e manter relacionamentos adicionais (coleções de itens) dentro dos mesmos dados, permitem que você classifique os dados relacionados com uma dimensão diferente e podem criar filtros incrivelmente eficazes.

Mas, como qualquer outra ferramenta, é possível utilizar os índices secundários do DynamoDB de um modo ruim.

Com grandes poderes vêm grandes responsabilidades - e uma grande necessidade de entender suas opções! Neste blog, vou me concentrar em comparar os diferentes tipos de índices secundários e oferecer algumas dicas para escolher entre eles. Deixarei de falar sobre escolhas de projeção de índice secundário e as consequências de custo e escalabilidade para o próximo artigo, além de algumas observações sobre uma tendência recente no uso de índices secundários globais do DynamoDB chamada "sobrecarga" (overloading) e por que ela deve ser evitada no design das suas tabelas na maioria dos casos.

Então fique ligado! E segurem seus chapéus - será uma turnê alucinante.

Onde vivem os índices secundários? E como eles chegam lá?

Os dados de sua tabela (o índice primário) são projetados em cseus índies secundários pelo DynamoDB com base na definição de índice que você fornece. Você não pode escrever diretamente em um índice secundário, mas ao escrever em um item em sua tabela base, o DynamoDB projetará alterações relevantes em seus índices secundários para você. Existem dois tipos de índice secundário: índices secundários locais (LSIs - Local Secondary Indexes) e índices secundários globais (GSIs - Global Secondary Indexes).

Índices secundários locais

Os LSIs residem nas mesmas partições do DynamoDB que a tabela base — eles compartilham o mesmo atributo de chave de partição (mas têm um atributo de chave de classificação diferente) e compartilham a taxa de transferência com a tabela base. Os LSIs são locais porque oferecem uma ordem de classificação diferente para uma coleção de itens dentro da mesma partição. Os LSIs oferecem suporte a leituras fortemente consistentes após escrever na tabela base, se o parâmetro for especificado na hora da solicitação de dados (caso contrário, a consistência eventual padrão é usada).

Na verdade, os LSIs e as tabelas base compartilham as mesmas coleções de itens — e isso restringe cada coleção de itens a residir em uma única partição. Quando uma tabela tem um ou mais LSIs, cada coleção de itens nunca pode crescer além de aproximadamente 10 GB (todos os dados para o mesmo valor da chave de partição na tabela base e todos os LSIs combinados). A taxa de transferência de leitura e escrita para qualquer coleção de itens é limitada a 3.000 unidades de leitura por segundo e 1.000 unidades de escrita por segundo na tabela e todos os LSIs associados.

Os LSIs devem ser definidos quando a tabela é criada e não podem ser excluídos sem excluir a tabela base associada. Pense bem antes de usar LSIs em seu modelo de dados - você deve ter um bom motivo (como um requisito válido para leituras fortemente consistentes) e deve saber que nunca terá uma coleção de itens que possa crescer e exigir mais de 10 GB, 3.000 unidades de leitura por segundo ou 1.000 unidades de escrita por segundo.

Se você decidir posteriormente que não quer ser limitado pelas propriedades dos LSIs ou não precisa mais de um LSI específico, pode ser necessária uma migração complexa de sua existente tabela para uma tabela de substituição/nova tabela.

Índices secundários globais

Os GSIs são como uma tabela separada — eles podem ter um atributo de chave de partição diferente e têm suas próprias partições e capacidade de taxa de transferência. Eles podem ser criados (com preenchimento/with backfill) conforme necessário e removidos (sem custo) quando não forem mais necessários. Eles são globais porque permitem que novos relacionamentos (coleções de itens) sejam definidos entre itens em todas as partições da tabela base. As coleções de itens em um GSI podem abranger partições para armazenar mais dados e fornecer maior taxa de transferência (também verdadeiro para a tabela base, desde que não haja LSIs).

Uma das maiores diferenças entre LSIs e GSIs está em seu comportamento durante a escrita na tabela base. Como a tabela base e quaisquer LSIs compartilham as mesmas partições, quaisquer atualizações nos LSIs são manipuladas atomicamente com a alteração no item da tabela base. Para GSIs, a alteração é propagada de forma assíncrona para uma partição diferente. Isso tem implicações de consistência de leitura após escrita. As leituras de um LSI podem ser solicitadas para serem consistentes, se desejado, mas uma leitura de um GSI é sempre eventualmente consistente.

Uma consideração adicional para leituras de um GSI é a monotonicidade. As leituras GSI não são monotônicas. Se você atualizar um item em sua tabela base para incrementar o valor de um atributo de 7 para 8, poderá fazer três leituras sucessivas dos dados projetados em seu GSI e ver o valor como 8 primeiro, depois 7 e, finalmente, de volta para 8. Uma série de leituras para os mesmos dados em um GSI pode retornar resultados que avançam e retrocedem ao longo do tempo. As leituras fortemente consistentes da tabela ou de um LSI são monotônicas.

Os GSIs são mais flexíveis que os LSIs, e qualquer LSI pode ser facilmente modelado como um GSI. Use LSIs apenas se tiver certeza de que o índice precisará suportar leituras consistentes/monotônicas ou se quiser se beneficiar do recurso de "leitura completa" (read through) (detalhes sobre isso em um artigo futuro).

Propriedades interessantes de chaves de índice secundárias

Em primeiro lugar: o valor da chave de índice não é garantido como único, como a chave primária em sua tabela base. O índice pode ter várias entradas projetadas com os mesmos valores para a chave de partição do índice e a chave de ordenação! A API GetItem não tem suporte para índices secundários porque GetItem implica a leitura de no máximo um item para um determinado valor da chave. Mas em um índice secundário, mesmo quando um valor específico da chave de índice é fornecido, você pode ver muitos itens retornados! Você deve usar Query ou Scan para ler de um LSI ou GSI. LSIs fornecem uma ordenação alternativa (sort key), GSIs fornecem coleções alternativas e ordenação (opcional).

Conforme mencionado anteriormente, um LSI deve ter uma chave composta. A tabela base à qual o LSI está anexado também deve ter uma chave composta. A chave de partição do LSI deve ser a mesma da tabela base e o atributo da chave de ordenação deve ser diferente daquele da tabela. Um exemplo simples pode ser uma interface do usuário que lista um conjunto de entradas em formato tabular — as entradas são agrupadas (coleções de itens relacionadas pelo mesmo valor do atributo chave de partição) e ordenadas por um dos valores de seus atributos (a chave de ordenação da tabela base). E se o usuário precisar ordenar o mesmo grupo de entradas por um atributo diferente? É aqui que um LSI pode ajudá-lo.

GSIs são mais flexíveis: uma chave de partição é necessária, mas pode ser diferente da tabela base - você pode relacionar/agrupar os dados da sua tabela em um atributo diferente! Uma GSI pode ter uma chave simples ou uma chave composta — e o mesmo vale para a tabela base à qual está anexada. Se você não precisa recuperar coleções de itens de seu GSI ordenados (talvez o padrão seja apenas consultar todos os itens que têm um valor comum de chave de partição no índice), não defina uma chave de ordenação - a GSI ainda pode construir coleções de itens para uma busca de dados eficiente. Definir uma chave de ordenação quando não é necessário pode limitar sua escalabilidade para as coleções de itens.

Detalhando distinções entre tipos de índices secundários

Há muitas nuâncias aqui, mas na verdade se resumem a algumas diferenças simples, então fiz uma folha de dicas que você pode usar na próxima vez que estiver considerando suas opções de índice secundário.

Fique de olho no próximo artigo desta série de modelagem de dados do DynamoDB (que visa detalhar o "design de tabela única").

Em artigos futuros: mais sobre indexação secundária e uma discussão resumida sobre onde o "design de tabela única" deu terrivelmente errado.

Parte 01 - O que realmente importa na modelagem de dados do DynamoDB?

Eduardo Rabelo — Wed, 12 Apr 2023 11:07:54 +0000

Créditos

Escrito originalmente por Pete Naylor, em What really matters in DynamoDB data modeling?.

Spoiler: não é o número de tabelas!

Quando deixei a equipe do DynamoDB alguns meses atrás, decidi que precisava compartilhar o que aprendi sobre como modelar dados para o DynamoDB e operá-lo bem. Durante meus seis anos trabalhando com clientes internos e externos do DynamoDB na AWS, tive a sorte de obter exposição a uma ampla variedade de modelos de dados do DynamoDB. Eu também vi como eles evoluíram na operação: como eles foram dimensionados (ou não) utilização com carga variável, sua flexibilidade para acomodar novos requisitos de aplicativos e se eles se tornaram proibitivos em termos de custo ao longo do tempo.

Esta é a primeira parte de uma pequena série de artigos que publicarei com o objetivo de corrigir alguns equívocos sobre as práticas recomendadas de modelagem de dados do DynamoDB. Nos últimos anos, recomendações estranhas evoluíram por meio dos rumores das mídias sociais (com a ajuda do marketing da AWS). Vou escrever sobre o mundo real. Darei os mesmos conselhos que a equipe do DynamoDB dá a outras equipes da Amazon para quem o serviço é de missão crítica - as mesmas recomendações de otimização, os mesmos avisos sobre o placebo do "design de tabela única", as mesmas dicas sobre a interpretação de métricas, os mesmos detalhes nas nuâncias de mensuração e medição, e o mesmo foco na excelência operacional.

Pronto para começar? Nesse primeiro artigo, definirei as bases para a série, compartilhando o molho secreto para o sucesso com o DynamoDB. Reconheço que demorei um pouco para realmente grocar essas coisas. Me siga! Eu conheço alguns atalhos.

O que realmente importa se não é tudo sobre o número de tabelas?

Os dois primeiros conceitos que você precisa entender ao aprender modelagem de dados do DynamoDB para levar seu pensamento além dos casos de uso de chave-valor simples são:

Flexibilidade de Esquema
Coleções de itens

Flexibilidade de esquema significa que nem todos os itens em uma tabela do DynamoDB exigem a mesma estrutura – cada item pode ter seu próprio conjunto de atributos e tipos de dados – isso abre muitas possibilidades! Na verdade, os únicos atributos para os quais o esquema é obrigatório são os atributos de chave primária — aqueles usados para indexar os dados na tabela. Cada item deve incluir os atributos-chave definidos para a tabela com o tipo de dados correto.

Uma coleção de itens é o conjunto de todos os itens que possuem o mesmo valor de atributo que a chave de partição; em outras palavras, eles estão todos relacionados pelo valor da chave de partição. Se você estiver familiarizado com bancos de dados relacionais, uma maneira de pensar sobre isso é olhar para uma coleção de itens como sendo um pouco como um JOIN materializado, onde o valor comum do atributo de chave de partição é algo como uma chave estrangeira. Para otimizar seu modelo de dados do DynamoDB, você deve procurar oportunidades para usar coleções de itens na tabela base ou em índices secundários, especialmente itens que se relacionam e que seriam buscados (seletivamente) juntos. Isso pode parecer óbvio, mas vale a pena deixar claro: para estar na mesma coleção de itens, os itens também precisam estar na mesma tabela – a coleção de itens é um subconjunto da tabela.

Por exemplo, você pode representar um carrinho de compras como uma coleção de itens, em que o identificador exclusivo do carrinho (Pete's Cart) é o valor da chave de partição e o identificador de cada produto adicionado ao carrinho é o valor da chave de ordenação (sort). Aparentemente, Pete gosta mais de café do que de vegetais, mas não tanto quanto de chocolates. O número de cada tipo de produto no carrinho é outro atributo (não-chave). A imagem abaixo descreve tal coleção de itens.

Seu código tem uma definição mais rígida, como a captura de tela do NoSQL Workbench abaixo.

As coleções de itens podem existir no índice primário (a tabela base) e/ou em um índice secundário. Vou me aprofundar nos detalhes dos índices secundários em um artigo futuro, então vamos nos concentrar na tabela base. As coleções de itens na tabela base requerem uma chave primária composta (chave de partição e chave de ordenação). Se não houver índices secundários locais (LSIs), a coleção de itens pode abranger várias partições do DynamoDB — ela não começará dessa forma, mas o DynamoDB dividirá automaticamente a coleção de itens entre as partições para acomodar o crescente volume de dados e, às vezes, ele também pode distribuir a coleção de itens entre as partições para fornecer uma taxa de transferência generalizada ou para isolar itens mais quentes (ou intervalos de itens).

É útil pensar em itens e coleções de itens como sendo dois tipos diferentes de registros no DynamoDB. Em uma tabela base com uma chave primária simples (sem chave de ordenação definida), você trabalha inteiramente com itens. Mas se sua tabela tiver uma chave primária composta (chave de partição + chave de ordenação), você trabalhará com coleções de itens. Os itens na coleção são armazenados na ordem dos valores da chave de ordenação e podem ser retornados na ordem descendente ou ascendente.

Uma coleção de itens é mágica – ela nos permite armazenar e recuperar itens relacionados juntos de forma eficiente. Os itens na coleção podem ter esquemas diferentes (o DynamoDB é flexível, lembra?) — cada um representando uma parte do registro geral da coleção de itens.

Se você tiver um item de 200 KB, atualizar até mesmo uma pequena parte desse item consumirá 200 unidades de escrita. Se, ao invés disso, esse item for armazenado como uma coleção de partes de itens em uma coleção, você poderá atualizar qualquer pequena parte para um consumo mínimo de unidade de escrita. Ei, mas isso é só o começo!

Você pode usar a operação Query para recuperar todos os itens da coleção ou apenas aqueles com um intervalo específico de valores de chave de ordenação. A especificação para o intervalo é chamada de condição de chave de ordenação (sort key condition). Dentro da coleção de itens, você pode limitar os itens recuperados para serem aqueles com uma chave de ordenação menor que um valor escolhido, ou maior que, ou mesmo entre dois valores.

Para chaves de ordenação em strings, você também pode usar begin_with (que na verdade é apenas uma variação de between, se você pensar bem). A aplicação de uma condição de chave de ordenação limita efetivamente o intervalo de itens a serem retornados da coleção de itens. É importante ressaltar que apenas os itens da coleção que correspondem à condição da chave de ordenação serão incluídos na medição das unidades de leitura (read units). Isso contrasta com uma expressão de filtro que se aplica após a avaliação das unidades de leitura - portanto, você ainda paga para ler os itens filtrados. Quando você recupera vários itens usando Query (ou Scan), a medição do consumo da unidade de leitura adiciona os tamanhos de todos os itens e depois arredonda para o próximo limite de 4KB (ao invés de arredondar para cada item como GetItem e BatchGetItem fazem). Assim, as coleções de itens permitem que você armazene registros muito grandes, atualize partes seletivas a baixo custo e recupere-as com eficiência ideal.

Coleções de itens (Query) e Scan são, na verdade, os únicos diferenciadores atraentes de custo e desempenho que defendem o armazenamento de dois itens na mesma tabela. Ambos permitem a recuperação de vários itens com os tamanhos de itens agregados arredondados para o próximo limite de 4 KB. Se você não for indexar dois itens juntos na mesma coleção de itens (tabela ou índice secundário) e não quiser retornar ambos de cada Scan, não há vantagem em mantê-los na mesma tabela. Mas certamente existem algumas desvantagens que abordarei um pouco mais tarde. Para todas as outras operações de dados (incluindo vários itens como BatchGetItem, TransactWriteItems, etc), o DynamoDB não se importa se os itens estão na mesma tabela ou não - você verá a mesma medição de armazenamento/taxa de transferência e o mesmo desempenho de qualquer jeito.

‍As vezes, para reunir os dados na mesma coleção de itens, você precisa fazer alguns ajustes nos valores da chave primária. Para ser armazenado na mesma tabela, a mesma definição de chave primária deve ser usada. Exemplos disso incluem armazenar um valor numérico como uma string para corresponder ao tipo de dados da chave de partição ou chave de ordenação ou criar um valor exclusivo para a chave de ordenação onde você não necessariamente tem algo importante para armazenar (usando o mesmo valor que o atributo de chave de partição é comum para isso ao criar um item de "metadados" na coleção).

‍
Imagine uma tabela para armazenar pedidos de clientes para envio. A chave de partição é um identificador de pedido numérico exclusivo (o tipo de dados é número) e você deseja usar uma coleção para armazenar um registro por item de itens do carrinho (identificado por um SKU numérico) e eventos de rastreamento (identificados por um UUID ordenável, como ksuid) para processamento de pedidos. Você deseja recuperá-los juntos para eficiência porque o padrão mais comum é fornecer uma página de rastreamento com os itens comprados mostrados além dos detalhes de rastreamento. Nesse caso, você precisará definir a chave de ordenação com tipo de dados string e converter valores para armazenar esses SKUs numéricos como strings. Há um custo para isso (porque armazenar um número como uma string consome mais bytes), mas vale a pena para obter o benefício da coleção de itens.

Como é fácil acomodar essas alterações ao escrever seus itens na tabela, um desenvolvedor pode fazer isso apenas para todos os itens e coleções de itens, certo? E colocá-los todos na mesma tabela? Faria sentido para todos os clientes do DynamoDB se unirem e armazenarem seus dados em uma tabela multi-tenant gigante? Não, claro que não. Essas técnicas têm um custo e só devem ser usadas quando puderem ser justificadas - para colher os benefícios das coleções de itens.

Finalizando

A parte valiosa e válida da orientação de "design de tabela única" é simplesmente esta:

Use a flexibilidade de esquema e as coleções de itens do DynamoDB para otimizar seu modelo de dados para os padrões de acesso que você precisa cobrir.

Se você estiver migrando de um banco de dados relacional, provavelmente terminará com menos tabelas do que seu antigo modelo totalmente normalizado. Você provavelmente terá mais de uma tabela e deve usar qualquer número de Índices Secundários Globais (GSIs) necessários para atender aos seus padrões secundários.

Sim, é isso. Realmente nunca houve necessidade de criar uma nova terminologia. O "design de tabela única" confundiu algumas pessoas e levou muitas outras a um caminho doloroso, complexo e caro (detalhes sobre isso em um próximo artigo) quando foi interpretado literalmente e, em seguida, deturpado como "melhor prática".

É hora de deixar essa terminologia de lado - ficar com a flexibilidade do esquema e as coleções de itens.

Fique de olho em artigos futuros em que discutirei as nuâncias de LSIs e GSIs e explicarei por que a "sobrecarga de GSI" é um padrão de modelagem de araque.

Apêndice: O que eu saberia sobre o DynamoDB afinal?

Até recentemente, eu trabalhava na AWS. Comecei como gerente técnico de contas em 2016 na equipe de contas que oferece suporte à Amazon.com como cliente corporativo da AWS. Minha área de foco era ajudar a Amazon a atingir algumas metas organizacionais ambiciosas: 1) migrar projetos críticos de bancos de dados transacionais de bancos de dados relacionais tradicionais para bancos de dados distribuídos desenvolvidos especificamente para computação em nuvem (como DynamoDB); 2) cargas transacionais de segundo nível "lift and shift" do Oracle para o Aurora; e 3) mover todo o armazenamento de dados do Oracle para o Redshift. Foi uma experiência fantástica em geral, mas a parte que mais gostei foi testemunhar a redução drástica na carga operacional e as melhorias na disponibilidade e latência que o DynamoDB proporcionou. Trabalhei com centenas de equipes de desenvolvedores da Amazon.com para revisar seus modelos de dados, ensiná-los sobre como gerenciar limites, dimensionamento, alarmes e painéis do DynamoDB. Sentei-me nas salas de guerra para eventos de pico, como o Prime Day, como ponto de contato para qualquer tipo de preocupação relacionada ao DynamoDB que surgisse com o rápido crescimento do tráfego de eventos. Não foi fácil para todos fazer a mudança de paradigma do modelo de dados, mas quando esse programa foi concluído, todos os desenvolvedores rapidamente passaram a considerar todas as vantagens garantidas do DynamoDB. Eles passaram a dedicar muito mais tempo às coisas que faziam a diferença para seus clientes — ver isso me impressionou profundamente.

Em 2018, tornei-me um arquiteto de soluções especializado em DynamoDB — parte de uma pequena equipe que trabalha com os maiores clientes corporativos (externos) da AWS. Eu os ajudei a desenvolver modelos de dados DynamoDB eficazes e eficientes para uma ampla variedade de casos de uso e padrões de acesso, e ensinei muitos desenvolvedores a operar bem com o DynamoDB. Meus últimos 18 meses na AWS foram gastos como gerente de produto para o serviço DynamoDB. Também dei centenas de consultorias a engenheiros de várias equipes de serviço da AWS como parte de um programa de "office hours" para o DynamoDB — revisando modelos de dados, fornecendo orientação de arquitetura mais ampla e ensinando sobre como o DynamoDB funciona e os insights revelados pelas métricas.

Tudo isso é para dizer que já vi muitos casos de uso de produção para o DynamoDB (de centenas de solicitações por dia a milhões de solicitações por segundo) e tenho uma forte noção da maneira como os desenvolvedores (na Amazon.com, dentro da AWS e em muitas outras empresas ao redor do mundo) estão realmente usando o DynamoDB na prática.

Construindo Arquiteruras Orientadas a Eventos

Eduardo Rabelo — Tue, 14 Mar 2023 00:11:57 +0000

🇧🇷 Tradução completa do Building Event Driven
Architectures do Serverless Land.

Nota: Essa é uma tradução livre, não oficial, realizada no meu tempo livre - Eduardo Rabelo.

Construindo Arquiteruras Orientadas a Eventos

As arquiteturas orientadas a eventos são um estilo de arquitetura que pode ajudá-lo a aumentar a agilidade de criar aplicativos confiáveis e escaláveis. Serviços serverless como EventBridge, Step Functions, SQS, SNS e Lambda têm uma afinidade natural com arquiteturas orientadas a eventos - elas são invocadas por eventos, emitem eventos e possuem recursos nativos para construir com eventos.

Saiba mais sobre arquiteturas orientadas a eventos, incluindo conceitos-chave, práticas recomendadas, serviços da AWS e recursos de introdução.

Este guia irá te apresentar a arquiteturas orientadas a eventos. Você vai compreender os padrões das arquiteturas orientadas a eventos e os serviços da AWS usados para implementá-los. Aprenda as práticas recomendadas para criar arquiteturas orientadas a eventos, desde a criação de esquemas de eventos até o tratamento de conceitos como a idempotência. Ao concluir esse guia, você encontrará recursos extras para expandir seu conhecimento em como criar arquiteturas orientadas a eventos na AWS.

A tradução completa no GitHub

oieduardorabelo / construindo-arquiteruras-orientadas-a-eventos-serverless-land

🇧🇷 Tradução completa do Building Event Driven Architectures do Serverless Land.

Nota: Essa é uma tradução livre, não oficial, realizada no meu tempo livre - Eduardo Rabelo.

Construindo Arquiteruras Orientadas a Eventos

Saiba mais sobre arquiteturas orientadas a eventos, incluindo conceitos-chave, práticas recomendadas, serviços da AWS e recursos de introdução.

View on GitHub

10 melhores práticas para nomes de arquivos e buckets no Amazon S3

Eduardo Rabelo — Mon, 13 Mar 2023 03:44:07 +0000

O Amazon S3 é um serviço de armazenamento simples que oferece escalabilidade, disponibilidade de dados, segurança e desempenho que são líderes do setor. Ao nomear seus buckets do S3, siga estas práticas recomendadas para garantir um gerenciamento de dados tranquilo e eficiente.

Amazon S3 é um popular serviço de armazenamento em nuvem fornecido pela Amazon Web Services (AWS). O S3 é um armazenamento de valor-chave simples com o benefício adicional de oferecer baixa latência e alta durabilidade.

Ao trabalhar com o S3, é importante seguir as práticas recomendadas para nomear objetos armazenados nos buckets. Isso ajudará você a manter seus dados organizados e facilitará a localização do que você está procurando.

Neste artigo, discutiremos as 10 melhores práticas para nomes de arquivos e buckets no Amazon S3.

1. Use uma convenção de nomenclatura consistente

Quando você tem uma convenção de nomenclatura consistente, é muito mais fácil encontrar os arquivos que está procurando. Por exemplo, se todos os seus arquivos de imagem forem nomeados com a data primeiro, seguida por uma descrição da imagem, será muito mais fácil encontrar uma imagem específica do que se todos fossem nomeados aleatoriamente.

Também é importante usar uma convenção de nomenclatura consistente porque facilita a automatização de tarefas. Por exemplo, se você sabe que todos os seus arquivos de imagem são nomeados da mesma maneira, você pode facilmente escrever um script que faça backup deles automaticamente em outro local.

Por fim, usar uma convenção de nomenclatura consistente facilita o compartilhamento de arquivos com outras pessoas. Se você sabe que todos os seus arquivos são nomeados da mesma maneira, basta dizer a alguém para ir ao seu site e procurar o nome do arquivo que está procurando. Isso é muito mais fácil do que tentar explicar onde encontrar um arquivo quando os nomes estão por toda parte.

2. Evite caracteres especiais em nomes de buckets

Quando você cria um bucket, a Amazon atribui automaticamente a ele um endpoint de site. Este é o URL que você usa para acessar o conteúdo do seu bucket quando está usando o recurso de hospedagem de site estático do S3.

No entanto, se o nome do seu bucket contiver caracteres especiais, como pontos ou hífens, o endpoint do site não funcionará. Isso significa que qualquer pessoa que tentar visitar seu site receberá uma mensagem de erro.

Para evitar esse problema, certifique-se de que seus nomes de bucket não contenham nenhum caractere especial.

3. Não use pontos nos nomes dos buckets

Quando você cria um bucket com um ponto no nome, como "meu.projeto", o S3 irá tratá-lo como dois buckets diferentes: "meu" e "projeto". Isso pode causar problemas porque, ao tentar acessar o bucket "meu.projeto", você pode ser redirecionado para o bucket "projeto".

Para evitar esse problema, simplesmente não use pontos em seus nomes de bucket.

4. Os nomes dos buckets são globalmente únicos

Quando você cria um novo bucket, o Amazon S3 verifica se o nome escolhido está disponível como um subdomínio DNS (Domain Name System). Se o nome estiver disponível, o Amazon S3 atribuirá esse nome ao seu bucket. No entanto, se o nome escolhido não estiver disponível, o Amazon S3 retornará uma mensagem de erro.

Isso é importante porque significa que você poderia criar inadvertidamente dois buckets com o mesmo nome e esses buckets seriam acessíveis a partir de URLs diferentes. Por exemplo, digamos que você crie um bucket chamado "example-bucket" na região Leste dos EUA (N. Virgínia, us-east-1). Em seguida, outra pessoa cria um bucket com o mesmo nome na região da UE (Irlanda, eu-west-1). Embora sejam dois buckets diferentes, ambos podem ser acessados usando a URL "example-bucket.s3.amazonaws.com".

Para evitar esse problema, escolha um nome único para seu bucket e use o identificador de região ao criar buckets em diferentes regiões. Por exemplo, você pode nomear seu bucket "example-bucket-us-east-1" na região US East (N. Virginia) e "example-bucket-eu-west-1" na região EU (Irlanda).

5. Mantenha seus buckets organizados

Quando você tem muitos dados no S3, pode ser difícil acompanhar tudo sem uma estrutura organizacional clara. Ao usar uma convenção de nomenclatura consistente para seus buckets, você pode garantir que todos os seus dados sejam fáceis de localizar e gerenciar.

Uma boa maneira de organizar seus buckets é usar um prefixo ou sufixo que indique o tipo de dados armazenados em cada bucket. Por exemplo, você pode usar o prefixo "dados-brutos" (raw-data) para buckets contendo arquivos não tratados, "dados-processados" para buckets contendo arquivos de dados processados e assim por diante.

Ao usar uma convenção de nomenclatura consistente, você pode tornar mais fácil para você e para outras pessoas encontrar e usar os dados armazenados em seus buckets do S3.

6. Crie e aplique políticas para o gerenciamento do ciclo de vida de objetos no S3

Os objetos no S3, por padrão, são colocados em uma classe de armazenamento Standard, o que significa que eles são armazenados indefinidamente, a menos que você especifique uma classe de armazenamento diferente ou exclua o objeto. No entanto, você pode não querer manter todos os objetos do S3 para sempre. Por exemplo, você pode precisar acessar determinados objetos apenas por um tempo limitado, após o qual poderá excluí-los.

A criação e aplicação de políticas para o gerenciamento do ciclo de vida de objetos no S3 permite que você exclua objetos automaticamente após um determinado período de tempo, o que pode ajudar a economizar nos custos de armazenamento. Ele também pode ajudar a melhorar a segurança, garantindo que objetos antigos e não utilizados não sejam deixados espalhados onde possam ser acessados por usuários não autorizados.

Para criar e aplicar políticas para o gerenciamento do ciclo de vida do objeto S3, você pode usar o AWS Management Console, os SDKs da AWS ou a AWS Command Line Interface (AWS CLI).

7. Habilite o versionamento em todos os buckets

O controle de versão é um recurso crítico do S3 que permite manter várias versões de um objeto no mesmo bucket. Isso é útil por vários motivos, como poder reverter para versões anteriores de um objeto ou recuperar-se de exclusões acidentais.

Habilitar o controle de versão em um bucket é fácil e leva apenas alguns cliques no console AWS. Depois de ativados, todos os objetos armazenados no bucket terão seu próprio ID de versão única. Esses IDs podem ser usados para recuperar versões específicas de um objeto quando necessário.

8. Criptografar dados em repouso (Encrypt data at rest)

Quando os dados são armazenados no S3, eles são armazenados fisicamente em servidores pertencentes e operados pela Amazon. Embora a Amazon faça um ótimo trabalho protegendo seus servidores, eles não podem garantir que os servidores nunca sejam comprometidos.

Se os dados forem criptografados em repouso, mesmo que os servidores sejam comprometidos, os dados ainda estarão seguros porque serão ilegíveis sem as chaves de criptografia.

Há duas maneiras principais de criptografar dados em repouso no S3: criptografia do lado do servidor e criptografia do lado do cliente.

A criptografia do lado do servidor é quando a Amazon criptografa os dados antes de serem gravados no servidor. Os dados são descriptografados automaticamente quando são lidos do servidor.

A criptografia do lado do cliente é quando os dados são criptografados pelo cliente antes de serem enviados para a Amazon. Os dados permanecem criptografados enquanto são armazenados no servidor e só são descriptografados quando o cliente os recupera.

Ambos os métodos são igualmente seguros, mas a criptografia do lado do cliente requer mais trabalho para configurar.

9. Monitore e audite o acesso aos seus buckets

Se você não estiver monitorando e auditando o acesso aos seus buckets, não terá como saber quem está acessando seus dados ou o que eles estão fazendo com eles. Isso pode levar a violações de dados, vazamentos de dados ou até mesmo perda de dados.

Para evitar esses riscos, você deve sempre monitorar e auditar o acesso aos seus buckets do S3. A AWS fornece um serviço chamado CloudTrail que facilita isso. Com o CloudTrail, você pode ver quem acessou seus buckets, o que eles fizeram e quando o fizeram.

Você também pode usar o CloudTrail para configurar alertas para ser notificado imediatamente se alguém tentar acessar seus buckets sem permissão. Dessa forma, você pode agir rapidamente para evitar qualquer dano.

10. Limite o acesso público aos seus buckets

Quando você cria um novo bucket do S3, ele é automaticamente privado. No entanto, existem várias maneiras de alguém tornar seu bucket público sem que você perceba. Por exemplo, se você usar um console do Amazon S3 para fazer upload de arquivos para um bucket e esquecer de definir as permissões, qualquer pessoa poderá acessar esses arquivos.

Para evitar isso, é importante limitar o acesso público aos seus buckets. Você pode fazer isso configurando uma política de bucket que nega todo o acesso público ou usando Amazon S3 Block Public Access.

Ambos os métodos ajudarão a garantir que apenas usuários autorizados possam acessar seus buckets S3 e que seus dados estejam seguros.

Créditos

Escrito originalmente por Janet Maples, em 10 S3 Naming Convention Best Practices.

Como construir uma aplicação WebSocket Serverless

Eduardo Rabelo — Wed, 08 Feb 2023 22:02:18 +0000

Ao criar aplicativos da web modernos, é cada vez mais importante ser capaz de lidar com dados em tempo real com uma arquitetura orientada a eventos para propagar mensagens para todos os clientes conectados instantaneamente.

Vários protocolos estão disponíveis, mas o WebSocket é indiscutivelmente o mais usado, pois é otimizado para sobrecarga mínima e baixa latência. O protocolo WebSocket oferece suporte à comunicação bidirecional full-duplex entre cliente e servidor em uma conexão persistente de soquete único. Com uma conexão WebSocket, você pode eliminar o polling e enviar atualizações para um cliente assim que um evento ocorrer.

Como integrar WebSocket em sua aplicação

Você pode fornecer uma arquitetura orientada a eventos configurando um servidor WebSocket dedicado para os clientes se conectarem e receberem atualizações. No entanto, essa arquitetura tem várias desvantagens, incluindo a necessidade de gerenciar e escalar o servidor e a latência inerente no envio de atualizações desse servidor para clientes, que podem ser distribuídos mundialmente.

Para expandir seu hardware em todo o mundo, você pode delegar a responsabilidade e o custo de hardware ao alugar recursos de um provedor de serviços em nuvem. Por exemplo, você pode usar um serviço de nuvem gerenciado, como o Amazon ECS, ou pode optar por uma solução WebSocket Serverless.

Um aplicativo serverless é aquele que não custa nada para você executar quando ninguém o está usando, excluindo os custos de armazenamento de dados. - Cloud 2.0: Code is no longer King — Serverless has dethroned it

Economizar nos custos operacionais é um excelente motivo para considerar uma estrutura serverless: você colhe os benefícios de escala e elasticidade, mas não precisa provisionar ou gerenciar os servidores.

Este artigo explica como criar uma aplicação básica de WebSocket Serverless, ideal para aplicativos simples, como bate-papo, usando o AWS API Gateway para criar um endpoint WebSocket e o AWS Lambda para gerenciamento de conexão e lógica de negócios de back-end.

A arquitetura básica de uma aplicação WebSocket Serverless

Construir uma aplicação simples de WebSocket Serverless é relativamente direto, usando o AWS API Gateway para criar APIs WebSocket e funções Lambda para processamento do back-end, armazenando metadados de mensagem no Amazon DynamoDB.

API Gateway

O Amazon API Gateway é um serviço para criar e gerenciar APIs. Você pode usá-lo como um proxy com estado para encerrar conexões WebSocket persistentes e transferir dados entre seus clientes e back-ends baseados em HTTP, como AWS Lambda, Amazon Kinesis ou qualquer outro endpoint HTTP.

AWS Lambda

O AWS Lambda é um serviço de computação serverless que permite executar código sem provisionar ou gerenciar servidores.

As APIs WebSocket podem invocar funções do Lambda, por exemplo, para entregar mensagens para processamento adicional e, em seguida, retornar o resultado ao cliente. As funções do Lambda são executadas apenas pelo tempo necessário para lidar com qualquer tarefa individual. Para autorização de conexões de clientes, a solicitação de conexão deve incluir credenciais a serem verificadas por uma função de autorizador do Lambda que retorna a política AWS IAM apropriada para direitos de acesso.

Exemplo: aplicativo de bate-papo com WebSocket Serverless

Como é tradicional, vamos ver um exemplo de aplicativo de bate-papo para ilustrar como a solução WebSocket Serverless alimenta um aplicativo simples de tempo real. Primeiro, considere a sequência pela qual uma conexão WebSocket do cliente é feita e armazenada.

Um dispositivo cliente estabelece uma única conexão WebSocket com o API Gateway. Cada conexão WebSocket ativa tem um URL de retorno individual no API Gateway que é usado para enviar mensagens de volta ao cliente correspondente.
A mensagem de conexão é enviada para uma função de autoriazação no AWS Lambda do API Gateway para confirmar se o dispositivo possui as credenciais corretas para se conectar ao serviço.
A mensagem de conexão e os metadados são enviados para um AWS Lambda separado quando ele é autenticado.
O manipulador Lambda inspeciona os metadados e armazena as informações apropriadas no Amazon DynamoDB, um banco de dados de documentos NoSQL.

Em um aplicativo de bate-papo, os usuários podem se envolver em várias conversas envolvendo um ou mais participantes. Este é um caso de uso típico para o padrão de publicação e assinatura (pub/sub). Quando um usuário envia uma mensagem para uma conversa ou canal específico, o aplicativo de bate-papo publica a mensagem para todos os outros usuários que se inscrevem nesse canal. Cada assinante desse canal recebe a mensagem em seu aplicativo.

Quando o aplicativo de bate-papo inicia uma conexão WebSocket com o API Gateway, deve haver uma maneira de determinar os canais para os quais essa conexão está autorizada a publicar e se inscrever. O código do cliente deve enviar essas informações dentro dos metadados da conexão.

Agora vamos considerar o ponto em que o usuário envia uma mensagem e outro usuário a recebe:

Um cliente envia uma mensagem de bate-papo, incluindo os metadados para identificar o canal específico no qual publicar.
No recebimento, o API Gateway o envia para a função Lambda apropriada.
Após a chamada, o Lambda verifica as conexões inscritas nesse canal e envia ao API Gateway o ID de cada assinante e a mensagem enviada.
O API Gateway usa as URLs de retorno para cada conexão de assinante para enviar a mensagem ao cliente da conexão WebSocket estabelecida.
Após a desconexão, uma função do Lambda é invocada para limpar o ID de conexão do banco de dados.

As limitações dessa implementação simples de WebSocket Serverless

O exemplo acima é um exemplo simplista de um aplicativo orientado a eventos em tempo real usando WebSocket Serverless. Algumas das limitações incluem:

O rastreamento do estado da conexão não escala: O API Gateway não rastreia metadados de conexão, e é por isso que ele precisa ser armazenado em um banco de dados como o Amazon DynamoDB usando uma função Lambda para atualizar o banco para cada conexão/desconexão. Para um grande número de clientes conectados, você atingiria os limites de escala do Lambda. Ao invés disso, você pode usar a integração nativa do API Gateway para chamar o DynamoDB diretamente, mas você precisará ficar atento ao alto nível de uso do banco de dados.

Outro aspecto que não abordamos é o da desconexão abrupta. Nos casos em que uma conexão do cliente cai sem aviso, a conexão ativa do WebSocket não é devidamente limpa. O banco de dados provavelmente armazenará identificadores de conexão que não estão mais presentes, o que pode causar ineficiências.

Uma maneira de evitar conexões zumbis é verificar periodicamente se uma conexão está "ativa" usando um mecanismo de pulsação, como TCP keepalives ou controle de frames em ping/pong. O envio de pulsações afeta negativamente a escalabilidade e a confiabilidade do sistema, especialmente ao lidar com milhões de conexões WebSocket simultâneas, pois cria uma carga extra no sistema.

Você não pode transmitir mensagens para todos os clientes conectados: Neste design simples, não há como enviar uma mensagem simultaneamente para várias conexões, como seria de esperar de um canal ou tópico pub/sub padrão. Distribuir uma atualização publicando-a para milhares de clientes exigiria que você buscasse os IDs de conexão do banco de dados e, em seguida, fizesse uma chamada de API para cada um, o que não é uma abordagem escalável. Como alternativa, você pode considerar o Amazon SNS para adicionar pub/sub ao seu aplicativo, mas ainda há limitações e a desvantagem da complexidade adicional. Para um exemplo de aplicativo de bate-papo, você pode supor que os canais típicos terão um número baixo de inscritos, a menos que sejam usados em sessões interativas de transmissão ao vivo com milhares de usuários. Outros cenários que podem tolerar a falta de transmissão incluem notificações de atualização individuais e recursos de interatividade que funcionam item por item. Os casos de uso de fan-out de dados ao vivo não podem suportar essa limitação se houver um grande número de assinantes em um canal para receber o placar esportivo ou atualização de notícias mais recente.

Há um limite para o número de conexões WebSocket permitidas por segundo: o AWS API Gateway define um limite por região de 500 novas conexões por segundo por conta e 10.000 conexões simultâneas. Isso pode ser insuficiente se você planeja escalar seu aplicativo.

A aplicação está vinculada a uma única região da AWS: As conexões WebSocket oferecidas pelo API Gateway estão vinculadas a uma única região, resultando em baixo desempenho devido à latência para clientes distantes geograficamente dessa região. É possível usar o Amazon EventBridge, um event bus serverless, para roteamento de eventos entre regiões para replicar eventos.

Desafios da construção de uma aplicação WebSocket Serverless pronta para produção

A arquitetura acima tem potencial se usada para criar uma aplicação simples de mensagens em tempo real, embora já tenhamos visto que ela tem sérias limitações em escala. Se você precisar de um sistema pronto para produção, precisará escala para milhões de conexões, mas também precisará considerar a confiabilidade de sua solução em termos de desempenho, integridade da entrega de mensagens, tolerância a falhas e suporte de fallback, todos os quais podem ser complexos e demorados. consumindo tempo para resolver.

Desempenho

Em um sistema distribuído, a latência se deteriora à medida que avança, portanto, os dados devem ser mantidos o mais próximo possível dos usuários por meio de datacenters gerenciados e edge acceleration points . No entanto, não é suficiente para minimizar a latência. A experiência do usuário precisa que a variação de latência seja mínima para garantir a previsibilidade.

Integridade da mensagem

Quando a conexão de um usuário cai e se reconecta, o aplicativo precisa continuar com o mínimo de atrito do ponto antes de ser desconectado. Quaisquer mensagens perdidas precisam ser entregues sem duplicar as já processadas. Toda a experiência precisa ser totalmente integrada.

Tolerância a falhas e escalabilidade

A demanda por um serviço pode ser imprevisível e é um desafio planejar e fornecer capacidade suficiente. Uma solução em tempo real deve estar altamente disponível em todos os momentos para suportar picos de dados. O desafio é escalar horizontalmente e absorver rapidamente milhões de conexões sem a necessidade de pré-provisionamento.

Sua solução também deve ser tolerante a falhas para continuar operando mesmo se um componente falhar. É necessário haver vários componentes capazes de manter o sistema se alguns forem perdidos. Não deve haver nenhum ponto único de congestionamento e nenhum ponto único de falha.

Conexões alternativas

Apesar do amplo suporte, o protocolo WebSocket não é suportado por todos os proxies ou navegadores, e alguns firewalls corporativos até bloqueiam portas específicas, o que pode afetar o acesso ao WebSocket. Você pode considerar oferecer suporte a conexões alternativas, como streaming XHR, XHR polling ou long-polling.

Desvio de recursos

Outro desafio para o uso de WebSocket Serverless puro em um sistema pronto para produção pode se apresentar apenas depois de usá-lo com sucesso na primeira iteração do produto. Embora você tenha adicionado o recurso essencial para receber atualizações em tempo real, o aumento de recursos geralmente significa que os recursos geram requisitos adicionais para experiências ao vivo compartilhadas e recursos colaborativos.

Construir e manter uma solução proprietária de WebSocket para suportar as futuras necessidades em tempo real de um produto pode ser um desafio. A infraestrutura que sustenta o sistema deve ser estável e confiável e requer engenheiros experientes para construí-la e mantê-la. Uma equipe de desenvolvimento pode descobrir que tem um compromisso de longo prazo para oferecer suporte à solução em tempo real, em vez de se concentrar nos recursos que aumentam o produto principal.

Ably: um WebSocket PaaS sem servidor criado para escala

Adotar uma solução WebSocket Serverless de um fornecedor terceirizado faz mais sentido financeiro para muitas organizações. Caso contrário, você pode gastar vários meses e muito dinheiro. Você acabaria sobrecarregado com o alto custo de propriedade da infraestrutura, dívida técnica e demandas contínuas de investimento em engenharia.

O Ably possui infraestrutura global elástica tolerante a falhas e altamente disponível para escalabilidade sem esforço e baixa complexidade. Nossa plataforma WebSocket Serverless é modelada matematicamente em torno dos Quatro Pilares de Confiabilidade. Podemos garantir que as mensagens sejam entregues com baixa latência em uma rede de ponta segura, confiável e global. Não há sobrecarga de DevOps e não há infraestrutura para gerenciar.

A plataforma Ably abstrai a preocupação de construir uma solução em tempo real para que você possa priorizar o roadmap do seu produto e desenvolver recursos para se manter competitivo.

Embora o protocolo nativo de Ably seja o WebSocket, raramente existe um protocolo de tamanho único: protocolos diferentes atendem a propósitos diferentes melhor do que outros. O Ably oferece vários protocolos , como WebSocket, MQTT, SSE e HTTP puro.

Para oferecer suporte a experiências ao vivo, Ably adiciona recursos como presença de dispositivo , histórico de transmissão , rebobinar canais e tratamento de desconexões abruptas, facilitando a criação de aplicativos avançados de tempo real. Há uma variedade de integrações de webhook para acionar a lógica de negócios em tempo real. Oferecemos um gateway para funções serverless de seus provedores de serviços de nuvem preferidos. Você pode implantar as melhores ferramentas da categoria em toda a sua pilha e criar aplicativos orientados a eventos usando os ecossistemas nos quais já investiu.

Ably permite que você ofereça uma experiência ao vivo sem atrasos, custos descontrolados ou usuários insatisfeitos. O uso do Ably permite que suas equipes de engenharia se concentrem na inovação do produto principal sem precisar provisionar e manter a infraestrutura em tempo real. Nossos clientes existentes já criam aplicativos em tempo real massivamente escaláveis, com entrada rápida no mercado e economia média de US$ 500.000 no custo de construção e manutenção.

Faça o download do nosso relatório "O estado da infraestrutura WebSocket Serverless".

Conclusão

Neste artigo, revisamos a arquitetura de uma plataforma simples de WebSocket Serverless usando o Amazon API Gateway e o AWS Lambda. Também consideramos algumas das limitações desse design, como falta de suporte para transmissão de mensagens em larga escala, deploy de região única e gerenciamento de conexão.

Apresentamos a plataforma WebSocket Serverless da Ably, que lida de forma confiável com a distribuição de dados em tempo real em alta escala para aplicativos móveis e da web.

Você pode entrar em contato para saber como podemos trabalhar com você!

Créditos

Escrito originalmente por Jo Stichbury, em How to build a serverless WebSockets platform.

Um guia prático para testar o AWS Step Functions

Eduardo Rabelo — Tue, 07 Feb 2023 06:50:44 +0000

Testar Step Functions pode ser uma tarefa assustadora. No entanto, com um pouco de preparação e esforço, o processo de teste pode ser simplificado e otimizado. Neste artigo, forneceremos uma estratégia prática sobre como testar Step Functions. Então, vamos começar preparando o cenário e apresentando os jogadores.

O que torna o Step Functions difícil de testar?

As Step Functions são complicadas por natureza porque consistem em muitas partes diferentes que precisam ser testadas individualmente.

Por exemplo, uma máquina de estado típica do Step Functions pode incluir ramificação condicional que pode direcionar a execução para diferentes caminhos. Todos esses caminhos precisam ser testados para que possamos ter certeza de que estão funcionando conforme o esperado.

Também podemos incorporar a lógica try..catch em nossa máquina de estado para nos ajudar a recuperar de erros que possam ocorrer em tempo de execução. Essa lógica também precisa ser testada minuciosamente para garantir que funcione corretamente.

Outra coisa importante a observar é que o Step Functions funciona em um ambiente altamente distribuído. Podemos usar as funções do Lambda para executar a lógica de negócios personalizada, bem como integrar diretamente com mais de 200 serviços da AWS. Toda essa funcionalidade precisa ser testada minuciosamente para garantir que ela se comporte adequadamente quando lançarmos nosso aplicativo em produção.

Além do mais, você pode usar padrões de retorno de chamada para suspender a execução enquanto esperamos que os processos externos sejam concluídos com êxito antes de prosseguir com nosso caminho de execução.

Esse padrão também pode ser muito útil para integrar etapas manuais em um processo automatizado. Por exemplo, para permitir que um operador humano aprove ou rejeite uma solicitação para implantar nosso aplicativo depois que o commit for enviado ao GitHub.

Finalmente, você tem os estados Wait. O que pode adicionar uma quantidade configurável de atraso à execução e dificultar o teste de ponta a ponta. Por exemplo, se houver um estado de espera que espere por uma hora, seu teste também precisaria dormir por tanto tempo? E você ficaria feliz em esperar uma hora para executar todos os casos de teste em sua suíte de testes? Provavelmente não!

Todos esses fatores tornam o Step Functions notoriamente difícil de testar. Mas existem maneiras de superar esses desafios (pelo menos até certo ponto) e produzir casos de teste de alta qualidade.

Testando com Step Functions Local

Step Functions Local é um simulador local para Step Functions e pode executar nossas máquinas de estado localmente. Eu geralmente evito simuladores locais (como localstack) porque eles geralmente são mais problemáticos do que valem a pena. No entanto, abro uma exceção para Step Functions Local porque sua capacidade de simulação é quase uma necessidade se você deseja obter uma boa cobertura de teste para Step Functions.

Por padrão, o Step Functions Local executa os estados Task contra os serviços reais da AWS (por exemplo, S3 ou DynamoDB). Podemos substituir os endpoints dos serviços AWS na configuração do Step Functions Local.

Usando esse recurso, podemos substituir as chamadas de serviços por simulações locais durante a execução de nossos testes. Embora isso possa parecer útil, apenas um pequeno número de serviços é suportado e isso significaria que teríamos que usar outras ferramentas para simular esses serviços da AWS.

O mais importante, o Step Functions Local nos permite mockar a saída dos estados Task. Essas respostas simuladas devem ser fornecidas quando você inicia o Step Functions Local. Mas podemos usá-las para ajudar a conduzir a execução da máquina de estado por um caminho específico que queremos testar. Por exemplo, lançando o erro certo em um estado Tasks para nos ajudar a testar o caminho de erro em nossa máquina de estado. Ou fornecendo a saída certa de um estado Task que alimenta um estado Choice para ter certeza de que seguiríamos o ramo certo.

Problemas com Step Functions Local

Embora seja uma ferramenta útil e que você deve ter em seu kit, ainda existem alguns problemas notáveis com ela.

Não há garantia de que as chamadas simuladas funcionarão exatamente da mesma maneira que na produção. Este é um problema com todas as simulações e simuladores locais. Que eles não são uma réplica perfeita do ambiente de execução real e são propensos a apresentar atrasos e falsos negativos ou positivos.
Ele não simula o IAM e, portanto, não pode nos ajudar a detectar erros relacionados à permissão em nossa máquina de estado. Isso é importante, especialmente em uma máquina de estado complexa que interage com muitos serviços da AWS por meio de integrações diretas de serviço.
Não suporta a funcionalidade de avanço rápido através de um estado Wait ou simulando um tempo esgotado nos estados Task.
Por último e talvez o mais importante, ele não oferece suporte a referências do CloudFormation. Quando você cria uma máquina de estado no Step Functions Local, o ASL deve usar ARNs ao invés de referências do CloudFormation porque a máquina de estado não é implantada como parte de uma pilha do CloudFormation. Isso significa que você não pode usar referências a outros recursos na máquina de estado. Por exemplo, você não poderia fazer referência a um bucket do Amazon S3 se quisesse que sua máquina de estado gravasse dados nele.

Este último ponto cria atrito em seu fluxo de trabalho de desenvolvimento. Isso significa que "testar antes de deployar" não é realmente viável sem primeiro deployar o projeto e criar os recursos referenciados pela máquina de estado.

Teste de ponta-a-ponta

Para executar testes de ponta-a-ponta, precisamos deployar o projeto na AWS e criamos uma máquina de estado e todos os recursos aos quais ela faz referência. Em seguida, executaríamos a máquina de estado com diferentes entradas para cobrir diferentes caminhos.

No entanto, muitas vezes é difícil ou impossível cobrir todos os caminhos de execução usando testes de ponta-a-ponta. Por exemplo, uma lógica de ramificação pode depender do resultado de uma chamada de API para uma API de terceiros, como Stripe ou Paypal. Ou talvez um caminho de erro dependa do DynamoDB lançar um erro. Estes são apenas alguns exemplos de cenários que não podemos cobrir facilmente usando testes de ponta-a-ponta.

Para alguns desses cenários, podemos usar APIs simuladas e retornar resultados fictícios para nossa lógica de ramificação.

Por exemplo, você pode usar o Apidog para hospedar uma API Stripe simulada para testar o fluxo de pagamento de sua máquina de estado. Você também pode hospedar uma API simulada local e expô-la publicamente usando ngrok.

Em ambos os casos, não estamos realmente interagindo com a API real de terceiros. Portanto, qualquer falha em nossa lógica, isso não afetará nossos clientes, pois eles não receberão um pagamento com falha em um cartão de crédito real. Mas a API simulada nos informará que nossa lógica está falhando quando não deveria.

No entanto, precisamos de uma maneira de "convencer" nossa máquina de estado a usar a API fictícia em vez da API real de terceiros. Uma maneira de fazer isso é adicionar a URL da API fictícia como variável em tempo de execução, e fazer com que nossas funções do Lambda a usem sempre que for especificada.

Teste de componentes para as funções do Lambda

Se uma máquina de estado consistir principalmente de funções Lambda, podemos testar cada função separadamente usando técnicas de teste baseadas em componentes:

Encapsule a lógica do domínio em seus próprios módulos e escreva testes de unidade para eles.
Escreva testes de integração (também conhecidos como testes de usuário) que invoquem o código da função Lambda localmente, mas que se comuniquem com os serviços reais da AWS (sem simulações ou simuladores locais!). Esses testes permitem iterar rapidamente no código funcional sem precisar implantá-lo na AWS após cada alteração.
Depois de ganhar confiança com os testes locais, implante tudo na AWS e teste as funções do Lambda como parte dos testes de ponta-a-ponta na máquina de estado.

Para saber mais sobre essa abordagem para testar as funções Lambda, confira meu artigo: My strategy for testing serverless applications.

Ou, se você quiser um passo a passo mais aprofundado e ver isso em ação, confira meu novo curso "Testing Serverless Architectures".

Uma estratégia para testar Step Functions

Ok, até agora nós cobrimos os desafios com o teste de Step Functions e apresentamos três abordagens para testá-los:

Usando Step Functions Local.
Usando testes de ponta-a-ponta.
Teste de componentes em funções individuais do Lambda.

Vamos combiná-los para chegar a uma estratégia que nos dê o melhor de todas as três abordagens.

Primeiro, use o teste de componentes para as funções individuais do Lambda.

Em seguida, tente cobrir o maior número possível de caminhos de execução usando testes de ponta-a-ponta. No entanto, lembre-se de que os testes de ponta-a-ponta não podem cobrir todos os caminhos de execução possíveis para uma máquina de estado. Ou, no mínimo, será muito desafiador atingir 100% de cobertura com testes de ponta-a-ponta. Portanto, é provável que haja algumas lacunas em nossa cobertura de teste. Por exemplo, alguns caminhos de difícil acesso com Choice e caminhos de erro.

Finalmente, use Step Functions Local e respostas simuladas para preencher as lacunas na cobertura dos testes de ponta-a-ponta. Onde não podemos direcionar os testes de ponta-a-ponta para um caso de teste que queremos executar, podemos usar as respostas simuladas no Step Functions Local para direcionar a máquina de estado para esses caminhos de execução.

Mas espere!

O objetivo do Step Functions Local não é nos permitir testar nossas máquinas de estado localmente sem fazer o deploy na AWS?

Na prática, isso é muito difícil de conseguir porque ela não oferece suporte a referências do CloudFormation. Em vez disso, acho que a melhor maneira de usar o Step Functions Local é preencher as lacunas em nossos testes de ponta-a-ponta.

Neste caso, eu faria:

Faça o deploy da máquina de estado e todos os outros recursos dos quais ela depende na AWS. A máquina de estado deployada conteria os ARNs totalmente qualificados em vez das referências do CloudFormation.
Inicie o Step Functions Local com as respostas fictícias necessárias para meus casos de teste.
Crie a máquina de estado no Step Functions Local, usando a definição da máquina de estado que foi deployada.
Execute casos de teste no Step Functions Local.

A combinação de testes de ponta-a-ponta com o Step Functions Local dessa forma forneceria quase 100% de cobertura de todos os caminhos de execução.

No entanto, ainda pode haver algumas lacunas deixadas em nossa cobertura de teste. Especificamente, quando estados Wait e timeouts Task estão sendo testados. Como não é viável escrever casos de teste que teriam que esperar indefinidamente, e o Step Functions Local não oferece suporte ao avanço rápido por meio desses estados Wait. A única solução viável que encontrei é usar o Step Functions Local e reescrever o relevante estados Wait para esperar apenas um segundo.

Podemos fazer isso na etapa 3 acima, quando criamos a máquina de estado no Step Functions Local. O mesmo pode ser feito para diminuir os tempos limite e, portanto, tornar viável o teste dos caminhos de erro.

Finalizando

A estratégia que descrevi acima nos dá o melhor dos dois mundos — teste de ponta-a-ponta combinado com a execução local de alguns casos de teste que requerem atenção especial.

Espero que este post tenha sido útil para você. Se você quiser aprender mais sobre como testar arquiteturas serverless, incluindo Step Functions, verifique meu novo curso "Testing Serverless Architectures".

Se você se inscrever antes de 1º de janeiro de 2023, também poderá obter 30% de desconto com nosso desconto de acesso antecipado! Espero vê-lo no curso :-)

Créditos

Escrito originalmente por Yan Cui, em A practical guide to testing AWS Step Functions

Como é o fluxo de dados no Remix

Eduardo Rabelo — Fri, 03 Feb 2023 08:50:09 +0000

Quando o React apareceu pela primeira vez, um de seus recursos mais atraentes era seu "fluxo de dados unidirecional". Isso ainda está descrito nos documentos do React na página "Thinking in React".

O componente no topo da hierarquia receberá seus dados como props. Se você fizer uma alteração em seus dados e chamar root.render() novamente, a UI será atualizada. Você percebe como sua interface do usuário é atualizada e onde fazer alterações são feitas. O fluxo de dados unidirecional (também chamado de ligação unidirecional) do React mantém tudo modular e rápido.

A ideia é que os dados só possam fluir em um sentido através de seu aplicativo, o que, portanto, torna seu aplicativo muito mais fácil de intuir, entender e raciocinar.

Isso veio a ser resumido na frase: "UI é uma função do estado", ou ui = fn(state). Sempre que algum estado muda, devido a uma ação, a interface é renderizada novamente. Até o momento, várias soluções sofisticadas de "gerenciamento de estado" foram criadas para facilitar a construção de aplicativos com esse modelo mental.

Um problema raramente reconhecido aqui, no entanto, é que esse "fluxo de dados unidirecional" é um pouco impróprio. É realmente um fluxo de dados unidirecional no cliente. Mas ter dados exclusivamente no cliente raramente é prático. Na maioria das vezes, você precisa manter os dados - para sincronizá-los - o que significa que você precisa que os dados fluam de duas maneiras: entre o cliente e o servidor.

Ação -> Estado" enquadrado em um navegador à esquerda. À direita está uma ilustração de um servidor com um banco de dados. Duas setas conectam essas duas ilustrações denotando transferência de rede."/>

Muitas ferramentas de gerenciamento de estado ajudam você a gerenciar o estado apenas no cliente, mas não o ajudam a cruzar efetivamente o abismo da rede: a lacuna entre o estado no cliente e o estado no servidor.

Entra o Remix: "Um dos principais recursos do Remix é simplificar as interações com o servidor para obter dados em componentes." O Remix estende o fluxo de dados pela rede, tornando-o verdadeiramente unidirecional e cíclico: do servidor (estado), para o cliente (interface) e de volta ao servidor (ação).

Quando é dizemos que sua “UI é uma função do estado”, uma maneira de desembaraçar as suposições dessa afirmação seria: A UI é uma função do seu estado remoto e do seu estado local. Em um aplicativo React tradicional, todos os estados residem no cliente e as partes que você deseja persistir devem pular para fora do "fluxo de dados unidirecional" e ser sincronizadas na rede para um servidor. Como você pode imaginar, esta é uma área propensa a bugs.

No Remix, no entanto, a ideia de "UI como uma função do estado" é transformada porque o estado remoto pode ser mais facilmente separado do estado local. "Qual é a diferença", você pergunta? Pense desta maneira.

O "estado remoto" é qualquer dado que precisa persistir, como dados do usuário. Esse estado (por exemplo, quantas notificações não lidas o usuário tem?) é armazenado no cliente e reconciliado em seu aplicativo a partir de mecanismos Remix, como loaders e actions.

(Observação: o Remix ajuda você a cruzar o abismo da rede, fornecendo informações sobre o estado da transmissão de seus dados usando transitions e fetchers - não há necessidade de rastrear o status de cada solicitação de rede por meio de booleanos como isLoading ou enums como initial | loading | success | failed).

Por outro lado, o estado local são dados efêmeros que podem ser perdidos (por exemplo, por meio de uma atualização) sem afetar negativamente a experiência do usuário. Esse estado (por exemplo, o menu suspenso aberto que revela as notificações do usuário?) é armazenado no cliente por meio de mecanismos como useState em React ou local storage nos navegadores. É importante ressaltar que ele não precisa persistir e sincronizar pela rede (para o servidor), reduzindo assim a complexidade e o potencial de bugs.

Formulários, fetchers, loaders, actions, todos são soluções de “gerenciamento de estado” no Remix (embora não os chamemos assim). Eles fornecem as ferramentas para manter o estado persistente em sincronia entre o cliente e o servidor, garantindo que os dados fluam ciclicamente em um sentido único por meio de seu aplicativo e pela rede: de loaders a um componente para uma action e vice-versa.

Com o Remix, sua UI se torna uma função de estado em toda a rede, não apenas localmente. Uma analogia interessante com as abstrações de dados que o Remix fornece, é a abstração do DOM Virtual do React.

No React, você não se preocupa em atualizar o DOM sozinho. Você define o estado e o DOM Virtual faz toda a diferença para descobrir como fazer atualizações eficientes no DOM. O Remix estende essa idéia para a camada de API para persistir dados.

No Remix, você não se preocupa em manter o estado do lado do cliente sincronizado com o servidor. Você "define o estado" com uma mutação e os loaders assumem o controle para buscar novamente os dados mais atualizados e fazer atualizações em seus componentes de interface.

Espero que isso ajude a ilustrar como o Remix ajuda a reduzir drasticamente a quantidade de complexidade necessária para criar sites melhores. Como Kent disse em sua palestra no RenderATL, o Remix funciona antes do JavaScript, isso é uma vitória para seus usuários porque eles obtêm uma experiência de aprimoramento progressivo. Mas também é uma vitória para você como desenvolvedor, porque não precisa criar toda a complexidade tradicionalmente associada às soluções de gerenciamento de estado.

Você não precisa se preocupar com o gerenciamento de estados ao usar o Remix. Redux, Apollo, por mais legais que essas ferramentas sejam, você não precisa delas quando estiver usando o Remix porque nem precisamos de JavaScript do lado do cliente para que tudo funcione... pense no aplicativo que você está criando... e vamos fingir que você pode jogar fora todo o código que tem a ver com o gerenciamento de estado do aplicativo... é assim que funciona quando você trabalha com o Remix. Se funcionar sem JavaScript no navegador, isso significa que você não precisa de nada no navegador que exija gerenciamento de estado.

Crédios

Escrito originalmente por Jim Nielsen, em Data Flow in Remix.