Forem: Renan de Andrade

Como usar tipos customizados em Golang

Renan de Andrade — Thu, 19 Jun 2025 21:26:22 +0000

Introdução

Uma das coisas mais comuns em códigos escritos na linguagem Go é o uso de tipos customizados utilizando structs. Geralmente usamos estes tipos para declarar entidades, transportar valores de forma estruturada e etc. Por exemplo, O código abaixo é muito comum em muitas aplicações:

type Person struct {
  Name string
  Document string
  Email string
}

Outros tipos customizados

Mas assim como structs, podemos utilizar outros tipos primitivos da linguagem para criar tipos customizados, abrindo assim um leque de oportunidades. O processo de criação é idêntico ao mostrado anteriormente, mas usando outro tipo primitivo como base. Aqui vão alguns exemplos:

// Tipo customizado baseado em string
type MyCustomString string

// Baseado em int
type MyCustomInt int

// Baseado em float
type MyCustomFloat64 float64

// Baseado em boolean
type MyCustomBool bool

// Baseado em slice
type MyCustomSlice []string

// Baseado em... já deu para entender, né!?

Mas como eu uso?

Usar esses tipos novos é tão simples quanto você está pensa. Eles operam da mesma forma que seus tipos base, assim como a struct. Dá uma olhada:

func main() {
    // Declarando variáveis com tipos personalizados
    var str MyCustomString = "example"
    var num MyCustomInt = 42
    var flt MyCustomFloat64 = 3.14
    var boolean MyCustomBool = true
    var slice = MyCustomSlice{"example1", "example2"}

    // Operando com as variáveis
    str += " string"
    num += 10
    flt *= 2.0
    boolean = !boolean
    slice = append(slice, "example3")

    // Exibindo os valores e tipos das variáveis
    log.Printf("Value of str: %s, type: %T", str, str)             //Value of str: example string, type: main.MyCustomString
    log.Printf("Value of num: %d, type: %T", num, num)             //Value of num: 52, type: main.MyCustomInt
    log.Printf("Value of flt: %.2f, type: %T", flt, flt)           //Value of flt: 6.28, type: main.MyCustomFloat64
    log.Printf("Value of boolean: %t, type: %T", boolean, boolean) //Value of boolean: false, type: main.MyCustomBool
    log.Printf("Value of boolean: %s, type: %T", slice, slice)     //Value of boolean: [example1 example2 example3], type: main.MyCustomSlice
}

Legal, né?!

Adicionando métodos

Uma possibilidade interessante que essa abordagem nos traz é a capacidade de as variáveis criadas a partir destes tipo chamarem métodos customizados. Isso pode ter várias aplicações interessantes. Olha só:

type MyCustomInt int

func (my MyCustomInt) Positive() bool {
    return my > 0
}

func main() {
  var num MyCustomInt = 42
  log.Println("num Positive:", num.Positive()) // num Positive: true
}

Olhando aquele nosso exemplo inicial da struct Person, podemos aplicar esses princípios para os campos Email e Document ao criar um novo tipo para cada um:

type Document string

func (d Document) Validate() bool {
    return len(d) > 0
}

type Email string

func (e Email) Validate() bool {
    if len(e) == 0 {
        return false
    }

    return strings.Contains(string(e), "@") && strings.Contains(string(e), ".")
}

Assim cada tipo sabe como fazer sua própria validação. A Person fica assim então:

type Person struct {
    Name     string
    Document Document
    Email    Email
}

Olha como o uso fica legal:

    person := Person{
        Name:     "John Doe",
        Document: "123456789",
        Email:    "johndoe@test.com",
    }

    log.Printf("Person: %+v", person)                                   // Person: {Name:John Doe Document:123456789 Email:johndoe@test.com}
    log.Printf("Person Document valid: %t", person.Document.Validate()) //Person Document valid: true
    log.Printf("Person Email valid: %t", person.Email.Validate()) //Person Email valid: true

Dá pra usar interfaces

