DEV Community: Marcelo Matz

Carreira Dev: Não comece pelo frontend

Marcelo Matz — Mon, 11 Sep 2023 17:37:59 +0000

Está começando agora ou pensando em começar na carreira DEV, então toma aqui o primeiro ensinamento: a carreira dev vai comer o teu rabo sem dó!

Chorume inicial

De uns anos pra cá, encontrar um vendedor de curso falando em jornada de carreira dev frontend mobile ultra blaster se tornou a coisa mais comum.

O problema é uns 80% desses são picaretas e os outros 20% estão sendo esmagados pelo marketing dos trambiqueiros.

Encontrar curso bom se tornou mais difícil do que achar dev especialista em Phonegap.

Alguns cursos acabam mostrando somente uma camada, dentre tantas que existem, dentro do mundo do desenvolvimento e deixam de lado uma imensidão de oportunidades de carreira.

Apesar do título deste post parecer tendencioso, e é, você vai perceber que o meu objetivo aqui não é brigar com o frontend ou com os vendedores de cursos, muito pelo contrário, você vai encontrar uma visão realista do que a gente sabe que está acontecendo.

Disclaimer: eu não vendo ou recomendo curso de ninguém. O que você vai encontrar aqui é a opinião de alguém que está desde o ano 2000 vivendo do mercado de tecnologia.

Começando na carreira Dev

Começar na carreira Dev tem se tornado um desafio enorme pra muita gente. Parte dessas pessoas são acometidas por tantas ofertas de cursos, imersões, semanas de aprendizado profundo, técnicas inovadoras de aprender linguagens de programação em 7 dias, etc!

Na real, o problema não é as pessoas venderem cursos. O problema é vender mentiras.

Vamos falar sobre 4 contos do vigário:

1º - Não tem centenas de milhares de vagas de emprego.
Hoje, inclusive, o que mais tem são pessoas de tecnologia procurando vagas, logo, vai conseguir uma oportunidade quem se destacar.

2º - Não é todo mundo que vai conseguir.
Tem gente que começa, tenta, se esforça e não consegue. Começar é fácil, mas isso é assim em qualquer coisa. Difícil é conseguir persistir.

3º - Você não vai aprender a programar em 7 dias!
Você até pode aprender a datilografar código e vai aprender um básico do básico, mas isso não vai te levar para o próximo nível.

4º - Não caia no conto da melhor linguagem de programação.
Se você ver um vídeo de um vendedor de curso de Python, ele vai te mostrar que Python é a linguagem mais usada no mundo. Se for um vendedor de curso de Javascript, ele vai fazer a mesma coisa e assim todos os outros.

O que é verdade na carreira dev é:

Não existe salário alto pra quem tá começando;
Existem casos raros e excessões que ganham muito, e elas serão apresentadas à você como um troféu;
Tem escolas sérias de tecnologia que te ensinam habilidades técnicas, de negócios e de relacionamento, mas são poucas;
Você não vai sair de uma imersão sabendo programar. Você no máximo aprender a copiar código escrito por outra pessoa;
Você só vai aprender a programar, programando. Quando você parar de repetir tutorial e começar a fazer os seus próprios, você aprende;
Altos salários existem sim e você pode ter um. Trabalhe por ele e foque na sua carreira, dedique anos estudando para ser bom no que você faz que o reconhecimento financeiro vem;
A maioria das vagas de emprego vão dizer uma coisa e na prática você vai fazer outra. Lide com isso desde agora ou viva reclamando depois.

Por onde começar?

Desde o início da pandemia até agora, o que mais apareceu no mercado foi desenvolvedor vendendo cursos. Cada pessoa/escola tenta puxar a farinha para o seu saco, afinal de contas a gente está falando de um segmento de mercado chamado Educação.

Como subcategoria de educação, temos o ensino de tecnologia. Dentro de tecnologia tem uma caralhada de coisas que não cabem aqui neste post.

Quanto mais específico for o curso que você estiver fazendo, mais distante você acaba ficando de outras tecnologias.

A minha recomendação para você que está começando agora na carreira de dev é primeiro andar por algumas áreas e entender como cada uma funciona, o mercado de trabalho, as pessoas que fazem parte deste meio, a forma de atuação das empresas que contratam pessoas para essa área e a sua participação dentro do mundo da tecnologia a partir deste ponto de vista.

Perceba que se você conseguir experimentar um pouco de cada área, isso no fim das contas só vai te ajudar a enxergar que existe mais coisas além dos limites apresentados dentro dos cursinhos que você vai encontrar por aí.

Dedo na ferida do frontend

A oferta de cursos de frontend usando Javascript, React, Angular, etc, vem aumentando muito.

Tão enfiando JS em tudo. E tudo bem, mas nem tão bem assim!

O uso do Javascript aumentou muito com o surgimento de bibliotecas e frameworks, o que acaba atraindo a atenção das pessoas, empresas e consequentemente dos vendedores de cursos.

Vende-se uma imagem de que, se você começar pelo frontend, por ele ser a camada da web onde as pessoas mais interagem, acaba sendo mais acessível e fácil expor um portfólio para então, a partir disso, conseguir uma vaga de emprego. E isso não é mentira, mas também não é totalmente verdade.

Escolher começar pelo frontend pode ser tentador e fazer todo sentido, visto que é uma área que cresce muito, tem grande oferta de cursos, muitas empresas focadas em vender formações frontend, mas por outro lado pode ser o começo de um caminho extenso, cansativo e extremamente ruim para algumas pessoas.

O desenvolvimento de software vai além da criação de interfaces, apps, sites, landing-pages ou qualquer outra coisa que se crie a partir do frontend hoje em dia.

O desenvolvimento híbrido de aplicativos pode até ser um bom mercado, mas entrar nele sem nem conhecer o desenvolvimento nativo, por exemplo, pode ser uma furada.

Vamos pelo caminho da lógica:
Uma pessoa que começa pelo frontend vai seguir basicamente uma jornada onde ela começa aprendendo HTML, CSS e o básico de Javascript e depois vai aprofundando em JS até ser imersa em alguma ramificação.

Essa ramificação vai acabar chegando num React da vida que hoje em dia é a biblioteca mais hypada.

É normal aparecer aqueles anúncios assim:

Seja um desenvolvedor mobile e conquiste a liberdade de ser um nômade digital, ganhar altos salários em dólar e conquistar a sua tão sonhada liberdade financeira 🤡
O vendedor de curso de Javascript vai te dizer que se você aprender apenas Javascript, você vai desenvolver software para qualquer tipo de dispositivo e ainda vai te mostrar exemplos de APPs que foram feitos em JS.

O que não te contam é que essa jornada vai muito além, e que chega um momento onde a pessoa focou tanto em uma determinada tecnologia, que ela acabou deixando de lado o aprendizado em programação para se tornar especialista em biblioteca.

Ao invés da pessoa aprender Javascript e trabalhar com JS, ela aprende React para usar NextJS ou outro framework da modinha, e depois fica horas e horas estudando algum framework de CSS para criar estilos, e por aí vai.

Aí chega a hora de colocar o APP no ar e a pessoa aprende a fazer deploy de APP feito em cima de framework. Nunca viu dentro do curso uma linha de informação sobre redes, protocolos, etc, mas vai aprender a seguir um tutorial de como integrar um CI/CD na Vercel a partir de um repositório no GitHub.

O que até aqui parece uma crítica, é na verdade um alerta.

A gente precisa parar de romantizar a carreira de desenvolvimento e mostrar que o campo de atuação é muito maior e ele vai além do hype da web.

Tecnologias embarcadas, softwares desktop, iOT, ciência de dados, banco de dados, hardware, games, carros autônomos, aviação comercial, agro pop e diversos outros meios precisam de pessoas desenvolvedoras para criar softwares que não chegam nem perto de rodar na web.

Se liga nisso aqui 👇

O que eu já vi de frameworks morrerem nos últimos 25 anos não foi pouco, e isso não vai acabar.

Um exemplo prático disso eu mesmo vivenciei quando, em 2002 eu fiz algumas especializações em Flash, uma tecnologia que na época era considerada a coisa mais incrível já criada no mundo e que pouco tempo depois viria a ser totalmente destruída.

Quem tem 30+ vai lembrar que foi Steve Jobs e o iPhone que decretaram o fim da vida do então Adobe Flash.

Não caia nas garras do framework bandido

Pare de programar orientado à framework, ou nem comece a programar assim se você ainda não sentiu esse gostinho.

É tipo sangue em boca de vampiro.

Não que eles (os frameworks, não os vampiros) não sejam importantes, mas você precisa aprender algumas coisas antes de usar frameworks.

Se lá em 2000 quando eu comecei a focar mais em desenvolvimento eu não tivesse ampliado o meu campo de atuação e conhecimento, aprendendo Linux, banco de dados, redes e infraestrutura, eu não teria conseguido os empregos que eu consegui e muito menos teria a experiência que eu tenho hoje.

Se liga que Programação é diferente de Desenvolvimento

Programar e desenvolver são coisas que podem ser semelhantes e podem também ser completamente diferentes.

Programar é o ato de entender e saber usar as linguagens de programação.

Desenvolver é usar a programação para construir algo.

Esse algo pode ser tanto uma coisa (software) pequeno e simples como também pode ser algo grandioso e complexo.

Dentro do desenvolvimento de software, por exemplo, nós temos diversos outros profissionais além da pessoa dev trabalhando no projeto.

O que os (alguns) cursos de dev tentam fazer é encurtar a jornada e "preparar o profissional para o mercado de trabalho" no menor tempo possível.

O que acaba sendo uma merda!

Diferente de uma graduação, por exemplo, onde a ideia é entrar a fundo em campos de estudos e fazer isso ao decorrer de alguns anos, os cursos removem do treinamento tudo aquilo que eles consideram desnecessário.

Exemplo são os cursos que ensinam a salvar dados num banco de dados, mas a pessoa que aprende não tem a menor noção do motivo de ela estar usando MongoDB ao invés de mySQL, por exemplo, ou qualquer outra solução no lugar outra solução, não importa.

Na minha humilde opinião, o que falta hoje são os cursos assumirem que o que eles ensinam é apenas uma parcela do que é necessário saber.

