Forem: Ewerton

Como eu penso e escrevo meus testes

Ewerton — Fri, 27 Mar 2026 18:19:51 +0000

Testes são uma parte fundamental do desenvolvimento de software. Eles nos ajudam a garantir que nosso código funcione como esperado e que possamos fazer alterações sem quebrar funcionalidades existentes.

Antes de criar uma aplicação, eu gosto de pensar em como vou testá-la. Isso me ajuda a projetar meu código de forma que ele seja mais fácil de testar.

Piramide de testes é uma forma de organizar os testes em uma aplicação. Ela é dividida em três camadas.
Na base temos os testes unitários, no meio os testes de integração e no topo os testes de ponta a ponta.

O próximo conceito de como escrever testes é o TDD (Test-Driven Development).
No TDD, escrevemos o teste antes de escrever o código. O fluxo é o seguinte:

Escreva um teste que falhe.
Escreva o código mínimo necessário para que o teste passe.
Refatore o código para que ele fique mais limpo e organizado.
Repita o processo.

Anatomia de um teste. Eu divido em 3 partes, setup, ação e verificação.

# setup
let(:user) { User.new(name: "Ewerton") }

# ação
user.save!

# verificação
expect(user).to be_persisted

Pensando em casos de uso, eu gosto de pensar em como o usuário vai interagir com o sistema.
O BDD (Behavior-Driven Development) é uma forma de escrever testes que foca no comportamento do sistema.
Eu usei bastante na minha carreira uma gem para testes chamada rspec. O rspec é uma biblioteca de testes para Ruby que implementa o BDD. Aqui eu penso em 3 palavras, Given, When e Then.

Given (Dado que): Eu tenho uma calculadora e os números 5 e 10.
When (Quando): Eu executo a operação de soma.
Then (Então): O resultado deve ser igual a 15.

RSpec.describe "Calculator" do
  describe "addition" do
    let(:calculator) { Calculator.new }

    context "when adding two positive numbers" do
      it "returns the sum of the two numbers" do
        result = calculator.add(5, 10)
        expect(result).to eq(15)
      end
    end
  end
end

class Calculator
  def add(a, b)
    a + b
  end
end

Esse exemplo é bem simples, mas ele ilustra bem o conceito de BDD. Isso é um pouco de como penso e como escrevo testes. Mas esses conceitos são um mundo a ser explorado. Não cabe em um único artigo e pretendo escrever mais sobre testes em breve.

Compartilhando Comportamentos usando Herança no Ruby

Ewerton — Tue, 17 Mar 2026 15:04:12 +0000

Um dos pilares da programação orientada a objetos é a herança, que é um conceito que permite que uma classe herde atributos e métodos de outra classe. No Ruby, a herança é feita usando o operador <.

Vamos criar uma classe base simples:

class Character
  def attack
    "Attack"
  end
end

O uso básico do `super`

O super é a palavra-chave usada para invocar um método da classe pai a partir de uma classe filha. Veja o exemplo de um Guerreiro (Warrior) que herda de Character:

class Warrior < Character
  def attack
    super + " with sword"
  end
end

Warrior.new.attack
#=> "Attack with sword"

Neste caso, chamar super funciona perfeitamente. A classe Warrior herda os métodos de Character e sobrescreve o método attack. A chamada para super executa o attack da classe pai.

A diferença entre `super` e `super()`

A confusão começa quando o método da classe filha exige argumentos que a classe pai não espera (ou vice-versa).

Por padrão, chamar apenas super invoca o método da classe pai repassando de forma implícita todos os mesmos argumentos que foram entregues ao método da classe filha.

Se tentarmos criar um Mago (Mage) cujo ataque recebe o nome de uma magia (spell), o uso apenas de super causará um erro:

class Mage < Character
  # O método filho espera 1 argumento (spell)
  def attack(spell)
    super # Isso automaticamente tentará passar o 'spell' para o método pai!
  end
end

Mage.new.attack("Fireball")
#=> "ArgumentError: wrong number of arguments (given 1, expected 0)"

O erro ArgumentError ocorre porque o argumento spell (no caso, "Fireball") foi repassado automaticamente por debaixo dos panos para o método Character#attack, mas a classe Character estava esperando zero argumentos.