Para melhorar ainda mais nosso exemplo, podemos fazer a pergunta: E se eu quiser usar o mesmo campo Document para vários tipos de documento (digamos que RG e CPF)?

Podemos então mudar o tipo de Document para interface, e criar os tipos dos outros documentos que implementam esta nova interface. Melhor mostrando, né?

type Document interface {
    Validate() bool
}

type DocumentRG string
type DocumentCPF string

func (d DocumentRG) Validate() bool {
    log.Println("RG validation logic")
    return len(d) > 0
}

func (d DocumentCPF) Validate() bool {
    log.Println("CPF validation logic")
    return len(d) > 0
}

Na Person nada muda, tá?!

Mas se liga aqui como fica o uso:

    person := Person{
        Name:     "John Doe",
        Document: DocumentCPF("123456789"),
        Email:    "johndoe@test.com",
    }

    person2 := Person{
        Name:     "Maike Doe",
        Document: DocumentRG("0987654321"),
        Email:    "maikedoe@test.com",
    }

    log.Printf("Person1: %+v", person)                                   // Person1: {Name:John Doe Document:123456789 Email:johndoe@test.com}
    log.Printf("Person1 Document valid: %t", person.Document.Validate()) // CPF validation logic // Person1 Document valid: true

    log.Printf("Person2: %+v", person2)                                   // Person2: {Name:Maike Doe Document:0987654321 Email:maikedoe@test.com}
    log.Printf("Person2 Document valid: %t", person2.Document.Validate()) //RG validation logic //Person2 Document valid: true

Dessa forma, você pode ter vários tipos de documentos, e quem vai implementar é quem decide qual vai usar.

Utilizando enums

Para fecharmos, podemos fazer a pergunta: E se eu quiser ter um campo que indique o tipo de documento?

A gente pode usar Enums para isso. Espia:

type DocumentType uint

const (
    DocumentTypeRG DocumentType = iota
    DocumentTypeCPF
    DocumentTypeCNH
    DocumentTypePassaporte
)

func (d DocumentType) String() string {
    switch d {
    case DocumentTypeRG:
        return "RG"
    case DocumentTypeCPF:
        return "CPF"
    case DocumentTypeCNH:
        return "CNH"
    case DocumentTypePassaporte:
        return "Passaporte"
    default:
        return "Unknown"
    }
}

Adicionamos então o campo DocumentType em Person:

type Person struct {
    Name         string
    Document     Document
    DocumentType DocumentType
    Email        Email
}

E para usar também é bem simples:

    person := Person{
        Name:         "John Doe",
        Document:     DocumentCPF("123456789"),
        DocumentType: DocumentTypeCPF,
        Email:        "johndoe@test.com",
    }

    person2 := Person{
        Name:         "Maike Doe",
        Document:     DocumentRG("0987654321"),
        DocumentType: DocumentTypeRG,
        Email:        "maikedoe@test.com",
    }

    log.Printf("Person1: %+v", person)                 // Person1: {Name:John Doe Document:123456789 DocumentType:CPF Email:johndoe@test.com}
    log.Println("Document Type:", person.DocumentType) // Document Type: CPF

    log.Printf("Person2: %+v", person2)                 // Person2: {Name:Maike Doe Document:0987654321 DocumentType:RG Email:maikedoe@test.com}
    log.Println("Document Type:", person2.DocumentType) // Document Type: RG

E voilà!

Vimos então que podemos criar tipos customizados baseados em tipos primitivos, chamar métodos através deles, implementar interfaces e até utilizar Enums.

E aí, o que achou dessas dicas? Deixe aí nos comentários.

Obs. Cover image criada com IA.

Melhorando a resiliência de sua aplicação com Stale Cache

Renan de Andrade — Thu, 15 May 2025 00:33:14 +0000

Durante nossa jornada como desenvolvedores de software é possível encontrarmos problemas que exigem técnicas inusitadas para resolvê-los. Mas a grande maioria pode ser resolvida com técnicas simples.

O assunto que este artigo apresenta pode ser não ser o mais badalado do momento, mas pode ser bastante útil se usado de forma certa.

