December 18, 2025
Spec Wars: Speed vs 'Who uses specs?'
Building a High-Performance OpenAPI Parser in Go
Speakeasy builds a fast API reader; fans cheer, skeptics shrug
TLDR: Speakeasy launched a new Go library to read and validate API blueprints faster and more accurately. Comments erupted into Postman vs OpenAPI and “do we need this?” debates, with some crying lock-in and others saying correctness at scale matters for ugly, real-world APIs.
Speakeasy just dropped a go-fast library for reading API blueprints (called OpenAPI) at scale, promising both accuracy and speed. They say existing tools either miss pieces or turn everything into messy maps, so they built a reflection-powered parser that models the spec closely and handles wild, circular references. The pitch: make it the default for Go devs working with OpenAPI, Swagger, and friends, all in one repo.
The comments turned it into an industry cage match. Team Postman argued real companies ship Postman files, not OpenAPI—hello Salesforce, Notion—and blasted the “login wall.” One spicy prediction: Postman will lock API lookup behind a paid MCP. Team Skeptic rolled eyes: “processing thousands” doesn’t scream “build your own supercharger.” The memes wrote themselves: “Reinventing the wheel speedrun,” “Circular refs are the circles of dev hell,” and “Just eat your spec broccoli.” Team Builder clapped back: correctness matters when specs get huge and weird, and central performance wins ripple everywhere. Result: speed vs reality, standards vs convenience, and one very loud parsing party.
Translation: OpenAPI is the instruction manual for an API, while Postman files are the pre-packed samples. Speakeasy bets on manuals; the crowd debates if samples have already won the kitchen—today. Seriously.
Key Points
- •Speakeasy released a Go library (speakeasy-api/openapi) to parse, validate, and transform OpenAPI-related specs with high performance and precision.
- •The library addresses shortcomings in existing Go OpenAPI libraries by closely modeling the spec while maintaining type safety.
- •A custom reflection-based marshaller separates model definitions from deserialization to support multiple specs and versions efficiently.
- •An intermediate Node representation preserves dynamic field shapes and location information for better validation and error reporting.
- •The library supports OpenAPI (2.0–3.2), Swagger 2.0, Arazzo, and Overlay Specification documents, with centralized performance optimizations.