Alguns poucos falam que você precisa ir além, etc, etc, etc, mas poucos mostram o caminho.

Algumas escolas de formação até possuem planos de carreira que contemplam diversos cursos e formações, onde no final de tudo isso a pessoa, teoricamente, é especialista em alguma coisa.

Naturalmente, se você começar a estudar uma tecnologia hoje, em poucos dias você vai topar com 200 novas tecnologias que estão envolvidas no meio do caminho dentro do pouco que você está usando.

Começa instalando o editor de código, aprendendo que precisa digitar comandos em um terminal, descobre que vai ter que usar Linux, entende que para "facilitar" criaram alguns pacotes que você só vai instalar e sair usando, etc, etc, etc.

Toda jornada de tecnologia começa simples e termina caótica.

Quando você acha que está sabendo muito e que manja dos paranauê de desenvolver, você descobre que precisa aprender algoritmos, estruturas de dados, descobre que existem paradigmas de programação, começa a acumular livros cansativos e chatos como os do Uncle Bob, Eric Evans e Martin Fowler, tendo que ler traduções grotescas de obras que só fazem sentido quando você conhece um campo muito mais amplo no desenvolvimento de software.

Em pouco tempo você vai ter uma lista de tecnologias tão grande para estudar e vai ver que outras pessoas estão muito mais avançadas do que você, e então você começa a se sentir menos capaz, começa a enxergar as oportunidades mais distantes, sente que dentro da própria comunidade de desenvolvimento existe muito mais um jogo de egos do que uma estrutura para ajudar quem está começando e começa a pensar em desistir.

Não se deixe abalar pelo caminho percorrido pelos outros. Foque em você! E esse é o melhor conselho que qualquer pessoa pode te dar.

Não se limite

No fim das contas a mensagem que eu quero te passar é: não se limite.

Não deixe a guerrinha entre linguagens de programação te fazer desistir ou persistir somente em um caminho a partir da opinião de outros. Experimente você mesmo.

O que você não deve experimentar são drogas. Linguagens de programação você pode testar todas.

Explore, conheça, teste linguagens de programação, mesmo aquelas que você olha para a sintaxe do código e pensa: isso aqui não foi feito por humanos.

Existem diversos tutoriais passo a passo no YouTube que podem te ajudar a ver mais conceitos. Não é porque você vai trabalhar com uma linguagem orientada à objetos que você vai deixar e entender sobre programação funcional, ou procedural, por exemplo.

Quando você entende mais sobre diferentes linguagens, você começa a perceber que as todas elas meio que são iguais, e que independente da linguagem que você tem mais domínio, saber programação te habilita a aprender outras linguagens rapidamente.

Saber programação não é sobre dominar uma linguagem de programação por completo e saber tudo o que pode ser feito com ela. Programação é saber quando e onde usar determinada linguagem e aplicar ela para resolver o problema que tiver que ser resolvido.

E isso não quer dizer que ser generalista é melhor do que ser especialista, mas se você começar do zero e colocar o objetivo de ser especialista em uma coisa sem nem conhecer as outras antes, pode ser que ali na frente você descubra que a sua escolha poderia ter sido melhor, ou não.

Espero você no próximo post. Até lá.

Google Places API: criando um App em Go para testar o novo recurso de Text Search

Marcelo Matz — Tue, 05 Sep 2023 17:25:35 +0000

Eu recentemente coloquei um desafio no meio das minhas metas: implementar uma aplicação fullstack usando a linguagem de programação Go. E eu consegui 🤘

Este artigo é sobre a minha experiência implementando um novo recurso da API de Places do Google Maps usando Go no backend e JS no frontend.

Se você quer uma versão resumida e em vídeo deste artigo, aqui você encontra.

Depois da PoC do BuscaCep usando DDD e CleanCode onde eu usei a API do ViaCep, eu comecei a pesquisar mais sobre o assunto e obviamente eu acabei esbarrando na plataforma do Google Maps.

Neste artigo eu mostro passo a passo o que eu fiz para implementar o App, qual foi a linha de raciocínio que eu usei para criar cada coisa e ainda mostro o código que eu usei, tanto no backend quanto no frontend.

Google Maps

O Google Maps é a plataforma do Google que te permite criar apps usando todas as informações que o Google tem sobre endereços.

Só o aprendizado para entender como o Google Maps é segmentado e principalmente como é feita a cobrança do serviço, já foi um baita aprendizado.

A plataforma do Google Maps é dividida em três segmentações diferentes:

Maps
Routes
Places

Maps é a API responsável por:

Mapas estáticos: Mostre um mapa estático no seu site.
Imagens do Street View: Adicione imagens do Street View em 360° aos seus apps.
Mapas de Elevação de terreno: Conseguir os dados da elevação de um ou vários locais.

Routes é a API responsável por:

API Routes: Versão otimizada para a performance das APIs Directions e Distance Matrix com recursos extras.
Roads: Identifique vias próximas usando as coordenadas.
Rotas: Forneça rotas para vários meios de transporte, com informações do trânsito em tempo real.
Matriz de distância: Calcule os tempos de viagem e as distâncias para várias origens e destinos.

Places é a API responsável por:

API Places: Integre o Place Details, Search e Autocomplete do Google aos seus apps.
Geocodificação: Converta coordenadas em endereços e vice-versa.
Geolocalização: Veja a localização aproximada do dispositivo usando as torres de celular e os nós da rede Wi-Fi próximos.
Address Validation: _Valide um endereço e seus componentes.
Fusos horários: Descubra o fuso horário de um conjunto de coordenadas._

API Places

Dentro dessa infraestrutura de APIs do Maps, o meu projeto se limitou a implementar a API Places que é justamente a API que integrar o Place Details, o Search e também o Autocomplete que eu não usei neste projeto.

A aplicação foi dividida em 2 partes: backend e frontend.

O objetivo principal era implementar a parte de backend da API de Places usando o Search e o Place Details usando a linguagem Go, sem deixar de criar um frontzinho básico.

Parte 1: Backend
A aplicação backend foi escrita em Go, e o papel desse backend era prover uma API que fosse responsável por buscar informações do Google Places API para depois retornar elas para o frontend. Ao meu ver esse este é básico de uma aplicação web, hoje em dia.

Alguns recursos do backend em Go:

Buscar lugares através da Google Places API
Manejar CORS (isso consumiu algumas horas de estudo)
Servir as informações obtidas para o frontend

Como a API do Google Place exige que eu faça duas requisições, uma para buscar o local e outra para buscar os detalhes deste local, eu fiz uma implementação da seguinte forma:

Função SearchPlace

func searchPlace(client *http.Client, query string) (*PlaceSearch, error) {
    searchURL := fmt.Sprintf("https://maps.googleapis.com/maps/api/place/textsearch/json?query=%s&key=%s", url.QueryEscape(query), gcpToken)
    resp, err := client.Get(searchURL)
    if err != nil {
        return nil, err
    }
    defer func(Body io.ReadCloser) {
        err := Body.Close()
        if err != nil {
            log.Println(err)
        }
    }(resp.Body)

    respBody, err := io.ReadAll(resp.Body)
    if err != nil {
        return nil, err
    }

    placeSearch := PlaceSearch{}
    if err := json.Unmarshal(respBody, &placeSearch); err != nil {
        return nil, err
    }

    return &placeSearch, nil
}

Ela tem a função de realizar uma consulta de pesquisa na API do Google Places, utilizando o termo de pesquisa fornecido como argumento query.

A chamada HTTP para a API é feita e a resposta (um JSON) é desserializada num objeto PlaceSearch, que contém um array de resultados, cada um com um PlaceId correspondente.

Se ocorrer um erro durante a execução da chamada HTTP ou durante a desserialização do JSON, o erro será retornado. Caso contrário, a função retorna o objeto PlaceSearch.

Função getPlaceDetail

func getPlaceDetail(client *http.Client, placeId string) (*PlaceDetail, error) {
    detailURL := fmt.Sprintf("https://maps.googleapis.com/maps/api/place/details/json?place_id=%s&fields=name,formatted_address,formatted_phone_number,website,rating,business_status,opening_hours,reviews,url,price_level&key=%s&language=pt-BR", placeId, gcpToken)
    resp, err := client.Get(detailURL)
    if err != nil {
        return nil, err
    }
    defer func(Body io.ReadCloser) {
        err := Body.Close()
        if err != nil {
            log.Println(err)
        }
    }(resp.Body)

    body, err := io.ReadAll(resp.Body)
    if err != nil {
        return nil, err
    }

    placeDetail := PlaceDetail{}
    if err := json.Unmarshal(body, &placeDetail); err != nil {
        return nil, err
    }

    return &placeDetail, nil
}

Essa função é utilizada para obter detalhes de um local específico, identificado pelo seu PlaceId.

A função faz uma chamada HTTP para um endpoint diferente da API do Google Places, que retorna os detalhes do local.

A resposta (um JSON) é desserializada num objeto PlaceDetail, que contém várias informações, incluindo nome, endereço formatado, URL do website, horário de funcionamento, reviews e mais.

Da mesma forma que searchPlace, se ocorrer um erro durante a chamada HTTP ou na desxerialização do JSON, o erro será retornado. Caso contrário, a função retorna o objeto PlaceDetail.

As duas funções desempenham um papel crucial na interação com a API do Google Places - a searchPlace é utilizada para fazer consultas de busca gerais, enquanto a getPlaceDetail é utilizada para obter detalhes mais específicos sobre cada local retornado pela pesquisa.

Função searchHandler Essa função é o coração deste software.

func searchHandler(w http.ResponseWriter, r *http.Request) {
    client := &http.Client{Timeout: 10 * time.Second}

    searchStr := r.URL.Query().Get("query")

    placeSearch, err := searchPlace(client, searchStr)
    if err != nil {
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }

    totalPlaces := len(placeSearch.Results)

    details := make([]*PlaceDetail, totalPlaces)
    var wg sync.WaitGroup

    for i, result := range placeSearch.Results {
        wg.Add(1)
        go func(i int, placeId string) {
            defer wg.Done()
            detail, err := getPlaceDetail(client, placeId)
            if err != nil {
                http.Error(w, err.Error(), http.StatusInternalServerError)
                return
            }
            details[i] = detail
        }(i, result.PlaceId)
    }

    wg.Wait()

    w.Header().Set("Content-Type", "application/json")
    err = json.NewEncoder(w).Encode(details)
    if err != nil {
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }
}