Para resolver isso, precisamos usar super() com os parênteses:

class Mage < Character
  def attack(spell)
    super() + " with spell #{spell}"
  end
end

Mage.new.attack("Fireball")
#=> "Attack with spell Fireball"

Resumo:

super: Invoca o método da classe pai repassando exatamente os mesmos argumentos que o método atual recebeu.
super(): Invoca o método da classe pai explicitamente sem nenhum argumento, não importa quantos argumentos o método atual tenha recebido.

Como sempre, ser explícito no seu código é uma boa prática e evita comportamentos inesperados ao sobrescrever métodos!

Otimizando consultas no PostgreSQL Com Gin Index

Ewerton — Fri, 27 Feb 2026 19:11:44 +0000

O PostgreSQL é um dos sgbds que mais usei durante minha carreira. Ele é robusto, confiável e possui uma série de recursos avançados que o tornam uma escolha popular para muitos desenvolvedores. Um desses recursos é o suporte a tipos de dados JSON e JSONB, que permitem armazenar e consultar dados semi-estruturados de forma eficiente. Neste post, vamos explorar como usar o tipo JSONB em conjunto com o Gin Index para otimizar consultas no PostgreSQL.

O que é JSONB?

O JSONB é uma versão binária do tipo de dados JSON no PostgreSQL. Ele armazena os dados em um formato otimizado para consultas, o que o torna mais rápido do que o tipo JSON tradicional. O JSONB suporta operações de indexação, o que significa que você pode criar índices para acelerar as consultas em campos específicos dentro do JSONB.

Criando um índice Gin para JSONB

O índice Gin (Generalized Inverted Index) é uma estrutura de dados que permite indexar valores dentro de um campo JSONB. Ele é especialmente útil para consultas que filtram por atributos específicos dentro do JSONB, como no exemplo abaixo:

-- 1. Criação da Tabela
CREATE TABLE cards (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
    attributes JSONB
);

-- 2. Inserção de Dados
INSERT INTO cards (name, attributes)
SELECT 
    'Card ' || generate_series,
    jsonb_build_object(
        'type', 'Creature',
        -- Subtipo com poucas variações para aumentar a amostragem
        'subtype', (ARRAY['Dragon', 'Goblin', 'Human', 'Elf'])[floor(random() * 4 + 1)],
        'stats', jsonb_build_object(
            'power', floor(random() * 10),
            'toughness', floor(random() * 10)
        ),
        -- Habilidade rara: apenas 'Phasing' será fácil de filtrar
        'abilities', CASE 
            WHEN random() < 0.001 THEN jsonb_build_array('Phasing')
            ELSE jsonb_build_array('Flying')
        END
    )
FROM generate_series(1, 1000000);

SELECT * FROM CARDS LIMIT 3;
// id |  name   | attributes
// ---+---------+----------------------------------------------------------------------------------
//  1 | Card 1  | {"type": "Creature", "stats": {"power": 8, "toughness": 1}, "subtype": "Goblin", "abilities": ["Flying"]}
//  2 | Card 2  | {"type": "Creature", "stats": {"power": 0, "toughness": 3}, "subtype": "Elf", "abilities": ["Flying"]}
//  3 | Card 3  | {"type": "Creature", "stats": {"power": 7, "toughness": 4}, "subtype": "Human", "abilities": ["Flying"]}

-- Atualiza as estatísticas para o Planejador de Consultas
ANALYZE cards;

Agora vamos analizar o desempenho das consultas sem o índice e depois com o índice Gin.

-- Consulta sem índice
EXPLAIN ANALYZE
SELECT * FROM cards
WHERE attributes @> '{"type": "Creature", "subtype": "Dragon"}';

"Seq Scan on cards  (cost=0.00..36891.00 rows=179403 width=163) (actual time=0.037..944.492 rows=250022 loops=1)"
"  Filter: (attributes @> '{""type"": ""Creature"", ""subtype"": ""Dragon""}'::jsonb)"
"  Rows Removed by Filter: 749978"
"Planning Time: 0.303 ms"
"Execution Time: 1441.434 ms"

Veja que temos um scan sequencial na tabela, o que pode ser muito lento em tabelas grandes. Veja o Rows Removed by Filter, que indica que o PostgreSQL teve que ler todas as linhas da tabela para encontrar as correspondências.

