News for hackers. Stuff that matters.

indybonez

Re:Building a High-Performance OpenAPI Parser in Go on Sunday December 14, 2025 @06:32PM (#46268314)
We (Speakeasy) recently open-sourced the OpenAPI library we use to generate SDKs and Terraform providers.

We built this because we found existing Go libraries struggled with the "sharp edges" of OpenAPI—specifically dynamic types (polymorphic fields) and complex reference architectures (circular refs/remote files).

This library uses Go generics to maintain strict type safety without losing flexibility and includes native support for the new Arazzo (workflows) and Overlay specifications.

Code is here: https://github.com/speakeasy-api/openapi

Show HN: Open-Source OpenAPI Parsing, Arazzo and Overlay Support from Speakeasy

https://github.com/speakeasy-api/openapi

At Speakeasy, we spend a lot of time working with OpenAPI specs, and we kept running into the same issues: existing parsers are either too rigid, incomplete, or don’t provide the foundations needed to build tools on top of OpenAPI.So we built our own: speakeasy-api/openapi.This is a fully open-source library for parsing, validating, and working with OpenAPI specifications. It’s written in Go...

( Read More... | no comments | on HN )

Show HN: An OpenAPI guide written for developers

https://www.speakeasyapi.dev/openapi

Hey HN! I work at Speakeasy building SDK generation and general API tooling. As part of our work, we’ve been helping a lot of companies improve the overall quality of their OpenAPI documents. As popular as OpenAPI is, there is a shocking lack of good information for developers who are trying to learn how to effectively work with the standard.To fix that, we have put together the full OpenAPI...

( Read More... | no comments | 8 points | on HN )
The way I have always done this is to write wrappers for all integrations, whether they are via SDK or direct HTTP calls to an API (they were generally called Clients like StripeClient). Each of these wrappers had a common purpose to abstract away the underlying integration (so if we wanted to switch Stripe out for another vendor, the changes were generally more self contained), but these wrappers also allowed us to capture telemetry about our integrations such as usage, versions, services they were called from.

Most of this telemetry either went to Datadog or Prometheus but we could also have them go to a central location that allowed us to build reports on usage and what all our integrations were.

Then we got all the tracking you mentioned for free whenever we implemented a new API. The initial lift was always a bit longer but very much worth it in the end