Introduction

Today I was working on a feature when a colleague asked me for help. He showed me a log that looked obvious at first: context canceled. One of those errors that usually points in a clear direction.

I gave a few debugging tips and went back to my task. A while later, he came back. The issue was still there.

The code was simple in theory. Two API calls ran concurrently, their results were combined, and a third API call used that data. The first two calls worked fine. The third one failed every time, logging context canceled.

That’s when it stopped making sense.

We checked the usual things: API logic, gRPC cancellations, timeouts, early returns. Nothing explained the behavior.

The problem wasn’t where we were looking.

Let’s walk through the scenario.

The situation

Imagine a function called DoSomething. It receives a context.Context, starts two goroutines using errgroup, waits for both of them to finish, and then calls a third API.

Conceptually, it looks like this: API 1 and API 2 run in parallel, return some data, and API 3 consumes that data.

Here is a simplified version of the code:

func DoSomething(ctx context.Context) error {
    // some fancy logic
    // ...

    // let's make some concurrent API calls
    g, ctx := errgroup.WithContext(ctx)

    var r1, r2 string
    g.Go(func() error {
        resp, err := CallAPI1(ctx)
        if err != nil {
            return err
        }
        r1 = resp
        return nil
    })
    g.Go(func() error {
        resp, err := CallAPI2(ctx)
        if err != nil {
            return err
        }
        r2 = resp
        return nil
    })
    if err := g.Wait(); err != nil {
        slog.Error("oh not something happened", "err", err)
        return err
    }

    // now let's use the data to make a third API call
    if _, err := CallAPI3(ctx, r1, r2); err != nil {
        slog.Error("api3 call failed", "err", err)
        return err
    }
    return nil
}

When this runs, API 1 and API 2 behave as expected. But API 3 fails and logs something like:

api3 call failed: context canceled

At this point, the natural reaction is to blame the context. But which cancellation are we actually dealing with?

What errgroup.WithContext really does

The library errgroup is a Go abstraction built on top of sync.WaitGroup that adds error propagation and context cancellation to concurrent workflows. With a WaitGroup, you can wait for multiple goroutines to finish, but you have to manage errors and cancellation manually. errgroup, on the other hand, lets each goroutine return an error, and the first non-nil error automatically causes Wait() to return that error and cancels a derived context shared by the group. In practice, this makes errgroup a better fit when goroutines are part of the same logical operation and should stop together on failure, while WaitGroup is more appropriate when you only care about synchronization and lifecycle, not shared failure semantics.

errgroup.WithContext does two things. It creates a group that waits for multiple goroutines, and it also returns a derived context. That derived context is canceled as soon as any goroutine in the group returns a non-nil error.

This is a powerful abstraction. It lets all goroutines stop early when one of them fails. But it also introduces a new context into the function, one that has very specific cancellation semantics.

And this is where the problem starts to take shape.

Notice this line again:

g, ctx := errgroup.WithContext(ctx)

At a glance, it looks harmless. But now the function has lost something important: there is no longer a clear distinction between the context that was passed into DoSomething and the context controlled by the errgroup.

The third API call is no longer using the original context. It’s using the errgroup context.

The subtle mistake

The issue here is not concurrency. It’s not the APIs. It’s not even errgroup itself.

The issue is variable shadowing. The classic shadowing mistake that was not spotted by a heavy golangci-lint pipeline.

By reusing the name ctx, the original context passed into DoSomething is replaced by the context returned by errgroup.WithContext. From that point on, every use of ctx refers to the group-controlled context.

When one of the goroutines returns an error, g.Wait() returns that error and, as part of its contract, cancels the errgroup context. That cancellation is correct and expected. But why was this returning a context cancelled if the API 1 and API 2 were working as expected?

That happened because the g.Wait() cancells the context after it is done. Meaning the context is always cancelled when the concurrent operation is over.

So the failure is not mysterious at all. API 3 is doing exactly what it should: it refuses to make a network request with a canceled context.

Why this is easy to miss in Go

Go makes shadowing easy to use — and easy to misuse — because it is a deliberate language feature, not an accident.

Shadowing happens when a variable declared in an inner scope has the same name as a variable in an outer scope. From that point on, the inner variable hides the outer one until the scope ends. Go allows this, and in many cases it’s idiomatic and even desirable.

The := operator is where this usually shows up. Depending on scope, it can introduce a new variable or reuse an existing one. A very common pattern looks like this:

ctx := context.Background()

if needsTimeout {
    ctx, cancel := context.WithTimeout(ctx, time.Second)
    defer cancel()
    callSomething(ctx)
}
callSomethingElse(ctx)

At first glance, this looks reasonable. Inside the if, we create a context with a timeout. Outside of it, we keep using ctx.

But that’s not what actually happens.

Inside the if, a new ctx is created. It shadows the outer one. When the block ends, that inner context is gone, and callSomethingElse receives the original context.Background(), not the timeout-bound context you might assume was propagated.

This is fine when you understand exactly how scope works. The danger is that the code reads as if ctx is being “updated”, when in reality it’s being replaced temporarily.

Now combine this behavior with something like errgroup.WithContext, where the returned context has very specific cancellation semantics. Reusing the same variable name makes it easy to forget that you’re no longer dealing with the original context at all.

Contexts are not just values. They encode ownership and lifetime. Shadowing them doesn’t just hide a variable — it hides a change in control flow. And that’s how bugs like “why is my context already canceled?” slip into otherwise clean-looking Go code.

The fix and the lesson

The fix is simple: give the errgroup context its own name.

func DoSomething(ctx context.Context) error {
    // some fancy logic
    // ...

    // let's make some concurrent API calls with the correct context
    g, gctx := errgroup.WithContext(ctx)

    var r1, r2 string
    g.Go(func() error {
        resp, err := CallAPI1(gctx)
        if err != nil {
            return err
        }
        r1 = resp
        return nil
    })
    g.Go(func() error {
        resp, err := CallAPI2(gctx)
        if err != nil {
            return err
        }
        r2 = resp
        return nil
    })
    if err := g.Wait(); err != nil {
        slog.Error("oh not something happened", "err", err)
        return err
    }

    // now let's use the data to make a third API call
    if _, err := CallAPI3(ctx, r1, r2); err != nil {
        slog.Error("api3 call failed", "err", err)
        return err
    }
    return nil
}

Now the code documents intent. Goroutines use gctx, and the developer is forced to make an explicit decision about which context to use after g.Wait().

More importantly, the lesson is not “never shadow variables.” It’s to be very deliberate when you do. Shadowing a simple value like an integer is rarely a problem. Shadowing something with behavior and lifetime, like a context, is where bugs quietly appear.

Conclusion

This bug wasn’t caused by concurrency being hard or Go being tricky. It was caused by a small naming decision that blurred an important boundary.

When reading or writing Go code, pay attention to where variables come from and what they represent over time. Especially with context.Context, the name you choose is part of the design.

Most of the time, Go does exactly what you tell it to do. The challenge is making sure you’re telling it the right thing.

See you on the next one! Bye!

The Go programming language is powerful and versatile. You can build anything from web applications to network services, cloud software, CLI tools, and even some systems programming tasks. The beauty of Go lies in its simplicity — but that doesn’t mean the language itself is simple. Its simplicity comes from carefully designed abstractions.

One important design choice in Go is how values are passed between functions. At first glance, it seems like you can pass things either by value or by reference. But in reality, Go passes everything by value.

That statement might feel confusing. After all, you can pass pointers in Go, and modifying data through them changes the original. So why does Go say everything is passed by value? Let’s break it down with examples.

Passing Structs by Value

When you pass a struct directly to a function, Go makes a copy of that struct. Any modification inside the function won’t affect the original value.

The output will be:

Inside function: {Alice 26}
Outside function: {Alice 25}

Here, the struct was passed by value — a copy was created.

Passing Structs with Pointers

If you need to modify the struct inside the function, you can pass a pointer to it.

The output will be:

Inside function: {Alice 26}
Outside function: {Alice 26}

Now the function updates the original value because we passed a pointer.

Pointers Are Still Passed by Value

When you pass a struct directly to a function, Go makes a copy of that struct. Any modification inside the function won’t affect the original value.

The output will be:

Pointer value outside function (address of user): 0x1400012c000
Pointer variable address outside function: 0x14000104030
Pointer value inside function (address of user): 0x1400012c000
Pointer variable address inside function: 0x14000104040

Notice that the memory addresses from the user are printed the same, but when it's printed the memory address of the pointer itself, it is different. That happens because the pointer was copied.

This would look like in the computer memory:

Maps and Slices Work the Same Way

Go’s built-in data structures also follow this rule. Take maps, for example. When you pass a map to a function, the map header (a small struct containing pointers) is copied, but both copies still point to the same underlying data.