O problema

Imagine que você tem uma aplicação Web simples, com um proxy reverso na frente, uma API rodando na sua linguagem favorita (vamos utilizar Go aqui :)), um banco Redis para cache, um banco de dados e uma chamada para uma aplicação externa. Como no exemplo a seguir:

A aplicação externa consumida provê dados que enriquecem as informações dos produtos oferecidos por sua aplicação. Mas o temos um problema: essa API externa é muito instável. Dependendo da carga aplicada, ela começa a ficar bem lenta e às vezes até pára de responder.

Você não pode deixar que seus clientes sintam essa instabilidade (pelo menos não deveria), como resolver isso então?

Solução

Dentre as várias técnicas de resiliência que podem ser aplicadas, vamos trabalhar com uma bem simples aqui: fazer caching no Redis. É uma solução óbvia, dado que sua aplicação já possui um Redis.

Mas um ponto importante a se considerar é que todo caching tem um TTL (Time to Live). E sempre há um trade-off na escolha de um valor para essa configuração (como tudo na Engenharia de Software). Se o tempo for muito curto, o cache pode não ser eficiente. Se for muito longo, você pode entregar dados muito desatualizados para o cliente.

Isso significa que em algum momento você vai precisar fazer um refresh desse cache. Mas e se a API não responder? :()

Para casos como esse (um pouco específicos, eu admito), usar cache stale pode ser um saída interessante.

Cache Stale

A proposta é super simples, você precisa entregar algo para o cliente, mesmo que seja um valor um pouco velho. E o quão velho é permitido que esse valor seja também será um escolha feita por você, ok?!

Dito isso, podemos então dividir o tempo de vida (TTL) do nosso dado em caching em duas partes: período fresco (fresh) e período obsoleto (stale).

Em palavras simples:

Por um período, o valor em cache é considerado útil para ser entregue ao cliente. No restante, ele é considerado velho, que precisa ser renovado, mas que pode ser entregue ao cliente se a renovação der errado.

Observe a representação gráfica abaixo:

Isso significa que nosso TTL final a ser informado no Redis será a soma dessas duas fatias de tempo. Mas o controle de quando fazer a renovação do cache ficará por parte da aplicação.

Aqui temos um exemplo de como implementar essa lógica usando golang:

func (repo *RedisRepository) Set(ctx context.Context, key string, value interface{}, config ...CacheConfig) error {
    ttl := repo.defaultRedisConfig.MaxStaleAge + repo.defaultRedisConfig.ValidAge
    if len(config) > 0 {
        ttl = config[0].MaxStaleAge + config[0].ValidAge
    }

    err := repo.client.Set(ctx, key, value, ttl).Err()
    if err != nil {
        return errors.New("error to set to Redis")
    }

    return nil
}

func (repo *RedisRepository) Get(ctx context.Context, key string, config ...CacheConfig) ([]byte, bool, error) {
    maxStaleAge := repo.defaultRedisConfig.MaxStaleAge
    if len(config) > 0 {
        maxStaleAge = config[0].MaxStaleAge
    }

    var remainingTTLCmd *redis.DurationCmd
    var valueCmd *redis.StringCmd
    stale := false

    _, err := repo.client.Pipelined(ctx, func(pipe redis.Pipeliner) error {
        valueCmd = pipe.Get(ctx, key)
        remainingTTLCmd = pipe.TTL(ctx, key)

        return nil
    })

    err = valueCmd.Err()
    if err != nil {
        if errors.Is(err, redis.Nil) {
            return nil, false, err
        }

        log.Println("error to get from Redis ", err.Error())
        return nil, false, errors.New("error to get from Redis")
    }

    err = remainingTTLCmd.Err()
    if err != nil {
        log.Println("error to get TTL to Redis ", err.Error())
        return nil, false, errors.New("error to get TTL to Redis")
    }

    stale = remainingTTLCmd.Val().Seconds() <= maxStaleAge.Seconds()

    return []byte(valueCmd.Val()), stale, err
}

Renovando o cache

