speakeasy VS openapi-generator

I’ve built conviction that code generation only gets useful in the long term when it is entirely deterministic, or filtered through humans. Otherwise it is almost always technical debt. Hence LLM code generation products are a cool toy, but no sensible teams will use them without an amazing “Day 2” workflow.

As an example, in my day job (https://speakeasyapi.dev), we sell code generation products using the OpenAPI specification to generate downstream artefacts (language SDKs, terraform providers, markdown documentation). The determinism makes it useful — API updates propagate continuously from server code, to specifications, then to the SDKs / providers / docs site. There are no breaking changes because the pipeline is deterministic and humans are in control of the API at the start. The code generation itself is just a means to an end : removing boilerplate effort and language differences by driving it from a source of truth (server api routes/types). Continuously generated, it is not debt.

We’ve put a lot of effort into trying to make an LLM agent useful in this context. However giving them control of generated code directly means it’s hard to keep the “no breaking changes”, and “consistency” restrictions that’s needed to make code generation useful.

The trick we’ve landed on to get utility out of an LLM in a code generation task, is to restrict it to manipulating a strictly typed interface document, such that it can only do non-breaking things to code (e.g. adjust comments / descriptions / examples) by making changes through this interface.

In my mind the analagous behaviour would be if the golang checksum database added in license terms that stated "you need to abide by a BSL to use data from this service". What that actually would mean is so nebulous that it feels threatening.

[0] Source: https://registry.terraform.io/v1/providers/airbytehq/airbyte...

[1] Source: https://github.com/airbytehq/terraform-provider-airbyte/tree... gzipped : ~300 resources, ~300 data sources

(NB: in airbyte's case the TF Provider was generated from a ~150Kb OpenAPI spec via https://speakeasyapi.dev: implying docs could be compressed even more)

I'm working on a company https://speakeasyapi.dev/ with the goal helping companies in this ecosystem get great production quality client sdks, terraform providers, cli(s) and all the developer surfaces you may want supported for our API. We also manage the spec and publishing workflow for you so all you have to do is build your API and we'll do the rest.

Feel free to email me at [email protected] or join our slack (https://join.slack.com/t/speakeasy-dev/shared_invite/zt-1cwb...) . We're in open beta and working with a few great companies already and we'd be happy for you to try out the platform for free!

Hi all I am a founding engineer for a API Experience company called Speakeasy - speakeasyapi.dev and we have recently released a Client SDK Generator for APIs using OpenAPI 3.0.X documents (soon to support 3.1). The generator will generate idiomatic Golang SDKs (along with other languages) that feel natural to use, easy to mock, and just work. The generator is free to use and can be run via a standalone golang built CLI with no external dependencies that can be easily installed as a binary or via homebrew (mac & linux). Check it out here https://github.com/speakeasy-api/speakeasy. If you have any questions or want to get in touch to see how Speakeasy can help you improve your APIs, just let me know!

The generator has been battle tested on thousands of APIs and we are sharing the results in our github repo. If you want to try it out on your own, download the CLI or brew install and get started in minutes:

Disclaimer: We're an early adopter of Stainless at Mux.

I've spent more of my time than I'd like to admit managing both OpenAPi spec files [1] and fighting with openapi-generator [2] than any sane person should have to. While it's great having the freedom to change the templates an thus generated SDKs you get with using that sort of approach, it's also super time consuming, and when you have a lot of SDKs (we have 6 generated SDKs), in my experience it needs someone devoted to managing the process, staying up with template changes etc.

Excited to see more SDK languages come to Stainless!

[1] https://www.mux.com/blog/an-adventure-in-openapi-v3-api-code...

[2] https://github.com/OpenAPITools/openapi-generator

As a result, the following specification can be used to generate clients in a number of different languages via OpenAPI Generator.

Of course you can compile the server from source if you have Go and the OpenAPI generator JAR (https://github.com/OpenAPITools/openapi-generator?tab=readme...)

Follow these steps : https://github.com/c100k/rebootx-on-prem/blob/master/.github...

And then :

(cd ./impl/http-server-go && GOARCH=amd64 GOOS=openbsd go build -o /app/rebootx-on-prem-http-server-go-openbsd-amd64 -v)

By adapting the arch if needed. Not tested, but it should work.

TL;DR: Start generating your HTTP clients and all the DTOs of the requests and responses automatically from your API, using openapi-generator instead of writing your own.

As an alternative, you can also use the official OpenAPI Generator, which is a more generic tool supporting a wide range of languages and frameworks.

I trialed generating SDKs using the OpenAPI Generator package, which was largely unsatisfactory.

If Swagger/OpenAPI is available, save yourself a lot of trouble and generate the client using OpenAPI Generator. If not, use a library like RestEase to make it significantly easier to create the client.

For a run of the mill REST API you should generate OpenAPI (Swagger) info for the API using a library like NSwag or Swashbuckle. You'd want to do this no matter what because it's documentation for the API, but the bonus is that you can use it with tools like OpenAPI Generator to create API client code and models in a variety of languages. You certainly can create an API client library manually, it would entail having a nuget package with a class library that contains the models and client code for calling the endpoints (which I'd create using a lib such as RestEase unless you just enjoy writing boilerplate code by hand). However 95% of the time it simply isn't worth creating your own lib when OpenAPI is available because once you've done it a time or two it takes less than 5 min to run the generator and create (or update) a lib.

Then you can use oapi-codegen or openapi-generator to generate the Go (or other language) SDK for it.