The map is passed by value, but since the underlying data is shared, modifications are visible outside.

Slices behave similarly: the slice header (pointer, length, capacity) is copied, but the underlying array is shared.

Conclusion

Go always passes values by value. The trick is that sometimes what’s copied is a pointer, as in the case of maps, slices, and explicit pointer usage. This design choice keeps the language simple and predictable:

• Structs → copied fully when passed by value.
• Pointers → the pointer itself is copied, but both point to the same memory.
• Maps and slices → their headers are copied, but the underlying data is shared.

This reflects Go’s philosophy: simplicity doesn’t mean easy; it means clear and consistent.

Todo desenvolvedor, em algum momento, precisará entender e saber as implicações das race conditions no desenvolvimento de aplicações, especialmente no backend ao interagir com bancos de dados.

Imagine sua conta bancária com saldo de R$ 100. Agora, você recebe um PIX no valor de R$ 200 e, no mesmo instante, realiza uma compra no débito de R$ 50. Se ambas as operações acessarem o saldo ao mesmo tempo, e a race condition não for tratada na aplicação e no banco de dados, o saldo poderia resultar em um valor incorreto. A primeira operação consulta o saldo de R$ 100 e, após o crédito, resulta em R$ 300, finalizando a operação. Já a segunda operação, ocorrendo simultaneamente, também lê o saldo de R$ 100 e, após o débito, resulta em R$ 50 de saldo definitivo na conta, desconsiderando o crédito anterior e causando uma inconsistência no saldo persistido no banco de dados.

As race conditions ocorrem quando múltiplas operações acessam e modificam dados simultaneamente, sem a devida sincronização. O resultado pode ser imprevisível, causando erros como dados inconsistentes no banco ou falhas no sistema.

Para resolver esse problema, existem duas abordagens comuns: a gestão otimista e a gestão pessimista de race conditions.

📊 Gestão Pessimista

Na gestão pessimista, a aplicação assume que as operações concorrentes causarão conflitos, então ele bloqueia o recurso compartilhado até que uma operação finalize seu uso. Esse tipo de controle garante que, enquanto uma transação está sendo processada, nenhuma outra pode acessar o recurso, eliminando a possibilidade de race conditions.

Exemplo em SQL:

BEGIN;
SELECT saldo FROM contas WHERE id = 1 FOR UPDATE;
-- Atualiza o saldo com base na lógica de crédito ou débito
UPDATE contas SET saldo = saldo + 200 WHERE id = 1;
COMMIT;

No exemplo acima, o comando FOR UPDATE garante que o saldo da conta está bloqueado para outras transações enquanto a operação atual está sendo executada, evitando que outra transação leia ou escreva no mesmo registro até que o COMMIT seja realizado.

🚀 Gestão Otimista

Na gestão otimista, a aplicação assume que conflitos são raros e permite que as operações concorram pelo recurso sem bloqueios explícitos. Quando uma operação é finalizada, a aplicação verifica se o dado foi modificado durante a transação. Caso tenha sido, a operação falha e a aplicação deve tentar novamente ou abortar.

A gestão otimista é mais eficiente em cenários onde o conflito de concorrência é raro, já que as transações podem ser executadas simultaneamente sem bloqueios. Contudo, ela exige um mecanismo de controle de versões ou verificação de mudanças para detectar conflitos.

Exemplo com controle de versão (usando uma coluna versao no banco):

BEGIN;
SELECT saldo, versao FROM contas WHERE id = 1;
-- Verifica se a versão é a mesma antes de atualizar
UPDATE contas SET saldo = saldo + 200, versao = versao + 1 WHERE id = 1 AND versao = 1;
COMMIT;

Aqui, a coluna versao é usada para garantir que a transação só será bem-sucedida se o registro não foi alterado por outra operação concorrente. Caso a versao tenha mudado, a transação falha e pode ser repetida ou abortada.

Exemplo em Go com SQL otimista

No Go, podemos implementar a estratégia de controle otimista ao usar uma função que tenta realizar a operação e lida com o erro caso haja um conflito:

package main