A renovação do valor em cache pode acontecer de forma síncrona ou assíncrona. Abaixo temos uma representação gráfica de cada um.

Abordagem síncrona

A vantagem de usar a síncrona é que existe a possibilidade de entregar um dado mais fresco de imediato para o usuário.

Abordagem assíncrona

Já no assíncrono temos a vantagem de não deixar o usuário esperando por um dado mais fresco, podemos entregar o stale de imediato e renovar o cache em paralelo.

Para o nosso exemplo, vamos fazer a renovação síncrona. Mas desafie-se a também implementar a assíncrona :)

func (repo *RedisRepository) GetOrRefresh(ctx context.Context, key string, refreshFn func() (value []byte, err error), config ...CacheConfig) ([]byte, error) {
    val, stale, err := repo.Get(ctx, key, config...)
    if err == nil && !stale {
        return val, nil
    }

    if err != nil && !errors.Is(err, redis.Nil) {
        log.Println("error to get from Redis", err)
        return nil, errors.New("error to get to Redis")
    }

    freshValue, err := refreshFn()
    if err != nil {
        log.Println("error to refresh Cache", err)
        return nil, errors.New("error to refresh Cache")
    }

    go func() {
        err := repo.Set(ctx, key, freshValue, config...)
        if err != nil {
            log.Println("error to set to Redis", err)
        }
    }()

    return freshValue, nil
}

Conclusão

Desta forma, você garante uma boa resiliência na sua aplicação. Além de garantir que o cliente sempre receba os dados, mesmo que a fonte (API externa) venha a falhar.

Esta é um dica simples mas que pode ser muito útil quando lidamos com aplicações que precisam de alta resiliência. Se este post gerou mais dúvidas que respostas, melhor ainda. Sei que você não vai deixar essas dúvidas em aberto :)

O código desenvolvido neste artigo pode ser encontrado neste repo no Github. Se tiver alguma dúvida ou sugestão, aguardo você nos comentários :)

Tenho certeza que nos veremos novamente. Até a próxima. #keephacking

Crédito de cover image: Photo by Mohamed B. on Unsplash.

Interceptando mensagens de erro com o nginx

Renan de Andrade — Sun, 12 Nov 2023 03:44:20 +0000

Como Desenvolvedores de Software, o cuidado com o quesito segurança de nossas apps é constante e nunca é demais. Sempre que uma de nossas aplicações se tornam públicas, temos o máximo de cuidado para não expor informações privadas e que possam comprometer o funcionamento da mesma, ou até mesmo do negócio como um todo.

Um ponto crucial de atenção que todos devemos ter ao expor uma aplicação para o público é como ela se comporta quando ocorre algum erro e o que é reportado para o usuário nesses cenários. Resposta de erros mal tratadas podem não ser nada demais para a maioria dos usuários, mas tenha certeza que para alguém, vai ser um prato cheio.

Com o intuito de ajudar a mitigar esses problemas, este artigo aborda o uso da feature proxy_intercept_errors do nginx.

O que é o nginx

O nginx é um web server largamente utilizado que pode ter muitas utilidades, as mais comuns são Load Balancer e Reverse Proxy. Nesses casos, podemos fazer diversas tratativas nos detalhes das requisições antes e depois do processamento por parte de nossas apps.

A imagem abaixo é uma representação básica de como o nginx pode ser utilizado:

Substituindo mensagens de erro

Para vermos a interceptação de erros em ação, vamos criar um projetinho simples usando Go, nginx e docker-compose.

Você pode encontrar o repositório de exemplo aqui.

Aplicação

Nosso exemplo é uma aplicação simples em Go contendo um http server simples com as seguintes rotas e seus respectivos códigos de retorno:

/success, 200;
/bad_request, 400;
/not_found, 404;
/internal_server_error, 500.

package main

import (
    "net/http"

    "github.com/gofiber/fiber/v2"
)