A função searchHandler é um manipulador HTTP que é acionado quando o endpoint /search é acessado.

No começo da função, um cliente HTTP com um limite de tempo de 10 segundos é criado. Em seguida, ela extrai a string de pesquisa a partir da query do request HTTP.

O método searchPlace é então chamado com o cliente HTTP e a string de pesquisa, que faz uma requisição para a API Place do Google e retorna uma matriz de PlaceIds.

Depois, a função cria um slice para armazenar as respostas de PlaceDetail vindas da API do Google Places.

A função inicia uma gorotina para cada PlaceID obtido na resposta da searchPlace, e estas gorotinas fazem chamadas à função getPlaceDetail para obter detalhes para cada PlaceID.

O sincronismo dessas gorotinas é controlado utilizando um WaitGroup.

Ao terminar as chamadas à função getPlaceDetail, a função searchHandler configura o cabeçalho "Content-Type" do response como "application/json" e codifica o slice de PlaceDetails em JSON para enviar como resposta ao cliente.

Se algum erro ocorrer ao longo desses passos, a função irá retornar um status de erro HTTP 500 para o cliente junto com o erro que ocorreu.

// Esta função é chamada quando o endpoint /search é acessado.
func searchHandler(w http.ResponseWriter, r *http.Request) {
    // Criar um cliente HTTP com um tempo limite de 10 segundos.
    client := &http.Client{Timeout: 10 * time.Second}

    // Extrair a string de pesquisa a partir da query do request HTTP.
    searchStr := r.URL.Query().Get("query")

    // Faz uma chamada à API do Google Places para procurar por um lugar.
    placeSearch, err := searchPlace(client, searchStr)
    if err != nil {
        // Se houver um erro, retorna um status 500 e o erro.
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }

    // Cria um slice para armazenar os detalhes dos lugares.
    totalPlaces := len(placeSearch.Results)
    details := make([]*PlaceDetail, totalPlaces)

    // Inicializando um WaitGroup para sincronizar as goroutines
    var wg sync.WaitGroup

    // Faz uma chamada para obter detalhes de cada lugar baseado em PlaceID
    for i, result := range placeSearch.Results {
        wg.Add(1)
        go func(i int, placeId string) {
            // Chamando a função para obter os detalhes do local
            defer wg.Done()
            detail, err := getPlaceDetail(client, placeId)
            if err != nil {
                http.Error(w, err.Error(), http.StatusInternalServerError)
                return
            }
            details[i] = detail
        }(i, result.PlaceId)
    }

    // Esperando todas as goroutines terminarem
    wg.Wait()

    // Configurar o cabeçalho HTTP 'Content-Type' para 'application/json'
    w.Header().Set("Content-Type", "application/json")

    // Codificar a resposta em JSON
    err = json.NewEncoder(w).Encode(details)
    if err != nil {
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }
}

Structs

Para sustentar tudo isso e também para eu conseguir tratar o JSON recebido, eu criei quatro structs.

type PlaceSearch struct {
    Results []struct {
        PlaceId string `json:"place_id"`
    } `json:"results"`
}

type OpeningHours struct {
    OpenNow     bool     `json:"open_now"`
    WeekdayText []string `json:"weekday_text"`
}

type Review struct {
    AuthorName string `json:"author_name"`
    Text       string `json:"text"`
}

type PlaceDetail struct {
    Result struct {
        Name                 string        `json:"name"`
        FormattedAddress     string        `json:"formatted_address"`
        FormattedPhoneNumber string        `json:"formatted_phone_number"`
        Website              string        `json:"website"`
        Rating               float64       `json:"rating"`
        BusinessStatus       string        `json:"business_status"`
        OpeningHours         *OpeningHours `json:"opening_hours"`
        Reviews              []Review      `json:"reviews"`
        Url                  string        `json:"url"`
        PriceLevel           int           `json:"price_level"`
    } `json:"result"`
}

Main

A minha função main, responsável por iniciar o meu software, acabou ficando assim:

func main() {
    err := os.Getenv("GCP_TOKEN_PLACE_API")
    if err != nil {
        log.Fatalf("Erro ao carregar o arquivo .env")
    }

    if gcpToken == "" {
        log.Fatal("Insira o Token GCP_TOKEN_PLACE_API na variável de ambiente")
    }

    http.HandleFunc("/search", searchHandler)

    log.Fatal(http.ListenAndServe(":8080", handlers.CORS(handlers.AllowedOrigins([]string{"*"}))(http.DefaultServeMux)))
}

Essa função basicamente verifica se o token de autenticação está inserido na variável de ambiente. (Em alguns momentos eu usei a variável de ambiente setada no meu OS, em outros momentos usei .env e em outros o token estava exposto no código-fonte mesmo.)

A rotina do http server

O servidor é iniciado na porta 8080 e eu passo um handler que faz a mão de aceitar a requisição vindo de outra origem. Eu separei a aplicação em duas imagens Docker onde o backend roda na porta 8080 e o frontend roda na porta 80.

Enquanto eu fazia a aplicação, eu tive problemas de CORS quando tentava fazer a requisição a partir do meu frontend. A requisição feita diretamente pela porta 8080 acontecia normalmente, enquanto o navegador encontrava problemas com isso.

O mecânismo CORS suporta requisições seguras do tipo cross-origin e transferências de dados entre navegadores e servidores web.

Esse servidor ainda usa uma handle function que faz a gestão das rotas. No caso eu criei uma rota /search onde a partir dela eu chamo outra função que é a responsável por continuar a requisição e posteriormente isso vai me retornar um JSON.

Parte 2: Frontend
O frontend foi feito com HTML, CSS, JavaScript, Bootstrap e o bom e velho jQuery.

Como eu queria testar alguns filtros no front, eu implementei o Datatables, um recurso que eu já conhecia de outros carnavais e que sempre me ajudou na hora de criar tabelas dinâmicas no frontend e ele tem como dependência o jQuery.

Eu poderia entrar a fundo nos conceitos de frontend e ficar explicando o motivo de eu não ter usado React, Vue ou qualquer outro super poder de frontend, porém, como eu falei, o desafio era primeiro implementar e fazer funcionar e depois, quem sabe, um dia, eu refaça o frontend usando alguma biblioteca do momento.

Aqui você encontra uma base do HTML usado no projeto:

<!DOCTYPE html>
<html lang="pt-br">
<head>
    <meta charset="UTF-8">
    <meta content="width=device-width, initial-scale=1.0" name="viewport">
    <title>AquiPertin - Encontre tudo o que você precisa, onde você precisa.</title>

    <!-- Bootstrap -->
    <link crossorigin="anonymous" href="https://cdn.jsdelivr.net/npm/bootstrap@5.0.2/dist/css/bootstrap.min.css"
          integrity="sha384-EVSTQN3/azprG1Anm3QDgpJLIm9Nao0Yz1ztcQTwFspd3yD65VohhpuuCOmLASjC" rel="stylesheet">

    <!-- Datatables -->
    <link href="https://cdn.datatables.net/1.10.25/css/dataTables.bootstrap4.min.css" rel="stylesheet">

    <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.15.3/css/all.min.css">
    <style>
        div#contentResultTable {
            width: 80%;
        }
    </style>
</head>
<body>
<div class="content vh-100">
    <header>
        <div class="container">
            <nav class="navbar navbar-light pt-5">
                <a class="navbar-brand" href="#">Aqui<strong>Pertin</strong></a>
                <span class="navbar-text">_simples assim :)</span>
            </nav>
            <span class="navbar-text">Encontre tudo o que você precisa.</span>
        </div>
    </header>
    <div class="container">
        <div class="row align-items-center">
            <div class="mx-auto">
                <div class="text-justify font-weight-bold">
                    <form class="mt-5" id="myForm">
                        <div class="form-group">
                            <label for="query"></label>
                            <input class="form-control" id="query" name="query" placeholder="Ex: Restaurantes próximos"
                                   type="text">
                            <button class="btn btn-primary mt-3" type="submit">Consultar</button>

                        </div>
                        <div class="form-group">
                            <input type="checkbox" id="onlyOpen" name="onlyOpen" checked>
                            <label for="onlyOpen" class="mt-3">Mostrar somente lugares abertos agora</label>
                        </div>

                    </form>
                </div>
            </div>
        </div>
    </div>

    <div aria-hidden="true" class="modal fade" id="reviewsModal" role="dialog" tabindex="-1">
        <div class="modal-dialog reviews-modal-dialog">
            <div class="modal-content">
                <div class="modal-header">
                    <h5 class="modal-title">Avaliações</h5>
                    <button class="close" data-dismiss="modal" onclick="closeModals()" type="button">&times;</button>
                </div>
                <div class="modal-body" id="reviewsContent"></div>
                <div class="modal-footer">
                    <button class="btn btn-secondary" data-dismiss="modal" onclick="closeModals()" type="button">Fechar</button>
                </div>
            </div>
        </div>
    </div>
    <!-- Modal -->
    <div aria-hidden="true" aria-labelledby="hoursModalLabel" class="modal fade" id="hoursModal" tabindex="-1">
        <div class="modal-dialog">
            <div class="modal-content">
                <div class="modal-header">
                    <h5 class="modal-title" id="hoursModalLabel">Horários de Funcionamento</h5>
                    <button class="close" data-dismiss="modal" onclick="closeModals()" type="button">&times;</button>
                </div>
                <div class="modal-body">
                    <!-- O conteúdo do horário de funcionamento será inserido aqui pelo JavaScript -->
                </div>
                <div class="modal-footer">
                    <button class="btn btn-secondary" data-dismiss="modal" onclick="closeModals()" type="button">Fechar</button>
                </div>
            </div>
        </div>
    </div>

    <div class="container-fluid mt-4" id="contentResultTable" style="display: none;">
        <div class="row">
            <div class="col-md-12">
                <table class="table table-striped table-bordered mt-5" id="resultTable">
                    <thead>
                    <tr>
                        <th title="Nome da empresa">Nome</th>
                        <th title="Endereço da empresa">Endereço</th>
                        <th title="Localização no Google Maps">Mapa</th>
                        <th title="Número de telefone da empresa">Telefone</th>
                        <th title="Avaliações do usuário">Avaliações</th>
                        <th title="Website da empresa">Site</th>
                        <th title="Classificação média dos usuários">Nota</th>
                        <th title="Horário de funcionamento da empresa">Funcionamento</th>
                    </tr>
                    </thead>
                    <tbody>
                    <!-- As linhas com os dados da requisição serão adicionadas aqui pelo JavaScript -->
                    </tbody>
                </table>
            </div>
        </div>
    </div>
