// the find
ogen-go/ogen
OpenAPI v3 code generator for go
ogen generates a complete, statically-typed Go client and server from an OpenAPI v3 spec — not just types, but JSON codecs, a radix router, parameter parsers, and OpenTelemetry instrumentation. It targets teams who want to own their spec as the source of truth and get zero-reflection, allocation-conscious HTTP handling out of it. If you're hand-writing net/http handlers against an existing spec, this is the tool that removes that work.
The optional/nullable wrapper types (OptNilString, NilString, OptNilString) genuinely solve a real Go pain point — the three-state problem of 'absent vs null vs value' without pointer soup. Most generators just reach for *string and call it done. The oneOf discriminator inference is unusually smart: it tries field name, field type, and enum value discrimination automatically before falling back to explicit discriminator mapping, which means it handles the majority of real-world specs without hand-holding. JSON encoding is entirely code-generated using jx rather than encoding/json, so you get byte-level control and no reflection overhead at runtime — the generated Decode methods are explicit switch statements over field names, not map lookups. The test corpus is serious: GitHub API, Kubernetes, Telegram Bot API, Firecracker — these are large, messy, real specs, and they all generate.
SSE server generation is explicitly missing — only client-side SSE is supported, which is a gap if you're building a streaming API and want the same schema-driven approach on both sides. The custom x-ogen-validate validators require manual registration at startup before validation runs; easy to forget, and there's no compile-time enforcement that your registered validators match what's in the spec. Real vendor specs from AWS, Stripe, or Twilio often have subtle spec violations that strict generators choke on — ogen's strictness is a feature for greenfield work but a friction point when you're consuming an external API you don't control. anyOf gets much less attention than oneOf in the documentation and test coverage, and in practice anyOf semantics in OpenAPI are ambiguous enough that the generated Go types for complex anyOf schemas can be awkward to work with.