import (
    "database/sql"
    "fmt"
    "log"
    _ "github.com/lib/pq"
)
func updateSaldo(db *sql.DB, id int, amount int) error {
    tx, err := db.Begin()
    if err != nil {
        return err
    }
    defer tx.Rollback()
    var saldo int
    var versao int
    err = tx.QueryRow("SELECT saldo, versao FROM contas WHERE id = $1", id).Scan(&saldo, &versao)
    if err != nil {
        return err
    }
    // Tenta atualizar o saldo e a versão
    res, err := tx.Exec("UPDATE contas SET saldo = $1, versao = versao + 1 WHERE id = $2 AND versao = $3", saldo+amount, id, versao)
    if err != nil {
        return err
    }
    rowsAffected, err := res.RowsAffected()
    if err != nil {
        return err
    }
    if rowsAffected == 0 {
        return fmt.Errorf("Conflito de versão, tente novamente")
    }
    return tx.Commit()
}
func main() {
    connStr := "user=postgres dbname=teste sslmode=disable"
    db, err := sql.Open("postgres", connStr)
    if err != nil {
        log.Fatal(err)
    }
    err = updateSaldo(db, 1, 200)
    if err != nil {
        fmt.Println("Erro ao atualizar saldo:", err)
    } else {
        fmt.Println("Saldo atualizado com sucesso")
    }
}

No exemplo acima, utilizamos a abordagem otimista. Caso a versão do registro tenha sido modificada por outra transação, a aplicação retorna um erro, indicando que a operação precisa ser repetida.

Conclusão

Race conditions podem ser críticas ao desenvolver sistemas concorrentes e, para tratá-las, é essencial escolher a estratégia correta. A gestão pessimista funciona bem quando há uma alta probabilidade de conflitos, já que bloqueia o acesso ao recurso. Já a gestão otimista é mais eficiente quando os conflitos são raros, permitindo maior paralelismo nas operações.

Ao lidar com banco de dados e sistemas de alta concorrência, sempre considere a melhor abordagem para garantir a integridade e consistência dos dados.

Por trás de cada linha de código em um simples programa feito em alguma linguagem de programação há vasto mundo complexo que foi pensado em detalhe em como podemos criar coisas no mundo da computação, e nesse mundo de engenharia de software não há um certo ou errado, apenas trocas (i.e. trade-offs) de cada escolha. Seja uma linguagem de programação interpretada, compilada ou entre outras que podem combinar ambas abordagens.

Aqui vamos explorar um pouco mais sobre linguagem de programação interpretada, desvendando sua arquitetura interna e entendendo como ela difere das linguagens compiladas. Vamos utilizar Python como um exemplo, mas os conceitos são similares para outras linguagens interpretadas.

Compilado vs Interpretado

Uma linguagem de programação interpretada executa o código fonte linha por linha em tempo real, traduzindo e executando cada instrução conforme encontrada. Isso permite rápida prototipagem e facilita a depuração, mas pode resultar em um desempenho geralmente mais lento. Por outro lado, uma linguagem compilada, como por exemplo Go, traduz todo o código fonte em código de máquina antes da execução, produzindo um programa executável independente, especifico para aquela arquitetura de hardware e o sistema operacional em que será executado, então, por exemplo, um binário para Windows não irá rodar em um MacOS, e um binário para MacOS compilado para processador x86–64 da Intel, não funcionará para os MacOS maios novos com processador ARM64 da Apple. Já as linguagens interpretadas abstraem a complexidade com um interpretador, e esse será responsável por ser compatível com determinado hardware e sistema operacional, trazendo uma vantagem em portabilidade entre plataformas do código escrito.

Linguagem Dinamicamente Tipada vs Estaticamente Tipada

Outra distinção importante entre linguagens de programação é se elas são dinamicamente ou estaticamente tipadas. Em linguagens dinamicamente tipadas, como Python, os tipos das variáveis são associados aos valores em tempo de execução. Isso significa que você não precisa declarar explicitamente o tipo de uma variável ao criar ou atribuir um valor a ela. Por exemplo, em Python, você pode simplesmente escrever valor = 10 sem especificar o tipo de valor, e o interpretador Python entenderá que valor é um inteiro(int). Por outro lado, em linguagens estaticamente tipadas, como Go ou C++, você precisa declarar o tipo de uma variável explicitamente antes de usar, como var valor int = 10. Isso geralmente é feito durante a compilação do código. Embora as linguagens dinamicamente tipadas ofereçam mais flexibilidade e facilidade de uso em alguns casos, elas tendem a introduzir bugs sutis no código que só serão percebidos durante a execução do programa. As linguagens estaticamente tipadas podem oferecer melhor desempenho e segurança, já que os erros de tipo são detectados em tempo de compilação em vez de em tempo de execução. Cada abordagem tem seus próprios prós e contras, lembre-se, não há certo ou errado, somente há trade-offs em engenharia de software. A escolha entre elas geralmente depende das necessidades específicas do projeto.

