Entrada (esquema .proto)

Salida (Go)

Qué hace esta herramienta

Go es el lenguaje nativo de protobuf — la mayoría de los servicios gRPC en producción están escritos en él. Lo normal es generar Go desde .proto usando protoc-gen-go o buf, lo que implica instalar la toolchain, configurar un generador y ejecutar un paso de build. Este conversor hace lo mismo en tu navegador — pegas, copias, lo metes en tu repo.

El mapeo de tipos sigue lo que emite protoc-gen-go: string → string, bool → bool, bytes → []byte, los tipos enteros se mapean a sus equivalentes int32/int64/uint32/uint64 (sin pérdida de precisión como en JavaScript), double → float64, float → float32. Los campos de mensaje singulares son punteros (siguiendo la convención de los bindings oficiales de Go para protobuf), repeated T se vuelve []T, map<K, V> se vuelve map[K]V.

Los nombres de campo reciben el tratamiento canónico de Go en PascalCase, con los acrónimos comunes en mayúsculas (order_id → OrderID, api_url → APIURL) según el estilo de revisión de Go. Cada campo recibe struct tags listos para pegar: protobuf:"varint,3,opt,name=status,proto3" para el formato wire y json:"status,omitempty" para el marshalling JSON. La conversión es local — tu .proto nunca sale del navegador. Para código de producción deberías ejecutar codegen real para obtener métodos, descriptores y la fontanería de reflection — pero para esbozos, revisiones y scripts puntuales esto es más rápido.

Cómo usarla

Tres pasos. La salida es Go listo para pegar que compila tal cual con la biblioteca estándar.

Pega tu esquema .proto

Suelta el esquema en el editor de la izquierda. syntax = "proto3"; al principio está bien pero es opcional. El parser maneja bloques anidados de message, declaraciones enum, oneof, map<K, V> y opciones de campo. Los imports se reconocen pero se omiten.

Los nombres de campo se convierten automáticamente de snake_case a PascalCase. El conversor pone en mayúsculas los sufijos de acrónimos comunes (Id → ID, Url → URL) para que la salida pase revive / golint sin quejas.

Lee la salida

A la derecha: Go con un type X struct por mensaje y un bloque type X int32 + const por enum. package proto al inicio es un placeholder — cámbialo por el nombre real de tu paquete.

Engánchalo a tu proyecto

Suelta el archivo en tu proyecto, ajusta la declaración package e importa. Para código gRPC real seguirás necesitando ejecutar protoc-gen-go para obtener los métodos marshal/unmarshal. Esta salida está pensada para manejo tipado de JSON, esbozos de structs y revisiones — los métodos del formato wire de protobuf no se generan aquí.

Cuándo realmente ahorra tiempo

Esbozar un servicio Go a partir de un .proto existente

Estás levantando un servicio Go que consume mensajes Protobuf de otro equipo. Quieres las formas de los structs para firmas de handlers y respuestas JSON sin montar todo el pipeline de codegen. Pega, suelta en types.go y ya tienes tipos.

Revisar un cambio de API Protobuf para un consumidor Go

Un compañero del backend añadió campos a un mensaje. Pega el nuevo .proto, haz diff de la salida Go contra tu types.go actual, deja una revisión enfocada. Más rápido que arrancar la toolchain solo para mirar el cambio.

Sanity check entre lenguajes

Tienes un .proto consumido tanto por clientes Go como TypeScript. Úsalo lado a lado con el conversor Protobuf a TypeScript para confirmar que ambos lenguajes verán nombres y tipos de campo compatibles tras la codificación JSON.

Scripts de integración puntuales

Estás escribiendo un script Go de 50 líneas que pega contra un endpoint gRPC-gateway. Montar protoc, buf y la config de un generador para un script es excesivo. Genera los structs aquí, mételos y manda el script.

Preguntas frecuentes

¿Es esto un reemplazo para protoc-gen-go?

No. protoc-gen-go emite los métodos binarios de marshal/unmarshal, los descriptores de archivo y la fontanería de reflection necesaria para gRPC real. Este conversor solo emite las formas de los structs y los tags. Si estás escribiendo un servicio gRPC real, ejecuta el codegen oficial. Si solo necesitas tipos para respuestas JSON, scripts hechos a mano o esbozos — esto es más rápido.

¿Por qué los campos tipados como mensaje son punteros?

Refleja lo que hace protoc-gen-go con los campos de mensaje en proto3 — son punteros para que el zero value sea nil (distinguible de un mensaje presente pero vacío). Los campos escalares se quedan como valores porque sus zero values son válidos por sí mismos (cadena vacía, 0, false). Si por alguna razón prefieres no-puntero, busca y reemplaza los asteriscos en la salida.

¿Cómo se emiten los enums?

Como typedefs Go int32 con un bloque const, siguiendo las convenciones de protoc-gen-go. Cada valor de enum se vuelve una constante Go en PascalCase de ese tipo. Las asignaciones numéricas vienen directas del .proto.

¿Qué pasa con los struct tags de protobuf?

Cada campo recibe un tag protobuf:"..." con el wire type (varint, fixed32, fixed64, bytes), número de campo, label (opt/rep), nombre y marcador proto3. Más un tag json:"name,omitempty" usando el nombre original en snake_case. Los tags de map<K, V> están simplificados — para compatibilidad estricta con el formato wire, ejecuta codegen real.

¿Cómo se convierten los nombres de campo?

snake_case → PascalCase, con sufijos de acrónimos comunes en mayúsculas: order_id → OrderID, api_url → APIURL, data_json → DataJSON. Esto coincide con las convenciones del estilo de revisión de Go para que la salida pase el lint sin limpieza manual.

¿Qué pasa si mi esquema importa otro .proto?

Las sentencias import se reconocen y se omiten — los tipos de mensaje entre archivos se renderizan con su nombre hoja (foo.Bar → Bar) que Go no resolverá a menos que ese tipo también exista en el mismo paquete. O pegas los mensajes importados inline, o cuentas con que tendrás que arreglar las referencias en la salida.

Herramientas relacionadas

Si trabajas con Protobuf, JSON y Go, estas se complementan bien:

Conversor Protobuf a Go