Vamos criar o índice Gin e analisar a consulta novamente.

-- Criando o índice Gin
CREATE INDEX idx_cards_attributes ON cards USING gin (attributes);

-- Consulta com índice
EXPLAIN ANALYZE
SELECT * FROM cards
WHERE attributes @> '{"type": "Creature", "subtype": "Dragon"}';

"Bitmap Heap Scan on cards  (cost=2044.35..28677.89 rows=179403 width=163) (actual time=96.083..777.979 rows=250022 loops=1)"
"  Recheck Cond: (attributes @> '{""type"": ""Creature"", ""subtype"": ""Dragon""}'::jsonb)"
"  Heap Blocks: exact=24391"
"  ->  Bitmap Index Scan on idx_cards_attributes  (cost=0.00..1999.50 rows=179403 width=0) (actual time=92.507..92.509 rows=250022 loops=1)"
"        Index Cond: (attributes @> '{""type"": ""Creature"", ""subtype"": ""Dragon""}'::jsonb)"
"Planning Time: 0.388 ms"
"Execution Time: 1197.012 ms"

Agora temos um Bitmap Heap Scan, que é muito mais eficiente do que o Seq Scan. Não temos mais o Rows Removed by Filter, pois o índice Gin já filtrou as linhas relevantes, resultando em uma execução muito mais rápida da consulta. A diferença no tempo de execução é significativa, mostrando a importância de usar índices adequados para otimizar consultas em campos JSONB.

Conclusão

O uso do tipo JSONB em conjunto com o índice Gin pode melhorar significativamente o desempenho das consultas em campos JSONB no PostgreSQL. Ao criar um índice Gin, as consultas que filtram por atributos específicos dentro do JSONB podem ser executadas muito mais rapidamente, especialmente em tabelas com um grande volume de dados. Se você estiver trabalhando com dados semi-estruturados, considere usar JSONB e índices Gin para otimizar suas consultas e melhorar a performance do seu banco de dados.

O problema N+1

Ewerton — Mon, 23 Feb 2026 18:04:11 +0000

Performance é uma das minhas preocupações quando estou desenvolvendo uma aplicação. E um dos problemas mais conhecidos relacionado a performance é o problema N+1. Ele acontece quando temos uma consulta que retorna N registros, e para cada um desses registros, fazemos uma nova consulta para buscar informações relacionadas.

Por exemplo, imagine que temos um sistema de blog, onde temos uma tabela de posts e uma tabela de comentários. Se quisermos buscar todos os posts e seus comentários, podemos fazer uma consulta para buscar os posts, e para cada post, fazer uma nova consulta para buscar os comentários relacionados. Isso pode resultar em N+1 consultas, onde N é o número de posts.

Imagine que temos 100 posts, isso significa que teremos 1 consulta para buscar os posts e 100 consultas para buscar os comentários, totalizando 101 consultas. Isso pode ser um grande problema de performance, especialmente se o número de posts for muito grande.

Exemplo:

SELECT * FROM posts; -- 1 consulta para buscar os posts
SELECT * FROM comments WHERE post_id = 1; -- 1 consulta para cada post
SELECT * FROM comments WHERE post_id = 2;
...
SELECT * FROM comments WHERE post_id = 100;

Podemos resolver esse problema com o IN, fazendo uma única consulta para buscar os comentários relacionados a todos os posts de uma vez.

SELECT * FROM posts; -- 1 consulta para buscar os posts
SELECT * FROM comments WHERE post_id IN (1, 2, ..., 100); -- 1 consulta para buscar os comentários relacionados a todos os posts

Dessa forma, reduzimos o número de consultas de N+1 para apenas 2, melhorando significativamente a performance da aplicação.

No Rails, por exemplo, podemos usar o método includes para evitar o problema N+1. Ele faz um eager loading dos registros relacionados, evitando consultas adicionais para cada registro.

posts = Post.includes(:comments).all

O que o include faz por debaixo dos panos:

SELECT * FROM posts; -- 1 consulta para buscar os posts
SELECT * FROM comments WHERE post_id IN (1, 2, ..., 100); --