</div>
<!-- jQuery -->
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js"></script>

<!-- Datatables JS -->
<script src="https://cdn.datatables.net/1.10.25/js/jquery.dataTables.min.js"></script>
<script src="https://cdn.datatables.net/1.10.25/js/dataTables.bootstrap4.min.js"></script>

<!-- Bootstrap JS Bundle -->
<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.0.2/dist/js/bootstrap.bundle.min.js"></script>

<!-- App JS -->
<script src="search.js"></script>
</body>
</html>

Abaixo eu compartilho com você um JS onde eu me dei ao trabalho de comentar quase que linha a linha para explicar o que eu fiz.

// armazena os dados recuperados
let table;
let dataStore = {};
// este código é executado quando o documento HTML é completamente carregado
$(document).ready(function() {
    // inicia o plugin DataTables na tabela #resultTable
    table = $('#resultTable').DataTable({
        // configura a linguagem em português para o DataTable
        "language": {
            "url": "https://cdn.datatables.net/plug-ins/1.10.24/i18n/Portuguese-Brasil.json"
        },
        // recupera uma instância DataTable existente, se aplicável
        "retrieve": true,
        // destrói qualquer instância DataTable existente para inicializar uma nova
        "destroy": true
    });
    // ativa tooltips para quaisquer elementos com um atributo de título
    $('[title]').tooltip();
});
// gera o conteúdo HTML a ser adicionado ao modal de revisão
function generateModalContent(reviewData) {
    return reviewData.filter(review => review.text)
        .map(review => {
            console.log(review.rating);
            let rating = parseFloat(review.rating) || 0;
            let fullStars = '<i class="fas fa-star"></i>'.repeat(Math.floor(rating));
            let halfStar = ((rating - Math.floor(rating)) !== 0 ) ? '<i class="fas fa-star-half-alt"></i>' : '';
            return `<h5>${review.author_name} ${fullStars}${halfStar}</h5>
                    <p>${review.text}</p>`;
        })
        .join('');
}
// abre um modal, o conteúdo é gerado dependendo do parâmetro 'type'
function openModal(index, type) {
    let modalContent;
    let modal;
    switch (type) {
        case 'reviews':
            modalContent = generateModalContent(dataStore[index].result.reviews);
            modal = $('#reviewsModal');
            break;

        case 'hours':
            modalContent = dataStore[index].result.opening_hours.weekday_text.map(hours => `<p>${hours}</p>`).join('');
            modal = $('#hoursModal');
            break;
    }
    modal.find('.modal-body').html(modalContent);
    modal.modal('show');
}
// fecha todos os modals abertos
function closeModals() {
    $('#reviewsModal').modal('hide');
    $('#hoursModal').modal('hide');
}
// gera o conteúdo HTML para resultados de busca
function createResultHtml(data) {
    // filtra os resultados de acordo com a opção "Apenas abertos"
    if (document.getElementById("onlyOpen").checked) {
        data = data.filter(item => item.result.opening_hours && item.result.opening_hours.open_now);
    }
    // ordena os resultados de acordo com a opção "Ordenar por"
    data.sort((a, b) => {
        // se a opção for "Avaliações", ordena por avaliações
        let a_open = (a.result.opening_hours && a.result.opening_hours.open_now) ? 1 : 0;
        let b_open = (b.result.opening_hours && b.result.opening_hours.open_now) ? 1 : 0;

        // se a opção for "Apenas abertos", ordena por abertos
        if (a_open && !b_open) {
            return -1;
        }
        if (!a_open && b_open) {
            return 1; // a_open false, b_open true, move a down
        }
        // se a opção for "Avaliações", ordena por avaliações - a ser implementado
        let a_rating = a.result.rating || 0;
        let b_rating = b.result.rating || 0;
        return b_rating - a_rating;
    });

    // armazena os dados para uso posterior
    dataStore = data;

    // gera o HTML para cada resultado
    return data.map((item, index) => {
        // se o local não tiver avaliações, o valor padrão é 0
        const rating = item.result.rating !== undefined ? item.result.rating : 0;
        // gera o HTML para as estrelas de avaliação
        const fullStars = '<i class="fas fa-star"></i>'.repeat(Math.floor(rating));
        const halfStar = ((rating - Math.floor(rating)) !== 0 ) ? '<i class="fas fa-star-half-alt"></i>' : '';
        const ratingHTML = `${fullStars}${halfStar}`;
        // gera os detalhes do local
        let details = {
            // se o valor for indefinido, o valor padrão é "Not Available"
            name: item.result.name || 'Not Available',
            address: item.result.formatted_address || 'Not Available',
            phoneNumber: item.result.formatted_phone_number || 'Not Available',
            reviews: item.result.reviews && Array.isArray(item.result.reviews) ? item.result.reviews.length : 0,
            website: item.result.website || "Not Available",
            url: item.result.url || "Not Available",
            rating: ratingHTML,
            // se o local estiver aberto, o valor padrão é "Open", caso contrário, "Closed"
            isOpen: item.result.opening_hours && item.result.opening_hours.open_now
                ? "<span class='badge bg-success'><i class='fas fa-arrow-up'></i> Open</span>"
                : "<span class='badge bg-danger'><i class='fas fa-arrow-down'></i> Closed</span>"
        };
        // retorna a linha da tabela HTML
        return getTableRow(details, index);
    }).join(""); // une todas as linhas em uma única string
}
// gera uma linha de tabela HTML a partir de detalhes de um local
function getTableRow(details, index){
    // retorna a linha da tabela HTML usando template literals
    return `
      <tr>
            <td>${details.name}</td>
            <td>${details.address}</td>
            <td><a href="${details.url}" target="_blank">Ver link</a></td>
            <td><a href="tel:${details.phoneNumber}">${details.phoneNumber}</a></td>
            <td><a href="#" onclick="openModal(${index}, 'reviews')">Ver avaliações (${details.reviews})</a></td>
            <td><a href="${details.website}" target="_blank">Acessar site</a></td>
            <td>${details.rating}</td>
            <td><a href="#" onclick="openModal(${index}, 'hours')">${details.isOpen}</a></td>
      </tr>
   `;}
// adiciona um listener de evento para o formulário de pesquisa
document.getElementById("myForm").addEventListener("submit", function(event) {
    event.preventDefault();
    // recupera o valor do campo de entrada - principal valor de pesquisa do App
    const query = document.getElementById("query").value;
    document.getElementById("contentResultTable").style.display = "block";
    // destrói a tabela existente antes de atualizar os dados usando o plugin DataTables
    table.destroy(); // primeiro destruir a tabela
    // faz uma solicitação (promise) para o servidor backend usando o valor de pesquisa
    fetch(`http://localhost:8080/search?query=${query}`, { method: 'GET' })
        // converte a resposta em JSON
        .then(response => response.json())
        // atualiza a tabela com os dados recuperados
        .then(data => {
            // atualiza o conteúdo da tabela com os dados recuperados
            document.getElementById("resultTable").querySelector("tbody").innerHTML = createResultHtml(data);
            // inicia o plugin DataTables na tabela #resultTable
            table = $('#resultTable').DataTable({
                "language": {
                    "url": "https://cdn.datatables.net/plug-ins/1.10.24/i18n/Portuguese-Brasil.json"
                },
                "retrieve": true
            });
        })
        // captura quaisquer erros e os imprime no console
        .catch((error) => console.error('Error:', error));
});
// adiciona um listener de evento para o botão "Limpar"
let placeholders = ["Ex: Restaurante na Paulista", "Ex: Mecânica em Curitiba ", "Ex: Café no aeroporto de Guarulhos", "Ex: Cinema em Porto Alegre", "Ex: Ponto de táxi em Copacabana", "Ex: Rodoviária em Fortaleza", "Ex: Museus em BH", "Ex: Farmácias no centro", "Ex: Supermercados próximos"];
let index = 0;
// altera o placeholder do campo de entrada a cada 2 segundos
function alterarPlaceholder() {
    let inputElement = document.getElementById("query");
    inputElement.placeholder = placeholders[index];
    index++;
    if (index >= placeholders.length) {
        index = 0;
    }
}
// adiciona um listener de evento para o "onload" do objeto window
window.onload = function() {
    setInterval(alterarPlaceholder, 2000);
};

Anatomia da aplicação

Esta aplicação web é uma combinação de HTML, CSS, JavaScript e usa uma API Rest em Go para buscar lugares próximos baseado na consulta do usuário.

HTML: O código HTML estrutura o layout do site com elementos de entrada de usuário, um formulário para enviar query, um checkbox para mostrar apenas lugares abertos agora, botões de ação, etc.

Ele também inclui área onde os resultados da API da busca serão mostrados em uma tabela.

Além disso, são incluídos os modais (janelas de diálogos) para exibir as avaliações e os horários de funcionamento dos lugares.

CSS: Os estilos CSS foram incluídos para melhorar a aparência do site. Nesse caso, é usada principalmente para ajustar a largura da tabela de resultados e para estilizar a tabela. O restante são classes do Bootstrap que já organizam todo o layout.

JavaScript: É usado para manipular as interações e ações do usuário, enviar solicitações à API, receber respostas e manipulá-las e atualizar a interface do usuário de acordo.

Especificamente, o código JavaScript faz o seguinte:

Inicia criando a tabela de resultados com DataTable, uma biblioteca JQuery que adiciona funcionalidades de interação à tabelas em HTML.
Define uma função generateModalContent que cria o conteúdo HTML a ser exibido nos modais de avaliações.
Define funções openModal e closeModals para controlar a exibição dos modais de avaliações e horários de funcionamento.
Define a função createResultHtml para criar as linhas da tabela de resultados. Esta função recebe os dados da API, filtra se o usuário marcou para ver só locais abertos agora, organiza os locais considerando se está aberto e a nota de avaliação do local.
A função getTableRow retorna um template string que é a linha da tabela de resultados.
Adiciona um listener de evento "submit" ao formulário. Quando o formulário é submetido, a consulta de entrada do usuário é capturada e uma solicitação é enviada à API. Quando a resposta é recebida da API, a tabela é preenchida com os dados da resposta.

