Input (schema .proto)

Output (Go)

Cosa fa questo strumento

Go è il linguaggio nativo di protobuf — la maggior parte dei servizi gRPC in produzione è scritta in Go. Normalmente generi Go da .proto usando protoc-gen-go o buf, il che vuol dire installare la toolchain, configurare un generatore e lanciare uno step di build. Questo convertitore fa lo stesso lavoro nel tuo browser — incolla, copia, butta nel repo.

Il mapping dei tipi segue ciò che protoc-gen-go emette: string → string, bool → bool, bytes → []byte, i tipi interi mappano sui rispettivi int32/int64/uint32/uint64 (senza la perdita di precisione di JavaScript), double → float64, float → float32. I campi messaggio singolari sono puntatori (in linea con la convenzione dei binding Go ufficiali di protobuf), repeated T diventa []T, map<K, V> diventa map[K]V.

I nomi dei campi ricevono il trattamento canonico Go in PascalCase, con gli acronimi comuni messi in maiuscolo (order_id → OrderID, api_url → APIURL) secondo lo stile di review Go. Ogni campo riceve struct tag pronti all'uso: protobuf:"varint,3,opt,name=status,proto3" per il wire format e json:"status,omitempty" per il marshalling JSON. La conversione è locale — il tuo .proto non lascia mai il browser. Per il codice di produzione vorrai comunque lanciare il codegen vero per ottenere metodi, descriptor e impalcatura di reflection — ma per bozze, review e script una tantum questo è più rapido.

Come usarlo

Tre passi. L'output è Go pronto da incollare che compila così com'è con la libreria standard.

Incolla il tuo schema .proto

Butta lo schema nell'editor di sinistra. syntax = "proto3"; in cima va bene ma è opzionale. Il parser gestisce blocchi message annidati, dichiarazioni enum, oneof, map<K, V> e opzioni di campo. Gli import vengono riconosciuti ma saltati.

I nomi dei campi si convertono automaticamente da snake_case a PascalCase. Il convertitore mette in maiuscolo i suffissi acronimi comuni (Id → ID, Url → URL) così l'output passa revive / golint senza lamentele.

Leggi l'output

A destra: Go con un type X struct per messaggio e un blocco type X int32 + const per ogni enum. package proto in cima è un placeholder — cambialo con il nome vero del tuo package.

Inseriscilo nel tuo progetto

Butta il file nel progetto, sistema la dichiarazione package e importa. Per codice gRPC vero ti servirà comunque lanciare protoc-gen-go per ottenere i metodi marshal/unmarshal. Questo output è pensato per gestione JSON tipizzata, bozze di struct e review — i metodi del wire format protobuf qui non vengono generati.

Quando fa davvero risparmiare tempo

Abbozzare un servizio Go a partire da un .proto esistente

Stai mettendo in piedi un servizio Go che consuma messaggi Protobuf di un altro team. Ti servono le forme dei struct per le firme degli handler e le risposte JSON, senza tirare su tutta la pipeline di codegen. Incolla, butta in types.go, sei tipato.

Revisionare una modifica all'API Protobuf per un consumer Go

Un collega del backend ha aggiunto campi a un messaggio. Incolla il nuovo .proto, fai il diff dell'output Go contro il tuo types.go attuale, lascia una review mirata. Più rapido che far partire la toolchain solo per guardare la modifica.

Verifica cross-linguaggio

Hai un .proto consumato sia da client Go che TypeScript. Usalo affiancato al convertitore Protobuf in TypeScript per confermare che entrambi i linguaggi vedranno nomi e tipi di campo compatibili dopo l'encoding JSON.

Script di integrazione una tantum

Stai scrivendo uno script Go di 50 righe che colpisce un endpoint gRPC-gateway. Mettere in piedi protoc, buf e una config del generatore per uno script è eccessivo. Genera i struct qui, mettili dentro, spedisci lo script.

Domande frequenti

Sostituisce protoc-gen-go?

No. protoc-gen-go emette i metodi binari di marshal/unmarshal, i descriptor di file e l'impalcatura di reflection necessaria per gRPC vero. Questo convertitore emette solo le forme dei struct e i tag. Se stai scrivendo un servizio gRPC reale, lancia il codegen ufficiale. Se ti servono solo i tipi per risposte JSON, script fatti a mano o bozze — questo è più rapido.

Perché i campi tipo messaggio sono puntatori?

Rispecchia ciò che fa protoc-gen-go con i campi messaggio in proto3 — sono puntatori così che lo zero value sia nil (distinguibile da un messaggio presente ma vuoto). I campi scalari restano valori perché i loro zero value sono di per sé validi (stringa vuota, 0, false). Se per qualche motivo preferisci non-puntatori, fai find-replace degli asterischi nell'output.

Come vengono emessi gli enum?

Come typedef Go int32 con un blocco const, in linea con le convenzioni di protoc-gen-go. Ogni valore di enum diventa una costante Go in PascalCase di quel tipo. Le assegnazioni numeriche arrivano dritte dal .proto.

E i struct tag protobuf?

Ogni campo riceve un tag protobuf:"..." con il wire type (varint, fixed32, fixed64, bytes), il numero di campo, la label (opt/rep), il nome e il marker proto3. Più un tag json:"name,omitempty" che usa il nome originale in snake_case. I tag map<K, V> sono semplificati — per stretta compatibilità wire-format, lancia il codegen vero.

Come vengono convertiti i nomi dei campi?

snake_case → PascalCase, con i suffissi acronimi comuni in maiuscolo: order_id → OrderID, api_url → APIURL, data_json → DataJSON. Si allinea alle convenzioni di review Go quindi l'output passa il lint senza pulizie manuali.

E se il mio schema importa un altro .proto?

Le istruzioni import vengono riconosciute e saltate — i tipi messaggio cross-file vengono renderizzati con il nome foglia (foo.Bar → Bar) che Go non risolverà a meno che quel tipo non esista anche nello stesso package. O incolli i messaggi importati inline, oppure mettiti in conto di sistemare i riferimenti nell'output.

Strumenti correlati

Se lavori con Protobuf, JSON e Go, questi si combinano bene:

Convertitore da Protobuf a Go