Entrada (esquema .proto)

Saída (Go)

O que essa ferramenta faz

Go é a linguagem nativa do protobuf — a maior parte dos serviços gRPC em produção é escrita nela. Normalmente você gera Go a partir de .proto usando protoc-gen-go ou buf, o que significa instalar a toolchain, configurar um gerador e rodar uma etapa de build. Esse conversor faz o mesmo trabalho no seu navegador — cola, copia, joga no seu repositório.

O mapeamento de tipos segue o que protoc-gen-go emite: string → string, bool → bool, bytes → []byte, os tipos inteiros mapeiam para seus equivalentes int32/int64/uint32/uint64 (sem perda de precisão como no JavaScript), double → float64, float → float32. Campos de mensagem singulares são ponteiros (seguindo a convenção dos bindings oficiais do Go para protobuf), repeated T vira []T, map<K, V> vira map[K]V.

Os nomes de campo recebem o tratamento canônico do Go em PascalCase, com acrônimos comuns em maiúsculas (order_id → OrderID, api_url → APIURL) conforme o estilo de revisão do Go. Cada campo recebe struct tags prontas pra colar: protobuf:"varint,3,opt,name=status,proto3" para o formato wire e json:"status,omitempty" para marshalling JSON. A conversão é local — seu .proto nunca sai do navegador. Para código de produção você ainda vai querer rodar codegen real para ter métodos, descriptors e a parte de reflection — mas para esboços, revisões e scripts pontuais, isso aqui é mais rápido.

Como usar

Três passos. A saída é Go pronto pra colar que compila do jeito que está com a biblioteca padrão.

Cole seu esquema .proto

Jogue o esquema no editor da esquerda. syntax = "proto3"; no topo é OK mas opcional. O parser lida com blocos message aninhados, declarações enum, oneof, map<K, V> e opções de campo. Imports são reconhecidos mas ignorados.

Os nomes de campo se convertem automaticamente de snake_case para PascalCase. O conversor coloca em maiúsculas os sufixos de acrônimos comuns (Id → ID, Url → URL) para que a saída passe no revive / golint sem reclamação.

Leia a saída

À direita: Go com um type X struct por mensagem e bloco type X int32 + const por enum. package proto no topo é placeholder — troque pelo nome real do seu pacote.

Encaixe no seu projeto

Solte o arquivo no projeto, ajuste a declaração package e importe. Para código gRPC de verdade você ainda vai querer rodar protoc-gen-go pra ter os métodos marshal/unmarshal. Essa saída é pra tratar JSON tipado, esboçar structs e fazer revisão — os métodos de wire format do protobuf não são gerados aqui.

Quando isso realmente economiza tempo

Esboçar um serviço Go a partir de um .proto existente

Você está montando um serviço Go que consome mensagens Protobuf de outro time. Quer as formas dos structs pra assinaturas de handlers e respostas JSON sem subir o pipeline de codegen completo. Cola, joga em types.go, está tipado.

Revisar uma mudança de API Protobuf para um consumidor Go

Um colega do backend adicionou campos a uma mensagem. Cola o novo .proto, faz diff da saída Go contra o seu types.go atual, deixa uma revisão objetiva. Mais rápido do que subir a toolchain só pra olhar a mudança.

Sanity check entre linguagens

Você tem um .proto consumido tanto por clientes Go quanto TypeScript. Use isso lado a lado com o conversor Protobuf para TypeScript para confirmar que as duas linguagens vão ver nomes e tipos de campo compatíveis após a codificação JSON.

Scripts de integração pontuais

Você está escrevendo um script Go de 50 linhas que bate num endpoint gRPC-gateway. Configurar protoc, buf e config de gerador pra um script só é exagero. Gera os structs aqui, joga, manda o script.

Perguntas frequentes

Isso substitui o protoc-gen-go?

Não. O protoc-gen-go emite os métodos binários de marshal/unmarshal, descriptors de arquivo e a parte de reflection necessária pra gRPC de verdade. Esse conversor só emite as formas dos structs e as tags. Se você está escrevendo um serviço gRPC real, rode o codegen oficial. Se só precisa dos tipos pra respostas JSON, scripts feitos à mão ou esboços — isso aqui é mais rápido.

Por que campos com tipo de mensagem são ponteiros?

Espelha o que o protoc-gen-go faz com campos de mensagem em proto3 — eles são ponteiros pra que o zero value seja nil (distinguível de uma mensagem presente mas vazia). Campos escalares ficam como valores porque seus zero values são, eles próprios, válidos (string vazia, 0, false). Se por algum motivo você prefere não-ponteiro, faça find-replace nos asteriscos da saída.

Como os enums são emitidos?

Como typedefs Go int32 com um bloco const, igual à convenção do protoc-gen-go. Cada valor de enum vira uma constante Go em PascalCase desse tipo. As atribuições numéricas vêm direto do .proto.

E as struct tags do protobuf?

Cada campo recebe uma tag protobuf:"..." com o wire type (varint, fixed32, fixed64, bytes), número do campo, label (opt/rep), nome e marcador proto3. Mais uma tag json:"name,omitempty" usando o nome original em snake_case. As tags de map<K, V> são simplificadas — para compatibilidade estrita com o wire format, rode codegen real.

Como os nomes de campo são convertidos?

snake_case → PascalCase, com sufixos de acrônimos comuns em maiúsculas: order_id → OrderID, api_url → APIURL, data_json → DataJSON. Bate com as convenções de revisão do Go pra que a saída passe no lint sem limpeza manual.

E se meu esquema importa outro .proto?

Declarações import são reconhecidas e ignoradas — tipos de mensagem entre arquivos são renderizados pelo nome final (foo.Bar → Bar) que o Go não vai resolver a menos que aquele tipo também exista no mesmo pacote. Ou você cola as mensagens importadas inline, ou já espera ter que arrumar as referências na saída.

Ferramentas relacionadas

Se você trabalha com Protobuf, JSON e Go, essas combinam bem:

Conversor Protobuf para Go