Uma ferramenta que usso para indentificar o problema N+1 é o Bullet, uma gem para Rails que detecta consultas N+1 e outras consultas ineficientes, alertando o desenvolvedor para que ele possa corrigir o problema.

Em resumo, o problema N+1 é um problema de performance no backend. Mas que pode ser evitado com boas práticas de desenvolvimento e ferramentas de detecção.

Entendendo o JSON Web Token (JWT)

Ewerton — Wed, 24 Dec 2025 20:48:12 +0000

Em algum momento, ao criar uma aplicação web, precisamos desenvolver uma solução de autenticação para o sistema. Existem várias estratégias para isso, como autenticação por senha,tokens, OAuth, entre outras.

Nesse post, vou falar apenas sobre o JWT (JSON Web Token), uma abordagem bastante utilizada no desenvolvimento de APIs.

O JWT é um padrão aberto usado para transmitir informações de forma compacta e segura entre partes usando JSON. Uma de suas características é ser stateless, ou seja, o servidor não precisa armazenar nenhuma informação sobre a sessão do usuário. Todas as informações nescessárias estão contidas no próprio token.

Essa abordagem é especialmente útil em aplicações onde o backend e o frontend estão separados, como em aplicações mobile e SPAs (Single Page Applications).

Anatomia do JWT

O JWT é composto por três partes, header, payload e assinatura separados por um ponto (.).

xxxxx.yyyyy.zzzzz

Header

O Header tem duas partes. O tipo do token, que é jwt e o algoritimo de assinatura utilizado. Tais como HMAC SHA256 ou RSA.

Exemplo:

{
  "alg": "HS256",
  "typ": "JWT"
}

Em seguida esse Json é codificado para Base64Url para formar a primeira parte do JWT.

Payload

A segunda parte do jwt é o payload, um objeto json com as informações da entidade tratada, geralmente é um user.

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

Signature

A terceira parte do jwt é a assinatura. Ela é formada pelo header mais o payload encodados em Base64Url e um secret. A assinatura é a parte mais importante do jwt pois é ela que garante a integridade do nosso token.

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

Colocando tudo junto o jwt ficaria assim:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.KMUFsIDTnFmyG3nMiGM6H9FNFUROf3wh7SmqJp-QV30

Como validamos a Assinatura?

Quando o servidor recebe o token, ele inicia um processo de verificação para garantir que aquelas informações são legítimas. Em vez de tentar "descriptografar" a assinatura, o servidor opta por reconstruí-la. Ele separa o Header e o Payload enviados pelo usuário e, utilizando a sua própria Secret (chave secreta) guardada no ambiente seguro do backend, aplica novamente o algoritmo de hash.

O resultado desse cálculo gera uma nova assinatura que é então comparada com a assinatura que veio originalmente no token. Se ambas forem exatamente iguais, o servidor tem a prova matemática de que o token é íntegro e pode confiar nos dados contidos ali.

JavaScript

const novaAssinatura = hash(`${headerSent}.${payloadSent}`, 'sua_secret_aqui');

if (novaAssinatura === signatureSent) {
  // O token é íntegro e válido!
}

Se uma pessoa mal-intencionada interceptar um token JWT e tentar alterar o role no payload — por exemplo, mudando de user para admin — qualquer modificação em um único caractere fará com que a assinatura original deixe de ser válida, e o token será rejeitado pelo servidor.

Para que o servidor aceitasse essa alteração, o atacante precisaria gerar uma nova assinatura que batesse com o novo conteúdo. No entanto, como a assinatura depende obrigatoriamente da Secret para ser gerada, e essa chave só o servidor possui, o invasor não consegue concluir o ataque. Sem a chave secreta, qualquer tentativa de alteração resulta em uma assinatura inválida, e o sistema bloqueia o acesso imediatamente.

O JWT é uma ferramenta poderosa para a autenticação , especialmente por ser stateless. Isso permite que sua aplicação escale facilmente, já que o servidor não precisa consultar um banco de dados de sessões a cada requisição.

No entanto, lembre-se o JWT protege a integridade dos dados, mas não a sua privacidade (já que o payload é visível). Portanto, mantenha sua Secret bem guardada, nunca armazene informações sensíveis como senhas dentro do token, crie uma secret que não seja fácil de ser quebrada com brute force. Com esses cuidados, o JWT se torna uma solução robusta e eficiente para o controle de acesso da sua API.