Arquitetura Interna de Uma Linguagem Interpretada

Para fins didáticos, vamos utilizar o Python como exemplo, dado que a estrutura pode variar levemente entre linguagens. Considere o código a seguir:

Quando esse executado em um computador, o processo ocorre da seguinte forma:

1. Escrevendo o Código: O processo começa com a pessoa desenvolvedora escrevendo o código em um editor de texto, como por exemplo VS Code, e salvando-o como um arquivo com extensão .py.
2. Interpretador do Python: O código é enviado para o interpretador, que é responsável por executar o programa, ele consiste em duas partes: o compilador e Máquina Virtual Python (PVM). O compilador, que converte o código Python em byte code, conhecido pela extensão .pyc e a PVM executa esse byte code, seguindo as instruções uma por uma.
3. Bibliotecas / Módulos: Se o código utilizar módulos de biblioteca do Python, como por exemplo import requests , esses também serão convertidos em byte code e executados pelo PVM.
4. Do Byte Code para o Código de Máquina: O byte code é então convertido em código de máquina, que é entendido diretamente para o especifico processador (CPU) do computador, como por exemplo um ARM64 do MacOS. Após a conversão para código de máquina, o computador usa esse código para executar o programa.

Este processo é repetido cada vez que o programa é executado. Ele pode ser resumido na imagem abaixo:

É importante mencionar que estamos utilizando apenas um exemplo para fins didáticos, há vários pontos de complexidade que são abstraídos nesse processo, lembre-se que cada linguagem de programação tem seu “mundo”, assim como cada sistema operacional e por ai vai.

Conclusão

Por trás de cada linha de código, há um vasto mundo de decisões e compromissos que foram cuidadosamente considerados para permitir que os programadores desenvolvam soluções eficientes e robustas para uma ampla variedade de problemas.

A distinção entre linguagens compiladas e interpretadas, bem como entre linguagens dinamicamente e estaticamente tipadas, ressalta a diversidade de abordagens disponíveis para os desenvolvedores e as trocas inerentes a cada escolha. Não há uma solução única ou correta, mas sim uma série de trade-offs que devem ser ponderados de acordo com as necessidades específicas de cada projeto. Lembre-se de escolher bem conforme cada necessidade.

Por fim, espero que esse entendimento de como as linguagens de programação interpretadas funcionam possa ajudar em sua visão mais holística desse mundo complexo e maravilhoso de engenharia de software.

Até a próxima. Se chegou até aqui, deixe sua curtida.

Você já parou para refletir sobre como a internet mudou drasticamente nossas vidas? Quando o Google surgiu e revolucionou completamente a maneira como buscamos informações online. Era como se um mundo de conhecimento estivesse literalmente ao alcance dos nossos dedos, e tudo isso graças aos complexos algoritmos por trás daquela simples caixa de pesquisa.

IA? AI?

Mas e agora, com o avanço da Inteligência Artificial (IA)? Assim como o Google abalou os primórdios da internet com sua ferramenta de busca, o mesmo fez a OpenAI quando lançou o ChatGPT, uma ferramenta que transforma a forma como interagimos com a internet, com isso, ao invés de passar horas navegando por páginas e páginas em busca de respostas, agora podemos simplesmente fazer uma pergunta e receber uma resposta direta. É como ter um assistente pessoal sempre disponível, embora claro, ainda há limitações.

E não é apenas o ChatGPT que está mudando a forma como interagimos com a internet, o TikTok, por exemplo, criou nova maneira para as gerações mais jovens acessarem informações, substituindo a tradicional busca na web por uma experiência mais imersiva e visual com seus vídeos, misturando a primordial busca na internet com vídeos curtos cheios de informações.

Mas e o futuro? Bem, parece que a Microsoft está pronta para dar mais um passo à frente. Ao reconhecer o potencial dos modelos de IA desenvolvidos pela OpenAI, a empresa apresentou no Bing, seu motor de busca rival ao Google, um novo conceito de busca online. Com essa experiencia já disponível, e utilizando um conceito chamado de RAG (i.e. Retrieval Augmented Generation), o mecanismo de busca que não apenas fornece links e textos com base em palavras chave, mas uma experiência inovadora gerando um prompt otimizado para o modelo de IA com base os principais resultados da busca tradicional. Como disse uma vez Jeff Bezos, os clientes/usuários nunca estarão satisfeitos, eles estarão sempre buscando por algo melhor, uma experiencia melhor, mesmo que nem eles saibam exatamente o que é. Essa busca incessante por melhorias, junto com claro, a concorrência de empresas, que impulsiona a inovação da tecnologia no mundo.

