Inndata (.proto-skjema)

Utdata (Go)

Hva dette verktøyet gjør

Go er protobufs hjemmespråk — de fleste gRPC-tjenester i produksjon er skrevet i det. Vanligvis genererer du Go fra .proto med protoc-gen-go eller buf, noe som betyr å installere toolchainen, konfigurere en generator og kjøre et byggesteg. Denne konverteren gjør samme jobb i nettleseren din — lim inn, kopier, slipp i repoet.

Typetilordningen følger det protoc-gen-go spytter ut: string → string, bool → bool, bytes → []byte, heltallstypene mappes til sine int32/int64/uint32/uint64-motstykker (ingen presisjonstap som i JavaScript), double → float64, float → float32. Singulære message-felt er pointers (i tråd med konvensjonen til de offisielle Go-protobuf-bindingene), repeated T blir []T, map<K, V> blir map[K]V.

Feltnavn får den Go-kanoniske PascalCase-behandlingen, med vanlige akronymer i store bokstaver (order_id → OrderID, api_url → APIURL) ifølge Go review style. Hvert felt får klar-til-bruk struct-tagger: protobuf:"varint,3,opt,name=status,proto3" for wire-formatet og json:"status,omitempty" for JSON-marshalling. Konverteringen er lokal — .proto-filen din forlater aldri nettleseren. For produksjonskode bør du fortsatt kjøre ekte codegen for å få metoder, descriptors og reflection-rørlegging — men for skisser, gjennomganger og engangsskript er dette raskere.

Slik bruker du det

Tre steg. Utdata er lim-inn-klar Go som kompilerer som den er med standardbiblioteket.

Lim inn .proto-skjemaet ditt

Slipp skjemaet i den venstre editoren. syntax = "proto3"; på toppen er greit men valgfritt. Parseren håndterer nestede message-blokker, enum-deklarasjoner, oneof, map<K, V> og feltvalg. Imports gjenkjennes men hoppes over.

Feltnavn konverteres automatisk fra snake_case til PascalCase. Konverteren store-bokstaver vanlige akronym-endelser (Id → ID, Url → URL) slik at utdata passerer revive / golint uten klaging.

Les utdata

Til høyre: Go med én type X struct per message og en type X int32 + const-blokk per enum. package proto på toppen er en plassholder — endre den til ditt faktiske pakkenavn.

Koble det til prosjektet

Slipp filen i prosjektet, fiks package-deklarasjonen og importer. For ekte gRPC-kode vil du fortsatt ønske å kjøre protoc-gen-go for å få marshal/unmarshal-metodene. Denne utdataen er ment for typet JSON-håndtering, struct-skisser og gjennomganger — protobufs wire-format-metoder genereres ikke her.

Når det faktisk sparer tid

Skissere en Go-tjeneste ut fra en eksisterende .proto

Du setter opp en Go-tjeneste som konsumerer Protobuf-meldinger fra et annet team. Du vil ha struct-formene til handler-signaturer og JSON-svar uten å sette opp hele codegen-pipelinen. Lim inn, slipp i types.go, du er typet.

Gjennomgå en Protobuf-API-endring for en Go-forbruker

En backend-kollega la til felter i en melding. Lim inn den nye .proto, diff Go-utdata mot ditt nåværende types.go, legg igjen en fokusert gjennomgang. Raskere enn å fyre opp toolchainen bare for å se på endringen.

Sanity check på tvers av språk

Du har en .proto som konsumeres både av Go- og TypeScript-klienter. Bruk dette side om side med Protobuf til TypeScript-konverteren for å bekrefte at begge språkene vil se kompatible feltnavn og typer etter JSON-koding.

Engangs-integrasjonsskript

Du skriver et 50-linjers Go-skript som treffer en gRPC-gateway-endepunkt. Å sette opp protoc, buf og en generator-konfig for ett skript er overkill. Generer structs her, slipp dem inn, send skriptet.

Vanlige spørsmål

Er dette en erstatning for protoc-gen-go?

Nei. protoc-gen-go spytter ut de binære marshal/unmarshal-metodene, fil-descriptorene og reflection-rørleggingen som trengs for ekte gRPC. Denne konverteren spytter kun ut struct-formene og taggene. Skriver du en ekte gRPC-tjeneste, kjør den offisielle codegen. Hvis du bare trenger typer for JSON-svar, håndlagde skript eller skisser — dette er raskere.

Hvorfor er message-typede felt pointers?

Det speiler det protoc-gen-go gjør for proto3 message-felt — de er pointers så zero value er nil (skiljbart fra en tilstedeværende men tom melding). Skalære felt forblir verdier fordi zero value-ene deres i seg selv er gyldige (tom streng, 0, false). Hvis du av en eller annen grunn foretrekker ikke-pointer, gjør find-replace på stjernene i utdata.

Hvordan genereres enums?

Som Go-int32-typedefs med en const-blokk, i tråd med protoc-gen-go-konvensjonene. Hver enum-verdi blir til en PascalCase Go-konstant av den typen. De numeriske tilordningene kommer rett fra .proto.

Hva med protobufs struct-tagger?

Hvert felt får en protobuf:"..."-tag med wire-typen (varint, fixed32, fixed64, bytes), feltnummer, label (opt/rep), navn og proto3-markør. Pluss en json:"name,omitempty"-tag som bruker det opprinnelige snake_case-navnet. map<K, V>-tagger er forenklet — for streng wire-format-kompatibilitet, kjør ekte codegen.

Hvordan konverteres feltnavn?

snake_case → PascalCase, med vanlige akronym-endelser i store bokstaver: order_id → OrderID, api_url → APIURL, data_json → DataJSON. Det matcher Go review-stilens konvensjoner, så utdata passerer lint uten manuell opprydding.

Hva hvis skjemaet mitt importerer en annen .proto?

import-setninger gjenkjennes og hoppes over — message-typer på tvers av filer rendres med bladnavnet sitt (foo.Bar → Bar), som Go ikke vil resolve med mindre den typen også finnes i samme pakke. Enten limer du de importerte meldingene inn inline, eller du regner med å fikse referansene i utdata.

Relaterte verktøy

Hvis du jobber med Protobuf, JSON og Go, fungerer disse godt sammen:

Protobuf til Go-konverter