func main() {
    app := fiber.New()

    app.Get("/success", func(c *fiber.Ctx) error {
        c.Set("Content-Type", "application/json")
        return c.SendString(`{"message": "success"}`)
    })

    app.Get("/bad_request", func(c *fiber.Ctx) error {
        c.Set("Content-Type", "application/json")
        return c.Status(http.StatusBadRequest).SendString(`{"error": "The new password cannot be the same as the previous one"}`)
    })

    app.Get("/not_found", func(c *fiber.Ctx) error {
        c.Set("Content-Type", "application/json")
        return c.Status(http.StatusNotFound).SendString(`{"error":"This resource is not found at database 'vuln'"`)
    })

    app.Get("/internal_server_error", func(c *fiber.Ctx) error {
        c.Set("Content-Type", "application/json")
        return c.Status(http.StatusInternalServerError).SendString(`{"error":"Error log with private information"`)
    })

    app.Listen(":8000")
}

A ideia é justamente podermos simular vários códigos de erro para testar nossa feat de interceptação de erros. Imagine que em um cenário real qualquer um desses retornos possa carregar uma informação que o cliente não possa ter acesso.

Configuração do nginx

De maneira bem simples, nosso arquivo de configuração do nginx ficou mais ou menos assim:

events{}
http {

    server {
        listen 80;

        error_page 404 500 /custom_err.html;
        error_page 400 @error400;

        location / {
            # proxy_intercept_errors on;
            proxy_pass http://app:8000;
        }

        location = /custom_err.html {
            root /usr/share/nginx/html;
            internal;
        }

        location @error400 {
            default_type application/json;
            internal;
            return 400 '{"error": {"status_code": 400,"status": "Bad Request"}}';
        }
    }
}

Sim, a linha comentada é intencional.

Testando a aplicação

Antes de entendermos melhor essa como tudo funciona, vamos ver nosso exemplo em ação. Execute o seguinte comando para iniciar nossa aplicação:

$ make run

Assim que estiver tudo rodando, vamos testar um dos endpoints de erro:

$ curl -i localhost/not_found

O resultado deve ser esse:

HTTP/1.1 404 Not Found
Server: nginx/1.25.3
Date: Sun, 12 Nov 2023 02:42:58 GMT
Content-Type: application/json
Content-Length: 56
Connection: keep-alive

{"error":"This resource is not found at database 'vuln'"

E voila! Tivemos uma resposta com informações comprometedoras.

Interceptando erros

Removendo o comentário, nosso location /fica assim:

       #...
        location / {
            proxy_intercept_errors on;
            proxy_pass http://app:8000;
        }
      #...

Chamando o mesmo endpoint que antes, temos esse novo retorno:

HTTP/1.1 404 Not Found
Server: nginx/1.25.3
Date: Sun, 12 Nov 2023 02:43:50 GMT
Content-Type: text/html
Content-Length: 250
Connection: keep-alive
ETag: "654cd606-fa"

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Error page</title>
</head>
<body>
    <h1>Ops... This is a custom error page</h1>
</body>
</html>

Isso significa que o Nginx interceptou nosso retorno de erro e substituiu pelo retorno de nossa página de erro customizada. E segundo a documentação, esse recurso é desabilitado por padrão.

É possível também retornar alguns outros formatos de resposta, como quando executamos o comando:

$ curl -i localhost/bad_request

Que retorna a seguinte resposta:

HTTP/1.1 400 Bad Request
Server: nginx/1.25.3
Date: Sun, 12 Nov 2023 02:57:55 GMT
Content-Type: application/json
Content-Length: 55
Connection: close

{"error": {"status_code": 400,"status": "Bad Request"}}

Como já deu para perceber, a resposta a ser retornada é definida pela config error_page.

Conclusão

Por mais que seja uma configuração simples, a interceptação de erros por parte do nginx pode ajudar a mitigar vários problemas. Esse post demonstrou uma das muitas maneiras de utilizar esse recurso.

Não esqueça de testar você mesmo o nosso exemplo aqui apresentado e explorar as mais diversas formas de usar essa e outras features do nginx.

And keep learning!

Créditos de imagem:

Cover image: Photo by David Pupăză on Unsplash