Blocos, Procs e Lambdas no Ruby

Ewerton — Wed, 04 Jun 2025 21:45:42 +0000

Ruby é famoso por sua sintaxe elegante e recursos poderosos, entre eles os Blocos, Procs e Lambdas. Se você está começando com Ruby ou quer reforçar o entendimento, este post vai ajudar a esclarecer o que são esses recursos, como funcionam, e quando usá-las.

Blocos

Um bloco é um pedaço de código que pode ser passado para um método. Um exemplo bastante comum é seu uso em iterações, como no método each. Podemos usar blocos tanto inline, com os caracteres {}, quanto em múltiplas linhas, com do .. end.

array = [1, 2, 3]

array.each{ |item| p item }

array.each do |item|
  p item
end

Procs

Procs são objetos que encapsulam blocos de código. Eles são flexíveis quanto à passagem de argumentos:

Se passarmos mais argumentos do que o esperado, os extras são ignorados.
Se não passarmos o argumento esperado, a execução continua normalmente.

my_proc = Proc.new { puts 'my proc' } # ou proc {puts 'my proc'}
my_proc.call

my proc
=> nil


other_proc = Proc.new { |x| "x is #{x}"  }
other_proc.call(2)
=> "x is 2"
other_proc.call
=> "x is "

other_proc.call(5,2)
=> "x is 5"

Lambdas

Se nenhum argumento for passado, um erro será exibido.
Lambdas são muito parecidas com Procs, mas são estritas em relação aos argumentos. Se você não passar o número exato de argumentos, um erro será gerado.

my_lambda = lambda { |x| "x is #{x}" }
my_lambda.call()

 `block in <top (required)>': wrong number of arguments (given 0, expected 1) (ArgumentError)`

Conclusão

Em resumo, blocos, procs e lambdas oferecem formas poderosas e flexíveis de lidar com trechos de código em Ruby. Os blocos são ideais para usos rápidos, como em iterações, enquanto procs permitem reutilizar lógica de forma mais solta, sem tanta preocupação com os argumentos. Já as lambdas se comportam de maneira mais próxima às funções tradicionais, garantindo que os parâmetros sejam respeitados com rigor.

Entender essas diferenças ajuda não só a escrever um código mais limpo e expressivo, mas também a fazer escolhas mais conscientes em projetos reais. Com o tempo e a prática, você vai perceber que esses conceitos são fundamentais para aproveitar todo o potencial da linguagem Ruby.

Como os Sites Evoluíram

Ewerton — Wed, 05 Mar 2025 19:10:12 +0000

Este é o meu primeiro post neste blog, e para construí-lo estou usando o Jekyll, um gerador de sites estáticos (SSG). Mas, afinal, o que significa um SSG? 🤔

Um SSG (Static Site Generator) é uma abordagem onde todas as páginas do site são geradas de forma estática no momento da build, antes mesmo de um usuário acessá-las. Isso significa que, ao invés de processar cada requisição no servidor, o site já está pronto e é entregue como arquivos HTML estáticos. O resultado? Um carregamento muito mais rápido, menor consumo de recursos no servidor .

Mas os sites sempre funcionaram dessa forma? Não! A forma como servimos conteúdo na web evoluiu bastante ao longo do tempo. Antes das abordagens modernas como SPA (Single Page Application) e SSR (Server-Side Rendering), os sites eram renderizados de maneira muito diferente.

O Início da Web com Sites Tradicionais e o Surgimento do AJAX

No começo da web, a maioria dos sites funcionava com uma abordagem clássica: cada clique em um link ou envio de formulário resultava no carregamento de uma nova página pelo servidor. Isso era simples, mas tornava a navegação lenta e pouco interativa.

A grande revolução veio com o AJAX (Asynchronous JavaScript and XML). Com essa técnica, os sites puderam buscar e atualizar informações sem precisar recarregar a página inteira. Isso trouxe um nível de interatividade antes impensável.

Um Exemplo famoso que popularizarou o AJAX foi o Gmail. Nele você conseguia visualizar e enviar emails sem precisar atualizar a página.