E falando de Jeff Bezos, o fundador da Amazon fez um investimento em uma empresa que está sendo conhecida por ser rival a busca tradicional oferecida pela Google, e a busca baseada por IA pela Microsoft, a empresa Perplexity AI. Trazendo uma experiencia similar ao que a Microsoft tem feito com o Bing AI, utilizando o conceito de RAG para realizar o prompt no modelo, para oferecer uma experiencia de respostas geradas por IA Generativa com base os principais e mais relevantes resultados da busca.

Isso nos leva a pensar…

À medida que nos aproximamos desse novo capítulo da busca na internet, com a IA moldando o caminho, assim como muitas outras ferramentas que estão aparecendo pelo boom de IA, só podemos esperar que essa revolução nos traga uma experiência ainda mais intuitiva, personalizada e eficiente. Assim como antes do Google poderíamos gastar centenas de horas para encontrar uma informação, e com a ferramenta ver isso ser reduzido para minutos, o futuro com ferramentas como a Perplexity AI nos promete talvez segundos, com uma experiencia cada vez mais inovadora. E claro, o Google com certeza não deixará a concorrência na frente, com isso o futuro parece estar chegando, e nós seremos os mais beneficiados com a concorrência das big techs. E ai, você está preparado?

Se chegou até aqui, deixe sua curtida :)

Um dos desafios que as equipes de tecnologia que possuem recursos na nuvem enfrentam, é que se caso os recursos não foram criados inicialmente se baseando em infraestrutura como código (ou seja, IaC, utilizando ferramentas como o Terraform), além de perder os diversos benefícios, como por exemplo, o reuso em outros projetos, podem enfrentar dores de cabeça ao introduzir essa nova forma de metodologia nos seus ciclos de desenvolvimento, onde é aproximado a infraestrutura como código junto aos repositório das aplicações e seus pipelines.

O problema comum é a equipe já ter infraestrutura rodando em produção, como agora trazer esses recursos para o ciclo de vida de um pipeline de infraestrutura como código, controlado pelo arquivo .tfstate, e como evitar possíveis impactos que isso pode trazer. Por exemplo, supondo que se tem um bucket S3 em ambiente produtivo na nuvem da AWS, uma das alternativas durante a migração para infraestrutura como código é criar um novo bucket e depois transitar na aplicação, mas essa estratégia pode trazer algumas dores de cabeça, além de ser uma estratégia custosa olhando as tarefas a serem realizas, então como podemos avisar o Terraform que os recursos já existem pensando em evitar downtime e retrabalho?

Exemplificando o Problema

Vamos considerar a criação do bucket utilizando Terraform:

Porém lembre-se do problema, é se a aplicação utilizando a infraestrutura já é produtiva, o que podemos fazer? Como podemos ver abaixo, o bucket já existe na conta AWS em uso.

Agora, vamos executar `terraform plan`, e ver o que acontece.

Veja que mesmo o nome estando exatamente igual ao criado na conta AWS configurada no terminal, ele ainda considera no ciclo de vida do Terraform que o recurso não existe. Caso rodarmos um terraform apply será apontado erro na API da AWS.

Mas há uma alternativa?

Pensando nesse cenário que na versão 1.5 do Terraform que foi introduzido o recurso de import, em um bloco simples, é possível dizer ao ciclo de vida do Terraform que aquele recurso já existe, e por isso só deve ser alterado se tiver modificações declaras em seu código. Vamos ver como fica no código abaixo.

O id é o identificador único de um recurso na AWS, nesse caso, é o nome do bucket. O to é para qual recurso declarado no terraform realizar um link.

Agora, tão simples quanto, podemos rodar novamente o terraform plan e validar se o ciclo de vida do Terraform irá reconhecer nosso bucket.

Agora sim, o ciclo de vida do Terraform entendeu que nosso bucket está criado na AWS, e irá importá-lo dentro do bloco meu_bucket , permitindo que possamos realizar alterações (como por exemplo adicionar tags do projeto) já utilizando o pipeline de infraestrutura com Terraform.

