Invoer (.proto-schema)

Uitvoer (Go)

Wat deze tool doet

Go is de protobuf-native taal — de meeste gRPC-services in productie zijn er in geschreven. Normaal genereer je Go uit .proto met protoc-gen-go of buf, wat betekent dat je de toolchain installeert, een generator configureert en een buildstap draait. Deze converter doet hetzelfde in je browser — plakken, kopiëren, in je repo zetten.

De type-mapping volgt wat protoc-gen-go uitspuwt: string → string, bool → bool, bytes → []byte, de integer-types mappen op hun int32/int64/uint32/uint64-tegenhangers (geen precisieverlies zoals in JavaScript), double → float64, float → float32. Enkelvoudige message-velden zijn pointers (volgens de conventie van de officiële Go-protobuf-bindings), repeated T wordt []T, map<K, V> wordt map[K]V.

Veldnamen krijgen de Go-canonieke PascalCase-behandeling, met veelvoorkomende acroniemen in hoofdletters (order_id → OrderID, api_url → APIURL) volgens de Go review style. Elk veld krijgt klaar-om-te-plakken struct-tags: protobuf:"varint,3,opt,name=status,proto3" voor het wire-format en json:"status,omitempty" voor JSON-marshalling. De conversie is lokaal — je .proto verlaat de browser nooit. Voor productiecode wil je nog steeds echte codegen draaien om methodes, descriptors en reflection-bedrading te krijgen — maar voor schetsen, reviews en eenmalige scripts is dit sneller.

Hoe je het gebruikt

Drie stappen. De uitvoer is plakklare Go die zo compileert met de standaardbibliotheek.

Plak je .proto-schema

Zet het schema in de linker editor. syntax = "proto3"; bovenaan is prima maar optioneel. De parser handelt geneste message-blokken, enum-declaraties, oneof, map<K, V> en veldopties af. Imports worden herkend maar overgeslagen.

Veldnamen worden automatisch geconverteerd van snake_case naar PascalCase. De converter zet veelvoorkomende acroniem-suffixen in hoofdletters (Id → ID, Url → URL) zodat de uitvoer revive / golint zonder gemopper passeert.

Lees de uitvoer

Rechts: Go met één type X struct per message en een type X int32 + const-blok per enum. package proto bovenaan is een placeholder — verander het naar je echte pakketnaam.

Bouw het in je project

Zet het bestand in je project, fix de package-declaratie en importeer het. Voor echte gRPC-code wil je alsnog protoc-gen-go draaien om de marshal/unmarshal-methodes te krijgen. Deze uitvoer is bedoeld voor getypte JSON-afhandeling, struct-schetsen en reviews — de protobuf wire-format-methodes worden hier niet gegenereerd.

Wanneer dit echt tijd scheelt

Een Go-service schetsen op basis van een bestaand .proto

Je zet een Go-service op die Protobuf-messages van een ander team consumeert. Je wilt de struct-vormen voor handler-signatures en JSON-responses zonder de hele codegen-pipeline op te tuigen. Plakken, in types.go zetten, je hebt types.

Een Protobuf-API-wijziging reviewen voor een Go-consumer

Een backend-collega heeft velden toegevoegd aan een message. Plak de nieuwe .proto, diff de Go-uitvoer tegen je huidige types.go, laat een gerichte review achter. Sneller dan de toolchain opspinnen alleen om de wijziging te bekijken.

Sanity check tussen talen

Je hebt een .proto dat door zowel Go- als TypeScript-clients wordt geconsumeerd. Gebruik dit naast de Protobuf naar TypeScript-converter om te bevestigen dat beide talen na JSON-encoding compatibele veldnamen en types zien.

Eenmalige integratiescripts

Je schrijft een Go-script van 50 regels dat een gRPC-gateway-endpoint aanroept. protoc, buf en een generator-config opzetten voor één script is overkill. Genereer de structs hier, plak ze erin, ship het script.

Veelgestelde vragen

Vervangt dit protoc-gen-go?

Nee. protoc-gen-go spuugt de binaire marshal/unmarshal-methodes, file-descriptors en de reflection-bedrading uit die nodig zijn voor echte gRPC. Deze converter spuugt alleen de struct-vormen en tags uit. Als je een echte gRPC-service schrijft, draai dan de officiële codegen. Als je alleen types nodig hebt voor JSON-responses, handgemaakte scripts of schetsen — dit is sneller.

Waarom zijn message-velden pointers?

Het spiegelt wat protoc-gen-go doet voor proto3 message-velden — ze zijn pointers zodat de zero value nil is (te onderscheiden van een aanwezige maar lege message). Scalaire velden blijven waarden omdat hun zero values op zichzelf geldig zijn (lege string, 0, false). Als je om een of andere reden geen pointer wilt, doe een find-replace op de sterretjes in de uitvoer.

Hoe worden enums uitgespuugd?

Als Go-int32-typedefs met een const-blok, conform de protoc-gen-go-conventies. Elke enum-waarde wordt een PascalCase Go-constante van dat type. De numerieke toewijzingen komen rechtstreeks uit het .proto.

Hoe zit het met de protobuf-struct-tags?

Elk veld krijgt een protobuf:"..."-tag met het wire-type (varint, fixed32, fixed64, bytes), veldnummer, label (opt/rep), naam en proto3-marker. Plus een json:"name,omitempty"-tag met de oorspronkelijke snake_case-naam. map<K, V>-tags zijn vereenvoudigd — voor strikte wire-format-compatibiliteit moet je echte codegen draaien.

Hoe worden veldnamen geconverteerd?

snake_case → PascalCase, met veelvoorkomende acroniem-suffixen in hoofdletters: order_id → OrderID, api_url → APIURL, data_json → DataJSON. Dit komt overeen met de Go review-style-conventies, dus de uitvoer passeert lint zonder handmatige opschoning.

Wat als mijn schema een ander .proto importeert?

import-statements worden herkend en overgeslagen — message-types over bestanden heen worden gerenderd met hun bladnaam (foo.Bar → Bar), die Go niet zal resolven tenzij dat type ook in hetzelfde pakket bestaat. Ofwel plak je de geïmporteerde messages inline, ofwel reken je erop dat je de verwijzingen in de uitvoer nog moet fixen.

Gerelateerde tools

Als je met Protobuf, JSON en Go werkt, passen deze goed bij elkaar:

Protobuf naar Go-converter