O AJAX abriu caminho para uma experiência mais dinâmica, mas ainda exigia muitos cuidados no gerenciamento das requisições. Isso levou à evolução para algo ainda mais avançado: as Single Page Applications (SPAs).

O Próximo Passo na Evolução com SPAs

As Single Page Applications (SPAs) levaram a ideia do AJAX ainda mais longe. Em vez de carregar páginas inteiras, elas carregam apenas uma única página inicial e usam JavaScript para atualizar o conteúdo dinamicamente conforme o usuário navega.

Isso tornou a experiência muito mais fluida e interativa, já que não há recarregamento completo da página. Frameworks como React, Vue e Angular popularizaram esse modelo, permitindo que desenvolvedores criassem aplicações altamente dinâmicas.

OK. Mas como funciona uma SPA?

O usuário acessa a aplicação e o navegador baixa um único arquivo HTML junto com os scripts JavaScript e CSS.
O JavaScript da página solicita dados do servidor via API (normalmente em JSON).
A aplicação atualiza dinamicamente o conteúdo exibido, sem precisar recarregar a página inteira.

Exemplo real: Quando você navega pelo Gmail, o conteúdo dos e-mails muda sem que a página toda precise ser recarregada. Isso acontece porque o frontend faz chamadas assíncronas para buscar apenas os dados necessários.

Vantagens das SPAs:

Navegação rápida após o primeiro carregamento.
Melhor experiência do usuário, sem recarregamentos constantes.

Desvantagens das SPAs:

SEO mais difícil, já que o conteúdo é carregado via JavaScript.
Tempo de carregamento inicial pode ser maior.

O Retorno do SSR

O Server-Side Rendering (SSR) resolve algumas das limitações das SPAs ao renderizar as páginas no servidor antes de enviá-las ao navegador. Isso melhora o tempo de carregamento e, principalmente, o SEO, já que os motores de busca conseguem indexar melhor o conteúdo já renderizado.

Frameworks modernos como Next.js trouxeram o melhor dos dois mundos, permitindo combinar SSR e SPA dentro do mesmo projeto.

Diferente das SPAs, que carregam um HTML básico e preenchem o conteúdo via JavaScript, o Server-Side Rendering (SSR) gera a página no servidor antes de enviá-la ao navegador. Assim, o usuário recebe um HTML pronto, sem depender do carregamento do JavaScript para visualizar o conteúdo.

Como funciona o SSR?

O usuário acessa a aplicação e o navegador faz uma requisição ao servidor.
O servidor busca os dados (ex.: do banco de dados) e gera um HTML pronto.
Esse HTML é enviado ao navegador e exibido imediatamente.

Exemplo no Rails: Em um app Rails tradicional com ERB Views, cada requisição a uma rota (/posts/1) faz o servidor buscar o post no banco e renderizar a view (show.html.erb) antes de enviá-la ao navegador. Isso garante que o HTML já chegue pronto ao usuário .

Por que o SSR é útil?

SEO muito melhor, pois o conteúdo chega pronto para os motores de busca.
Primeiro carregamento mais rápido. Por outro lado, o SSR pode aumentar a carga no servidor e exigir um backend mais robusto.

Com o tempo, diferentes abordagens surgiram para melhorar a forma como servimos conteúdo na web. O AJAX trouxe interatividade, as SPAs transformaram a navegação, e o SSG e SSR equilibraram performance e SEO. Hoje, a escolha da abordagem ideal depende das necessidades de cada projeto e das prioridades do desenvolvedor.

Forem: Ewerton

Como eu penso e escrevo meus testes

Compartilhando Comportamentos usando Herança no Ruby

O uso básico do super

A diferença entre super e super()

Otimizando consultas no PostgreSQL Com Gin Index

O que é JSONB?

Criando um índice Gin para JSONB

Conclusão

O problema N+1

Entendendo o JSON Web Token (JWT)

Anatomia do JWT

Header

Payload

Signature

Como validamos a Assinatura?

Blocos, Procs e Lambdas no Ruby

Blocos

Procs

Lambdas

Conclusão

Como os Sites Evoluíram

O Início da Web com Sites Tradicionais e o Surgimento do AJAX

O Próximo Passo na Evolução com SPAs

O Retorno do SSR

O uso básico do `super`

A diferença entre `super` e `super()`