Building a High-Performance OpenAPI Parser in Go

> we process thousands of OpenAPI specifications every day

Doesn't really strike me as the load that requires writing a high-performance solution from scratch, especially on modern hardware.

> For example, in OpenAPI 3.1, the type field of a schema can be a single string (e.g., "string") or an array of strings (e.g., ["string", "null"]).

> In a statically typed language like Go, this is usually handled by using interface{} (which loses type safety) or complex pointer logic.

Having worked on JSON Schema parsing in go very recently, I disagree with this assessment. You create a `Type` in one of a few (2?) ways, depending on your specific needs. The simple method being that it's a `[]string` under the hood with a custom UnmarshalJSON receiver function. If reproducing the exact input structure is important you can cover that by making `Type` into a struct with a `[]string` and a `bool` to track if it was originally a single or an array. Then you have custom MarshalJSON and UnmarshalJSON receiver functions. That is, in fact, how I've seen multiple existing go JSON Schema libraries handle that variable type. No use of `any` or complex pointers.

Off topic: Something on that web page causes Firefox on my MBA2020 to use 133% of CPU, 30% of GPU Helper, the fan goes to full speed, and scrolling is slow and janky. I can barely read the article.

When I go to Reader mode, the CPU goes down to less than 20%, scrolling works great, and the fan goes off.

Did they implement scrolling using JavaScript?

One observation I've had recently. Postman files seem more popular the OpenAPI specs lately. Major SaaS companies will produce a postman file but not an OpenAPI spec. Two examples: Salesforce and Notion

This is really unfortunate because Postman requires you to have an account and log in to download or export these to another format.

Prediction: Postman produces a paid MCP for API lookup in the near future