Por fim, a função alterarPlaceholder (que nome tosco) altera o placeholder do input de consulta a cada 2 segundos, dando exemplos ao usuário de como usar a aplicação.

O código JavaScript está usando o AJAX (com a função fetch) para realizar requisições HTTP assíncronas à API do servidor, e então, usa os dados recebidos para atualizar dinamicamente a interface de usuário.

Em resumo, neste App as consultas são feitas à API REST desenvolvida em Go (backend) e os resultados são processados e apresentados na forma de uma tabela no navegador do usuário (frontend).

Este App é um exemplo simples de como uma API Restful pode ser utilizada para buscar e exibir dados dinamicamente no frontend de uma aplicação web.

Considerações finais

O desafio do projeto foi concluído com sucesso.

Se você chegou até aqui, muito provavelmente você percebeu que o App poderia ter sido feito seguindo uma série de boas práticas no desenvolvimento de software.

A minha justificativa para isso é que este era um ambiente de testes construído para errar, ou seja, o meu objetivo era cometer erros durante o processo e me colocar em situações onde eu precisaria buscar uma solução para um problema que não tinha sido previsto anteriormente.

Se este App fosse aproveitado para algo realmente em produção, muita coisa precisaria ser feita, como começar escrevendo todas as funções a partir de testes, aplicar os conceitos de arquitetura e código limpos, organizar o projeto de forma física e lógica aplicando boas práticas de desenvolvimento.

Apenas a critério de conhecimento, eu comecei a escrever a requisição HTTP só para testar o endpoint e quando eu vi tinham se passado 6 horas!

Eu cometi erros como por exemplo não ir fazendo commits, ou pior ainda, nem tinha criado um repositório Git e já tinha horas de código.

Outro erro de noob foi iniciar o repo com sono e cansado e acabar expondo o token da API na variável de ambiente e commitar isso!

Outro erro ainda mais tosco foi eu não ter feito um mock do payload do Google para implementar o frontend. Eu fiquei testando em produção, fazendo requisições na API do Google a cada teste que eu fazia 😂

O Google cobra por SKU, ou seja, a cada informação que eu busco eles me cobram. E tem informações que custam mais caro do que outras, e algumas ainda existem uma cobrança à parte quando o consumo fica dentro de um determinado range.

O resultado dessa brincadeira consumindo dados de uma API em produção foi de R$ 726,29. Obviamente que eu usei um voucher do Google Cloud para testar a aplicação e não precisei pagar nenhum real por isso.

Eu ainda tive que lidar com HTML e CSS que há muitos anos eu não colocava a mão de verdade. Javascript eu ainda sabia como fazer algumas coisas e onde procurar ajuda quando precisasse.

Eu também tive que estudar sobre Docker, CORS, requisições http a partir do resultado de uma outra requisição http, etc, etc.

No fim das contas eu considero que o resultado foi duca e certamente eu vou criar mais implementações assim, sempre testando serviços reais que podem ser usados em aplicações reais.

Se você gostou deste artigo, considere deixar um comentário. Eu vou ficar feliz em saber a tua opinião sobre tudo isso.

Até a próxima.

PoC: Evoluindo o Busca Cep com DDD e clean code

Marcelo Matz — Fri, 01 Sep 2023 16:13:53 +0000

Este post é uma continuação do post anterior. Dessa vez eu vou falar sobre as melhorias que eu fiz no código e na evolução do script do Busca Cep que agora virou até mesmo uma Prova de Conceito - PoC.

Pesquisando na internet sobre a definição de prova de conceito, eu encontrei isso aqui:

Uma prova de conceito (PoC) é uma demonstração prática da viabilidade de uma ideia ou método. É uma implementação resumida, simples e incompleta, que antecede o protótipo do projeto.

Dessa vez eu apliquei um pouco de domain-driven design, clean code, testes e fiz até mesmo um front-end vergonhoso e cheio de Javascript e CSS feitos de forma bem artesanal e o que você vai ler abaixo é a minha implementação resumida, simples e incompleta do Busca Cep.

Aqui está o link para o repositório do projeto no GitHub.

Criando um Serviço de Busca de CEP Simples com Go

O Busca Cep nasceu junto com este artigo que fala do meu aprendizado em cima da linguagem de programação Go.

Eu demonstrei como fazer uma implementação usando Go extremamente simples para consultar, consumir e tratar as informações recebidas a partir de uma requisição http para o web service da ViaCep.

Busca Cep PoC

Como o meu objetivo é estudar sobre desenvolvimento de software, eu implementei algumas melhorias em cima do exemplo do Busca Cep (criado no artigo anterior) e aproveitei essa implementação para colocar em prática alguns conceitos que são fundamentais no dia a dia de um dev.

Vamos falar de commit

O primeiro commit que eu fiz foi implementando um tratamento de erros, ainda na função Main.

Na real, na real, foi nesse momento que eu pensei em transformar tudo isso em uma prova de conceito e assim começou a pequena jornada de mudanças.

Mais adiante ainda eu viria a começar a separar o software de acordo com as responsabilidades de cada coisa, mas neste momento eu lembro de estar focado lendo sobre erros no Go.

O mais interessante de tudo, na minha opinião, é que muitas vezes por causa de uma simples mudança no código, a maneira como nós pensamos muda completamente.

Meio que faz sentido aquilo que o mano Alberto falou: "A mente que se abre a uma nova ideia jamais voltará ao seu tamanho original"

Aprendizados

O meu maior aprendizado com essa PoC foi perceber que as alterações mais sutis, foram as que mais me fizeram pensar e consequentemente isso me fez escrever menos código.

Como diz o filósofo:

Pensar melhor e executar melhor é melhor do que pensar pior e executar pior.

As startups gostam de adotar o discurso de: erre rápido, corrija rápido!
A moral é que até hoje eles estão errando rápido e levando semanas para corrigir 😂

Sobre o commit do tratamento de erros:
incluí um novo método isEmpty na struct ViaCep para verificar se todas as suas propriedades estão vazias. Isso ajuda a lidar com situações em que a pesquisa CEP não retorna nenhum resultado. Consequentemente, uma resposta de erro com a mensagem "CEP não encontrado" é retornada quando um resultado de pesquisa CEP está vazio. Essa alteração aprimora o tratamento de erros e leva a um status de resposta HTTP mais preciso.

DDD - Primeiros passos com Domain-Driven Design.

Domain-Driven Design (DDD) é uma abordagem de design de software que coloca o domínio do problema no centro do processo de desenvolvimento.

Desde que eu comecei a ler o livro do Eric Evans sobre DDD, além de me sentir um pouco mais burro, eu fui entendendo como e quando faz sentido criar essa separação em camadas.

E justamente por eu entender isso é que eu sei que uma PoC como o Busca Cep não tem a necessidade de se trabalhar um design de software mais avançado. Tanto é verdade que a primeira versão não passava de um simples script na Main.

Eu ignorei este fato de ser um projeto pequeno e defini que a ViaCep é o meu domínio principal. O meu código todo gira em torno de fazer uma requisição http no ViaCep.

A partir disso eu parti para organizar o meu projeto de forma que essa organização reflita essa separação entre as minhas regras de negócio e o domínio principal.

O commit chama-se: Refactoring ViaCep data lookup to improve modularity

Este commit reorganiza o código BuscaCep em pacotes diferentes. O principal objetivo era melhorar a modularidade do código, separando responsabilidades e tornando o código mais fácil de testar.

A estrutura ViaCep e a função BuscaCep foram movidas de main.go para um novo arquivo, domain/viacep.go. Este arquivo agora encapsula funcionalidades relacionadas à busca e verificação de dados do ViaCep.

Da mesma forma, a função BuscaCepHandle foi movida para um novo arquivo, handlers/cep.go. Este arquivo agora trata do fluxo de solicitação/resposta HTTP para pesquisas CEP (Código Postal).

Dois novos arquivos de teste domain/viacep_test.go e handlers/cep_test.go também foram criados, estabelecendo as bases para futuros casos de teste.

O que eu fiz de mudança no Busca Cep neste momento foi separar o projeto de forma física e lógica. Eu criei um diretório chamado domain e outro chamado handlers e separei os arquivos Go correspondentes dentro de cada diretório.

Em domain eu separei justamente o que está relacionado ao domínio do meu negócio, que neste caso é o web service do ViaCep onde eu faço a requisição http. Em handlers eu deixei as funções que tratam de requests, parâmetros, etc.

Por mais que existam formas mais elegantes de se fazer essa separação, pra mim o aprendizado que eu tive por simplesmente ter parado um tempo para pensar nessa separação foi sensacional.

Sem falar que isso tornou o meu código muito mais fácil de ser testado. Eu consigo pensar o que eu quero testar e consigo separar isso de uma forma mais organizada.

Testes

Enquanto eu avançava na implementação das melhorias, eu queria ter uma experiência trabalhando com testes em Go.

Tanto para erros, quanto para testes, o Go oferece um suporte built-in maravilhoso. Quem já passou raiva com outros linguagens de programação por causa de captura de erros, sabe o luxo que é ter uma lang que realmente se preocupa com isso.

Eu ainda vou estudar mais sobre testes e certamente vou escrever mais sobre este assunto. Por enquanto eu estou satisfeito com o que eu aprendi sobre testes em Go.

Refatorando

Refatorar código é uma delícia. Sério! Eu sou do pensamento que todo dev deveria amar o processo de refatorar código.

Parece que as coisas se tornam mais simples e ao mesmo tempo mais divertidas de serem feitas quando a gente refatora.

Eu comecei a refatorar o projeto, criar as separações e ver que eu podia ir mais longe, resolvi simular um front-end.

Criei uma tela que permite ao usuário fazer o input de um cep e ver as informações sobre ele.

O mais legal é que, para testar isso dentro dessa aplicação e não precisar subir o backend de um lado e o front de outro, eu fiz com que a rota principal ("/") retornasse um arquivo html, enquanto a outra rota faz a requisição para o web service.