Mas será que tem como ficar melhor?

Além dessa facilidade, será que é possível "importar" a declaração completa do recurso? Pois como fizemos acima, por mais que o ciclo de vida do Terraform entenda a existência do recurso, não o cria automaticamente na nossa declaração dentro do main.tf.

Pensando nisso que foi também introduzido o recurso de gerar as configurações durante o estágio de terraform plan, onde é possível gerar a declaração do seu recurso de infraestrutura, e combinar (ou não) com o import de um recurso existente como fizemos acima. Para isso, basta ter um import como a seguir.

Após isso, no exemplo acima vamor importar uma IAM Role que foi criada via console, e agora conseguimos gerar a declaração com o comando a seguir.

terraform plan -generate-config-out='generated.tf'

Como mencionado no comando, será criado um arquivo chamado generated.tf , vamos vê-lo a seguir.

Conclusão

Com ambos recursos de import e generate-config-out, conseguimos avisar o ciclo de vida do Terraform que o recurso existe, seja por qual motivo for, e além disso também gerar a declaração do recurso, tornando tudo bem mais fácil na migração da infraestrutura criada via console para infraestrutura como código.

Caso tenha lido até aqui, deixe sua curtida se gostou do conteúdo! Até a próxima!

Todo mundo em algum momento já precisou “dar um Google”, buscar alguma informação que precisava, e achar o site onde pudesse se aprofundar no conteúdo desejado. Porém algo que não paramos para pensar durante essas consultas na internet é como essa indexação de conteúdos de bilhões de sites da internet é feita, e como os sites de mecanismos de busca, ou seja Bing, Google, Yandex e entre outros fazem essa apresentação de diversos resultados para nós, e ainda mais, como ela funciona?

Neste artigo, vamos entender mais a fundo o que está “em baixo do capô” dos robôs que indexam conteúdos para os mecanismos de busca, e entender como o web crawling e web scraping são utilizados para as finalidades de indexação de conteúdos.

O Puppeteer

O Puppeteer é uma produto para automação de browser, disponível para o Node.js e outras linguagens, ele fornece uma maneira fácil de controlar um navegador de forma automatizado. Com o Puppeteer, você pode criar scripts que navegam os sites da internet, e interagir com elementos da página, coletar informações e muito mais. Além disso, o Puppeteer é compatível com a maioria dos navegadores populares, como o Chrome, o Firefox e o Safari.

Com essas propriedades, o Puppeteer permite que possamos realizar web crawling e web scraping em sites da internet.

Web Crawling vs. Web Scraping

Antes de começarmos, vamos esclarecer a diferença entre web crawling e web scraping.

O web crawling é o processo de coletar dados de vários sites da internet de maneira sistemática. É como se você estivesse rastreando a internet em busca de informações. O objetivo do web crawling é coletar o máximo de dados possível em um determinado assunto, seja para fins de pesquisa, análise de mercado ou outra finalidade.

Já o web scraping é o processo de extrair informações específicas de uma site da internet. O objetivo do web scraping é coletar dados relevantes de uma página da web para uma finalidade específica, como monitorar preços de produtos, coletar informações de contato, coletar dados de uma tabela, ou automatizar a tarefas que seriam realizadas de forma manual por um usuário.

Agora que sabemos a diferença entre web crawling e web scraping, vamos ver como usar o Puppeteer para realizar essas tarefas.

Instalação do Puppeteer

Para começar, precisamos instalar o Puppeteer. Você pode instalar o Puppeteer usando o npm, o gerenciador de pacotes do Node.js.

npm install puppeteer

Depois de instalado, podemos começar a usar o Puppeteer em nossos scripts.

Exemplo de Web Crawling

Vamos começar com um exemplo de web crawling. Neste exemplo, vamos usar o Puppeteer para coletar todas as URLs em uma página da web e, em seguida, seguir cada URL e coletar todas as URLs em cada página vinculada.

Para isso, vamos criar um arquivo index.js conforme a seguir.

const puppeteer = require('puppeteer');