No fim das contas, no frontend eu fiz um tratamento usando Javascript para exibir as informações na tela, mas por baixo dos panos o backend em Go é quem faz todo o processo.

Mais para frente, quem sabe, eu não faça um frontend (true) que consome o microsserviço do Busca Cep.

Por enquanto eu to feliz com o que foi feito até aqui com algo que começou super simples e foi ganhando corpo e servindo ao seu propósito de ser algo de valor acadêmico.

Considere deixar um comentário se você tem alguma dúvida, crítica ou sugestão.

Até a próxima!

Criando um Serviço de Busca de CEP Simples com Go

Marcelo Matz — Thu, 31 Aug 2023 13:33:38 +0000

Neste artigo, faremos uma imersão em um serviço básico escrito em Go que pode servir para buscar informações de um CEP (Código de Endereçamento Postal) no Brasil.

Vamos usar a API ViaCep para busca de CEPs brasileiros.

Estrutura do Código

O código é dividido em três partes principais:

A definição do tipo ViaCep, que é uma estrutura (struct) que espelha os dados retornados pela API ViaCep.
A função main, que inicia um servidor HTTP e define o roteamento.
As funções BuscaCepHandle e BuscaCep que lidam com a lógica principal da aplicação.

Definindo o tipo ViaCep

Vamos definir o tipo ViaCep como uma estrutura com vários campos do tipo string. Esses campos refletem as propriedades do objeto JSON que recebemos da API ViaCep.

type ViaCep struct {
    Cep         string `json:"cep"`
    Logradouro  string `json:"logradouro"`
    Complemento string `json:"complemento"`
    Bairro      string `json:"bairro"`
    Localidade  string `json:"localidade"`
    Uf          string `json:"uf"`
    Ibge        string `json:"ibge"`
    Gia         string `json:"gia"`
    Ddd         string `json:"ddd"`
    Siafi       string `json:"siafi"`
}

As tags json:"..." anexadas a cada campo da struct fazem o rolê de instruir o pacote encoding/json sobre como fazer o mapeamento do JSON para a struct em Go.

Função Main

Na função main começamos escutando na porta 8080 e configuramos um roteamento de URL simples, onde todas as requisições para a rota / são tratadas pela função BuscaCepHandle.

func main() {
    http.HandleFunc("/", BuscaCepHandle)
    err := http.ListenAndServe(":8080", nil)
    if err != nil {
    return
    }
}

Se um erro ocorrer durante http.ListenAndServe, nós simplesmente retornamos e encerramos a execução do programa.

Funções BuscaCepHandle e BuscaCep

A função BuscaCepHandle é nossa manipuladora de requisições HTTP. Ela lida com todas as solicitações que chegam à raíz ("/") da nossa aplicação.

func BuscaCepHandle(w http.ResponseWriter, r *http.Request) {
    if r.URL.Path != "/" {
        w.WriteHeader(http.StatusNotFound)
        return
    }
    cepParam := r.URL.Query().Get("cep")
    if cepParam == "" || len(cepParam) != 8 {
        w.WriteHeader(http.StatusBadRequest)
        return
    }
    // ... (código truncado por brevidade)
}

Esta função verifica se o parâmetro do cep foi passado na requisição e se ele possui 8 caracteres. Se o CEP não for válido, devolvemos um status HTTP 400.

A função BuscaCep é uma função auxiliar usada por BuscaCepHandle para fazer a solicitação real para a API ViaCep e processar os dados de resposta.

func BuscaCep(cep string) (*ViaCep, error) {
    url := "https://viacep.com.br/ws/" + cep + "/json/"
    resp, err := http.Get(url)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()
    body, err := io.ReadAll(resp.Body)
    if err != nil {
        return nil, err
    }
    var viaCep ViaCep
    err = json.Unmarshal(body, &viaCep)
    if err != nil {
        return nil, err
    }
    return &viaCep, nil
}

Esta função faz uma requisição para a API ViaCep, lê a resposta e a deserializa em um objeto ViaCep.

A função retorna um ponteiro para um objeto ViaCep ou um erro, caso algo dê errado durante a solicitação HTTP ou a deserialização do JSON da resposta.

Abaixo eu deixo um exemplo do código completo para você analisar:

package main

import (
    "encoding/json"
    "io"
    "net/http"
)

type ViaCep struct {
    Cep         string `json:"cep"`
    Logradouro  string `json:"logradouro"`
    Complemento string `json:"complemento"`
    Bairro      string `json:"bairro"`
    Localidade  string `json:"localidade"`
    Uf          string `json:"uf"`
    Ibge        string `json:"ibge"`
    Gia         string `json:"gia"`
    Ddd         string `json:"ddd"`
    Siafi       string `json:"siafi"`
}

func main() {
    http.HandleFunc("/", BuscaCepHandle)
    err := http.ListenAndServe(":8080", nil)
    if err != nil {
        return
    }
}

func BuscaCepHandle(w http.ResponseWriter, r *http.Request) {
    if r.URL.Path != "/" {
        w.WriteHeader(http.StatusNotFound)
        return
    }
    cepParam := r.URL.Query().Get("cep")
    if cepParam == "" || len(cepParam) != 8 {
        w.WriteHeader(http.StatusBadRequest)
        return
    }
    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(http.StatusOK)
    viaCep, err := BuscaCep(cepParam)
    if err != nil {
        w.WriteHeader(http.StatusInternalServerError)
        return
    }
    err = json.NewEncoder(w).Encode(viaCep)
    if err != nil {
        return
    }

}

func BuscaCep(cep string) (*ViaCep, error) {
    url := "https://viacep.com.br/ws/" + cep + "/json/"
    resp, err := http.Get(url)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()
    body, err := io.ReadAll(resp.Body)
    if err != nil {
        return nil, err
    }
    var viaCep ViaCep
    err = json.Unmarshal(body, &viaCep)
    if err != nil {
        return nil, err
    }
    return &viaCep, nil
}

Pronto!
Isso é o suficiente para criar um microsserviço simples de busca de CEP usando Go.

Se você quiser ter acesso ao código completo, pode acessar o repositório do projeto no GitHub.

Embora seja uma aplicação bastante simples, ela forma a base de como um serviço da vida real pode ser construído utilizando Go para buscar e fornecer informações do CEP a partir de uma API.

Melhorias

Apesar de este ser um código que funciona e retorna o dado que esperamos, existem algumas coisas que podem ser melhoradas neste código.

Tratamento de erros: Quando um erro ocorrer, pode ser interessante retornar a mensagem de erro real ao invés de apenas um código de status HTTP para ajudar na depuração.

Lembre-se de que esta não é uma boa prática para um ambiente de produção, pois pode expor detalhes do sistema a usuários indesejados.

Em um ambiente de produção, uma coisa que você pode fazer é logar o erro e retornar um ID de log para o cliente como uma referência para ele usar na abertura de um atendimento de suporte, por exemplo.

Endpoint do servidor: Atualmente o serviço está configurado para escutar todas as requisições na raiz ("/").

Poderia ser mais inteligente e útil ter um endpoint específico para essa funcionalidade como "/ceps" ou "/buscarCep". O exemplo não considerou isso justamente por ser um exemplo!

Validação do CEP: Poderia ser interessante adicionar uma validação mais forte para o campo 'cep'.

Atualmente, o código apenas verifica se tem 8 caracteres, mas pode existir um cenário onde a entrada tenha 8 caracteres mas não seja um CEP válido. 🤡

Testes: Incluir testes de unidade e integração para garantir que o serviço está funcionando conforme esperado.

Na verdade tudo isso deveria ter começado a partir da escrita de testes. My bad

Goroutine no BuscaCep: A função do BuscaCep que chama um serviço externo poderia considerar utilizar uma goroutine para executar essa tarefa assincronamente.

Verificações HTTP: A resposta da função http.Get(url) pode vir com statusCode não 200. Seria inteligente fazer essa verificação antes de ler o corpo da resposta.

Agora sim, pronto!

Talvez quando você ler este post, os arquivos no repositório já tenham sido alterados e algumas dessas (ou todas) melhorias implementadas.

E se você tiver sugestões que colaborem com o aprendizado de outras pessoas sobre este mesmo assunto, fique a vontade para fazer um pull-request no GitHub.

Até a próxima 🤘

Benchmark Go: Marshal x Encoder com requisição http

Marcelo Matz — Tue, 29 Aug 2023 17:46:11 +0000

Este artigo tem a obrigação de começar explicando que sim, eu sei que sistematicamente realizar requisições de rede dentro de um benchmark não é uma prática recomendada devido à variabilidade e à falta de controle sobre a rede, que pode levar a resultados de benchmark inconsistentes. E provavelmente vai. Mas eu vou fazer mesmo assim.

Faz um Bench!

Nos meus estudos em programação eu aprendi que, quando eu tenho dúvida sobre o que usar, testar é a melhor forma de entender o que faz mais sentido usar.

Neste artigo eu vou falar sobre testes usando Marshal e Encoder, e também vou fazer a deserialização de um JSON usando Unmarshal e Decoder a partir de uma requisição HTTP.

Um pouco de história

Quem é melhor, Marshal ou Encoder?

Em Go, json.Marshal e json.NewEncoder são usados para converter a estrutura de dados em Go para JSON, mas eles são usados de maneiras diferentes.

A função json.Marshal retorna uma representação JSON da estrutura de dados Go na forma de uma []byte e um error caso ocorra algum.

Por outro lado, json.NewEncoder pega um io.Writer (como um os.File ou http.ResponseWriter) e retorna um novo *json.Encoder que pode ser usado para transmissão de stream da estrutura de dados Go para o io.Writer em formato JSON.

Aqui um exemplo usando json.Marshal:

package main

import (
    "encoding/json"
    "fmt"
    "log"
)

type Person struct {
    Name string
    Age  int
}

func main() {
    p := &Person{"Ada", 36}
    b, err := json.Marshal(p)
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println(string(b))
}

Outro exemplo usando json.NewEncoder:

package main

import (
    "encoding/json"
    "log"
    "os"
)

type Person struct {
    Name string
    Age  int
}