(async () => {

  //Abre uma sessão no browser e uma aba
  const browser = await puppeteer.launch();
  const page = await browser.newPage();

  const urls = new Set();
  const queue = new Set();

  const crawlingDepthLimit = 5;

  queue.add('https://www.medium.com/');

  while (queue.size > 0) {

    const url = queue.values().next().value;

    //Remove a próxima URL da fila e adiciona nos resultados
    queue.delete(url);
    urls.add(url);

    //Para de adicionar novas URLs na fila caso tenha chegado no limite configurado
    if (urls.size < crawlingDepthLimit){

      //Acessa a página informada da fila atual
      await page.goto(url);

      //Mapeia elementos HTML de links para adicionar a fila
      const newUrls = await page.$$eval('a', links =>
      links.map(link => link.href)
      );
  
      //Verificar duplicidades de URLs antes de adicionar na fila
      newUrls.forEach(newUrl => {
        if (!urls.has(newUrl) && !queue.has(newUrl)) {
          queue.add(newUrl);
        }

      });
    }
  }

  //Fecha o browser
  await browser.close();

  console.log([...urls]);

})();

Este script abre o site do https://www.medium.com em uma instância do navegador controlado pelo Puppeteer e coleta todas as URLs da página. Em seguida, adiciona cada URL à lista de URLs coletadas e adiciona todas as URLs recém-descobertas a uma fila para processamento posterior.

Em seguida, o script segue cada URL na fila e repete o processo, coletando todas as URLs em cada página vinculada e adicionando-as à fila. Como boa prática, foi adicionado um limite de crawling para evitar tempo de execução extensivo.

Executando esse script com Node.js, executando o comando node index.js temos o seguinte resultado:

Exemplo de Web Scraping

Já para termos um exemplo de script para web scraping, o script a seguir abre a página inicial do site https://www.example.com/ e extrai o texto do título da página (elemento <h1>) e o texto do primeiro parágrafo da página (elemento <p>). Em seguida, ele exibe essas informações no terminal.

const puppeteer = require('puppeteer');

(async () => {

  //Abre uma sessão no browser e uma aba
  const browser = await puppeteer.launch();
  const page = await browser.newPage();

  //Acessa a página informada
  await page.goto('https://www.example.com/');

  //Coleta elementos HTML da página
  const title = await page.$eval('h1', el => el.innerText);
  const paragraph = await page.$eval('p', el => el.innerText);

  //Tira um print de tela do site no browser
  page.screenshot({path: `screenshot.png`})

  console.log(title);
  console.log(paragraph);

  //Fecha o browser
  await browser.close();
})();

Executando esse script com Node.js, executando o comando node index.js temos o seguinte resultado:

Uma das funcionalidades é tirar capturas de tela da sessão do browser controlada pelo Puppeteer, como no exemplo a seguir com a página do https://www.example.com

Estes são apenas exemplos simples, mas com possibilidades ilimitadas, pois poderíamos extrair uma grande quantidade de informações úteis a partir de sites, tais como: preços de produtos, informações de contato, dados de tabelas, dentre outros. Assim como, realizar automações para tarefas repetitivas, ou testes de interface de usuário simulando um cliente final, onde poderíamos executar cliques em botões, e fazer uma experiência completa.

Conclusão

O Puppeteer é uma ótima ferramenta para web crawling e web scraping em sites da internet. Ele nos permite automatizar ações no navegador, interagir com elementos da página e extrair informações específicas. Com o Puppeteer, podemos facilmente coletar dados de uma variedade de fontes, como sites de notícias, plataformas de mídia social, sites de comércio eletrônico e muito mais.

No entanto, é importante lembrar que o web scraping deve ser realizado de forma ética e legal. Alguns sites podem ter termos de serviço que proíbem o scraping de seus dados ou podem considerar o scraping de seus dados como uma violação de seus direitos autorais. Vale ressaltar também que muitos sites hoje em dia contém com mecanismos anti robôs, como o reCAPTCHA da Google por exemplo, que identifica comportamento de robôs como os que criamos acima, e realiza o bloqueio destes scripts.

Após a compreensão dos conceitos de web crawling e web scraping e seu uso, conseguimos entender como as informações dos sites da internet são extraídas e indexadas por mecanismos de busca, e entendendo que quando um determinado termo, texto ou frase é buscado (por exemplo, “O que é Node.js?”), o mecanismo busca na “última versão” indexada dos sites públicos da internet, que foram indexadas por robôs como os que criamos anteriormente.

Com a imagem a seguir, conseguimos visualizar diversas informações de vários sites da internet, e como os mecanismo de buscam usam o que foi indexado (ou seja, salva e manipula o HTML puro como fizemos acima) para trazer uma experiência customizada para o usuário.

Se chegou até aqui, deixe seu 👍 para saber que curtiu o artigo!

Me siga para mais postagens! 😃