func main() {
    p := &Person{"Ada", 36}
    err := json.NewEncoder(os.Stdout).Encode(p)
    if err != nil {
        log.Fatal(err)
    }
}

Ambas as amostras de código produzirão a mesma saída JSON {"Name":"Ada","Age":36}.

Em resumo

A principal diferença de desempenho entre json.Marshal e json.NewEncoder está na alocação de memória.

json.Marshal converte a estrutura de dados em Go em uma sequência JSON completamente na memória e, em seguida, retorna essa sequência em formato []byte.

Esta abordagem é rápida e simples, mas pode ser um problema se você estiver tentando processar uma grande quantidade de dados de uma vez - você pode facilmente ficar sem memória.

Por outro lado, json.NewEncoder escreve a saída JSON diretamente para um io.Writer como um fluxo, por isso é mais eficiente em termos de memória. Ele não precisa alocar espaço para a estrutura de dados inteira em memória de uma só vez, então você pode processar volumes de dados muito maiores sem se preocupar com problemas de memória.

Se você está manipulando uma pequena quantidade de dados e precisa de uma sequência JSON para uso no programa, json.Marshal é uma escolha adequada.

Se você estiver processando uma grande quantidade de dados ou quer enviar o JSON diretamente para um http.ResponseWriter ou para um arquivo, json.NewEncoder é geralmente uma opção melhor devido ao seu menor uso de memória.

No entanto, a diferença no desempenho e no uso de memória entre os dois provavelmente só será perceptível para estruturas de dados muito grandes.

Para a maioria dos usos diários, você pode usar o que achar mais conveniente e quando alguém perguntar para você qual é melhor, responda: depende!

Além do Go

Pacotes de terceiros que fazem a mão do JSON

Existem outras opções e pacotes de terceiros disponíveis na linguagem Go para manipulação de JSON. Neste caso eu vou falar de uma em especial.

jsoniter: jsoniter é uma biblioteca que afirma ser compatível com encoding/json mas 4x a 6x mais rápida.

O link para o repo do jsoniter.

Usar o JsonIter em Go é simples como usar qualquer outro pacote externo.

Aqui um exemplo:

package main

import (
    "fmt"
    "github.com/json-iterator/go"
)

type Person struct {
    Name string
    Age  int
}

func main() {
    var json = jsoniter.ConfigCompatibleWithStandardLibrary
    p := &Person{"Ada", 36}
    b, err := json.Marshal(p)
    if err != nil {
        panic(err)
    }
    fmt.Println(string(b))
}

Se o desempenho for um problema crítico, você pode eventualmente considerar a escrita de suas próprias funções de serialização / des-serialização. No entanto, isso normalmente só é necessário em circunstâncias muito específicas e as diferenças de desempenho entre os pacotes prontos para uso são geralmente pequenas para a maioria dos casos de uso.

Em resumo nós temos os recursos nativos do Go onde podemos tanto usar o Marshal quanto o Encoder e podemos usar o jsoniter também com Marshal e Encoder.

Vamos escrever um teste para comparar eles, fazendo uma requisição http para a API do ViaCep.

Como eu vou fazer uma requisição http, vou utilizar a deserialização com Unmarshal e Decoder. Bora!

Deserializando o JSON de um request HTTP

O exemplo de código que vamos usar:

package main

import (
    "bytes"
    "encoding/json"
    "io/ioutil"
    "net/http"
    "testing"

    jsoniter "github.com/json-iterator/go"
)

type Info struct {
    Cep         string `json:"cep"`
    Logradouro  string `json:"logradouro"`
    Complemento string `json:"complemento"`
    Bairro      string `json:"bairro"`
    Localidade  string `json:"localidade"`
    Uf          string `json:"uf"`
    Unidade     string `json:"unidade"`
    Ibge        string `json:"ibge"`
    Gia         string `json:"gia"`
}

func fetchData(url string) ([]byte, error) {
    resp, err := http.Get(url)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()

    return ioutil.ReadAll(resp.Body)
}

func BenchmarkEncodingJsonUnmarshal(b *testing.B) {
    data, _ := fetchData("https://viacep.com.br/ws/01001000/json/")
    info := &Info{}
    for i := 0; i < b.N; i++ {
        if err := json.Unmarshal(data, &info); err != nil {
            b.Fatal(err)
        }
    }
}

func BenchmarkEncodingJsonDecoder(b *testing.B) {
    data, _ := fetchData("https://viacep.com.br/ws/01001000/json/")
    info := &Info{}
    for i := 0; i < b.N; i++ {
        if err := json.NewDecoder(bytes.NewBuffer(data)).Decode(&info); err != nil {
            b.Fatal(err)
        }
    }
}

func BenchmarkJsoniterUnmarshal(b *testing.B) {
    data, _ := fetchData("https://viacep.com.br/ws/01001000/json/")
    info := &Info{}
    var json = jsoniter.ConfigCompatibleWithStandardLibrary
    for i := 0; i < b.N; i++ {
        if err := json.Unmarshal(data, &info); err != nil {
            b.Fatal(err)
        }
    }
}

func BenchmarkJsoniterDecoder(b *testing.B) {
    data, _ := fetchData("https://viacep.com.br/ws/01001000/json/")
    info := &Info{}
    var json = jsoniter.ConfigCompatibleWithStandardLibrary
    for i := 0; i < b.N; i++ {
        if err := json.NewDecoder(bytes.NewBuffer(data)).Decode(&info); err != nil {
            b.Fatal(err)
        }
    }
}

Em cada um desses benchmarks, estamos fazendo uma chamada GET para a API, obtendo os dados em um formato JSON, e em seguida deserializando esses dados JSON para uma instância do struct Info.

Lembre-se de cuidar com carinho dos erros. Aqui estou ignorando o erro do fetchData para manter o foco na comparação de desempenho entre Unmarshal e Decoder. O erro que erre!

Você pode acessar o repositório do código no GitHub e rodar o teste na sua máquina. Na minha máquina funcionou!

Os testes são:

Nos benchmarks que estão no código do teste que foi feito, existem quatro operações sendo testadas:

a deserialização do JSON usando json.Unmarshal (BenchmarkEncodingJsonUnmarshal)
a deserialização usando json.NewDecoder (BenchmarkEncodingJsonDecoder)
a deserialização usando jsoniter.Unmarshal (BenchmarkJsoniterUnmarshal)
deserialização usando jsoniter.NewDecoder (BenchmarkJsoniterDecoder)

Detalhe: As operações estão rodando em uma máquina Apple M1 (goos:darwin, goarch: arm64).

Os resultados mostram que jsoniter (tanto Unmarshal quanto Decoder) é mais rápido que o pacote encoding/json padrão.

Isso é consistente com a reputação de jsoniter de ser uma biblioteca de JSON mais rápida, já que foi projetada com o desempenho em mente.

Alguns dados do bench

BenchmarkEncodingJsonUnmarshal: A operação de deserialização usando json.Unmarshal foi concluída em 2233 nanossegundos (ns) por operação. Foram realizadas 496503 operações.

BenchmarkEncodingJsonDecoder: A operação de deserialização usando json.NewDecoder foi concluída em 2678 ns por operação. Foram realizadas 484986 operações. Esse número é maior do que Unmarshal possivelmente porque Decoder é mais adequado para fluxos de dados.

BenchmarkJsoniterUnmarshal: A operação de deserialização usando jsoniter.Unmarshal foi concluída em 538.3 ns por operação. Foram realizadas 2000696 operações.

BenchmarkJsoniterDecoder: A operação de deserialização usando jsoniter.NewDecoder foi concluída em 676.8 ns por operação. Foram realizadas 1633261 operações.

Observe que, apesar de jsoniter ser mais rápido que json, existem outros aspectos a considerar ao escolher qual usar.

Alguns dos aspectos mais notáveis seriam a compatibilidade da API (a API do json é estável desde Go 1, enquanto a de jsoniter pode não ser) e a quantidade de recursos disponíveis (há provavelmente mais tutoriais, exemplos de código, e respostas do StackOverflow para json do que para jsoniter).

É isso! Se você gostou (ou não) considere deixar um comentário.

Manipulando arquivos: um CRUD de arquivos em Go

Marcelo Matz — Mon, 28 Aug 2023 22:31:46 +0000

Como Criar um CRUD de arquivos em Go

Um guia básico e passo a passo

Uma das coisas que dev mais faz no seu dia a dia é resolver problemas aplicando os fundamentos da programação.

Um destes fundamentos é a capacidade de ler e escrever em arquivos.

Quem trabalha desenvolvendo software, acaba trabalhando com manipulação de arquivos em algum momento.

Neste artigo eu vou mostrar como criar um CRUD (Create, Read, Update, Delete) de arquivo usando a linguagem de programação Go.

Vale ressaltar que neste exemplo eu vou usar os próprios recursos do Go sem a necessidade importar nenhuma biblioteca externa para o meu software.

Caso você queria pesquisar mais a fundo sobre cada biblioteca usada na criação deste exemplo, você pode consultar a documentação da Standard Library do Go.

Se você preferir ir direto para o repositório do código ao invés de ler o artigo, você pode acessar o repositório no GitHub.

Show me the code

O ponto de partida que qualquer software em Go é a partir da função main contida no pacote main. Eu vou escrever todo o código dentro da mesma função main.

Abaixo temos a estrutura base do nosso software:

package main

import (
    "bufio"
    "fmt"
    "io"
    "os"
)

func main() {
    // Agora só falta implementar
    // Duas barras e um texto indica um comentário
}

O CRUD na prática

Create

Eu vou começar implementando o Create do CRUD e para fazer isso em Go eu vou usar o método nativo da linguagem os.Create().

O pacote os do Go permite acessar diversos recursos do sistema operacional, e como nós queremos trabalhar com arquivos, nada mais justo do que usar o pacote que permite isso.

f, err := os.Create("test.txt")
if err != nil {
    panic(err)
}
// Não esqueça de fechar o arquivo quando a criação for concluída.
defer func(f *os.File) {
    err := f.Close()
    if err != nil {
        panic(err)
    }
}(f)

Dentro da função Main nós temos uma variável f que recebe como valor o os.Create().

Note que além da variável f existe uma outra variável chamada err que também foi criada.

Em Go quando nós temos algumaCoisa := "valorDeAlgumaCoisa" significa que nós estamos criando uma variável e ao mesmo tempo estamos atribuindo um valor. O := é o operador Marmota (logo do Go) usado para criação e inferência de tipo.

O processo se resume em:

1) Criar a variável `f`

(ou file, ou arquivo ou o nome que você quiser) e criar também uma variável para receber o erro err.

O método (função) Create do pacote os do Go funciona da seguinte forma: ele recebe um nome como parâmetro e retorna dois valores: O primeiro retorno é o arquivo em si (no caso um ponteiro para o arquivo, mas não vou entrar no mérito dos ponteiros aqui) e também recebe como retorno um erro.

2) Usar o método `defer` para garantir que o arquivo vai ser fechado depois que ele for criado.

O defer em Go é utilizado para garantir que uma função seja executada posteriormente.

A instrução defer agenda uma função a ser chamada após a função que a contém ser concluída.

Pode parecer confuso, mas você vai perceber que em outras palavras, a função é "adiada" até que o resto do código seja executado.

Um uso comum para defer é justamente para fechar um arquivo, garantindo que, independentemente do que acontecer no código após a abertura do arquivo, ele (o arquivo) será fechado quando a função for terminada.
Por exemplo:

file, err := os.Open("file.txt")
if err != nil {
    log.Fatal(err)
}

defer file.Close()

// Outras operações no arquivo...
// O arquivo será fechado quando a função terminar

Neste exemplo, file.Close() só será chamado depois que o resto do código na função for executado. Isso é útil porque mesmo se uma operação subsequente no arquivo resultar em um erro e você retornar da função mais cedo do que o esperado, o arquivo ainda será fechado corretamente.

Defer e Closure

Outra maneira de usar o defer neste caso é em conjunto com uma função anônima. Closure é uma função anônima.

Muitas vezes é recomendado usar closures com a declaração defer, principalmente quando estamos lidando com operações que também envolvem erros, como fechamento de arquivos ou conexões em Go.

Um dos principais motivos para combinar defer com uma closure é que a closure pode acessar e manipular as variáveis definidas no escopo onde ela foi criada.

Portanto, ela pode lidar com valores ou estados que possam ter mudado ao longo do tempo antes de o defer ser realmente executado.
Aqui está um exemplo de fechamento de um arquivo usando closure e defer:

f, err := os.Open("file.txt")
if err != nil {
    log.Fatal(err)
}

defer func(f *os.File) {
    if err := f.Close(); err != nil {
        log.Fatal(err) // ou qualquer outra manipulação de erro
    }
}(f)

// Outras operações no arquivo...

Em resumo, após criarmos um arquivo usando os.Create("nomeDoArquivo.extensaoDoArquivo") nós precisamos fechar ele. De acordo com a implementação do método na standard library, na hora que passamos o nome do arquivo como parâmetro para a função Create, caso o arquivo não exista ele vai ser criado e, caso ele já exista, o Go faz um truncate do arquivo.

Read

Ler do Arquivo

A leitura do arquivo é feita em duas etapas. Primeiro, abrimos o arquivo com os.Open() e em seguida lemos o arquivo utilizando bufio.NewReader().

f, err := os.Open("test.txt")
if err != nil {
    panic(err)
}
defer func(f *os.File) {
    err := f.Close()
    if err != nil {
        panic(err)
    }
}(f)

reader := bufio.NewReader(f)
buffer := make([]byte, 10)
for {
    n, err := reader.Read(buffer)
    if err != nil && err != io.EOF {
        panic(err)
    }
    if n == 0 {
        break
    }
    fmt.Print(string(buffer[:n]))
}

Agora mais duas variáveis foram criadas. Uma reader e uma buffer. _Você pode abrir um arquivo sem buffer, mas lembre-se que dependendo do tamanho do arquivo ele pode exceder a memória disponível e acabe gerando um erro.

A variável reader agora armazena o retorno do método bufio.NewReader(f) onde o f nós estamos passando como parâmetro para este método.

O mais legal de trabalhar com buffer é você poder definir o tamanho da fatia que você quer ler de cada vez. No exemplo eu estou usando o método make para criar um slice de byte de tamanho 10.

buffer := make([]byte, 10)

A função make é função built-in do Go que aloca e inicializa um objeto do tipo slice, map ou char. No caso eu estou usando o tipo slice.

Você pode consultar a documentação do Go para saber mais sobre o pacote de tipos em Go.

Continuando com a explicação do exemplo, depois disso eu uso um laço for para fazer algumas coisas:

n, err := reader.Read(buffer) Aqui eu estou acessando o método Read da função bufio.NewReader(f) que eu usei para criar o meu reader e salvando na variável n. _A variável de erro eu já expliquei antes como funciona.

Observe no código exemplo como lidamos com o io.EOF (End of File).

if err != nil && err != io.EOF {
        panic(err)
    }

É importante lembrar de fazer isso porque a leitura pode retornar io.EOF a qualquer momento, por isso já tratamos isso no for e é assim que nós sabemos quando terminamos de ler o arquivo.

Sobre o io.EOF (End Of File): ele é um erro que é comum em operações de arquivo e é usado para indicar que o fim de um arquivo foi atingido.

Como uma convenção em programação, sempre que uma função está lendo de um arquivo e atinge o fim do arquivo, essa função retorna io.EOF.

Isso é útil para que o código que chamou a função de leitura possa saber quando parar de ler.

O nosso exemplo é bastante simples mas ele mostra como usamos o io.Reader (uma interface que abstrai a leitura de dados de uma fonte).

Nós usamos um loop (for) para tentar ler 10 bytes do reader de cada vez em nosso buffer.

Se o reader.Read() encontrar um erro que não seja io.EOF, o programa entra em pânico.

Uma coisa que eu sempre gostei em Go foi poder definir que ele vai entrar em pânico caso algum erro aconteça porque literalmente a função que trata isso se chama panic 😂

Se nenhum byte for lido (n == 0), isso significa que atingimos io.EOF e o arquivo não tem mais nada a ser lido, então saímos do loop.

Caso contrário, processamos os bytes que foram lidos com sucesso.

Então, resumindo, io.EOF é usado em Go (e muitas outras linguagens) para sinalizar que a leitura de um arquivo ou outra fonte de entrada chegou ao fim. Ele é útil para controlar loops e outras estruturas que continuam a ler até que não haja mais nada para ler.

Update

Escrever no Arquivo

Depois de criar o arquivo, podemos escrever nele. Para fazer isso, utilizamos a função f.Write(), que aceita uma fatia de bytes como argumento.

size, err := f.Write([]byte("Criando conteúdo do arquivo"))
if err != nil {
    panic(err)
}

Assegure-se de sincronizar os dados no disco usando f.Sync() para garantir que todos os dados pendentes sejam efetivamente escritos no arquivo.

err = f.Sync()
if err != nil {
    panic(err)
}

Escrever em um arquivo é algo bem simples. No exemplo eu usei uma variável chamada size para armazenar o retorno da função Write e uma variável de erro, como já de costume.

Abaixo eu mostro como imprimir no console essa informação usando o pacote fmt e a função Printf para formatar a saída de texto usando o %s(de string) que vai ser substituído pelo conteúdo do arquivo, convertido em string.

Além disso eu também mostro o tamanho do arquivo em bytes.

fmt.Printf("Tamanho: %d bytes\n", size)
    fmt.Printf("Conteúdo do arquivo: %s\n", string(arquivo))

Existe um outro método chamado writeString onde eu não precisaria passar um slice de bytes, porém, entretanto, contudo, eu teria que garantir que em 100% das vezes o que tipo de dado que vai trafegar ali é do tipo string. Se eu tenho a opção de trabalhar com uma cadeia de bytes, sejam eles em algum momento um string ou não, eu vou optar por isso.

De qualquer forma, escrever dados em um arquivo é algo que se torna muito fácil quando aproveitamos os recursos da linguagem.

Delete

Apagando um arquivo

Apagar um arquivo usando Go é extremamente simples. Para deletar um arquivo, usamos a função os.Remove().

err = os.Remove("test.txt")
if err != nil {
    panic(err)
}
fmt.Println("\nArquivo deletado com sucesso!")

Deployando

Neste tutorial eu te mostrei como, fundamentalmente, fazer operações CRUD em arquivos no Go.

Abaixo eu deixo um exemplo do código completo. No início do post tem o link para o repositório no GitHub.

package main

import (
    "bufio"
    "fmt"
    "io"
    "os"
)

func main() {
    // Criar um novo arquivo
    f, err := os.Create("test.txt")
    if err != nil {
        panic(err)
    }
    defer func(f *os.File) {
        err := f.Close()
        if err != nil {
            panic(err)
        }
    }(f)

    // Escrevendo no arquivo criado
    size, err := f.Write([]byte("Criando conteúdo do arquivo"))
    if err != nil {
        panic(err)
    }

    // Sincroniza os dados no disco
    err = f.Sync()
    if err != nil {
        panic(err)
    }

    arquivo, err := os.ReadFile("test.txt")
    if err != nil {
        panic(err)
    }

    fmt.Println("Arquivo criado com sucesso!")
    fmt.Printf("Tamanho: %d bytes\n", size)
    fmt.Printf("Conteúdo do arquivo: %s\n", string(arquivo))

    // Abrindo um arquivo existente
    f2, err := os.Open("test.txt")
    if err != nil {
        panic(err)
    }
    defer func(arquivo2 *os.File) {
        err := arquivo2.Close()
        if err != nil {
            panic(err)
        }
    }(f2)

    // Lendo arquivo usando bufio
    reader := bufio.NewReader(f2)
    buffer := make([]byte, 10)
    for {
        n, err := reader.Read(buffer)
        if err != nil && err != io.EOF {
            panic(err)
        }
        if n == 0 {
            break
        }
        fmt.Print(string(buffer[:n]))
    }

    // Deletando um arquivo
    /*
        err = os.Remove("test.txt")
        if err != nil {
            panic(err)
        }
        fmt.Println("\nArquivo deletado com sucesso!")
    */
}

Assim como em qualquer linguagem de programação, existem muitas nuances que nós podemos explorar mas eu considero este um ótimo ponto de partida.

Espero que este guia tenha sido útil e encorajo a todos a continuar explorando e aprendendo Go!