The problem with this approach is writing openapi by hand from scratch is incredibly tedious process. Writing Protobufs, capnproto or any such similar idl feels much more productive

it lacks flexibility but i really enjoy grpc-gateway for 99% of my work

https://github.com/grpc-ecosystem/grpc-gateway

gRPC-GW is the way… if you’re fully bought in into Go. A bit harder sell if you’re on other platforms - you need specialized proxy infra

Its a bit icky but LLMs / copilot can speed up the creation of openapi specs a lot.

Agree it doesn't fix the "root" problem that the overall syntax is not ergonomic.

My point was that writing an openapi, or other IDL is faster than writing the code to manually do these things.

And more accurate than LLMs.

Feels like whenever an LLMs could code it, you'd be better of not having the boilerplate code at all.

Agree 100% with all points. I love contract-first. Better for producers and provides multiple tooling options and better docs for consumers.

I was agreeing with parent that some spec formats frankly suck to write by hand and openapi yaml is IMHO one of those (as opposed to say .protos which are nice for humans to read/write).

I use LLM as glorified interactive autocomplete to speed up writing the yaml specs (not the code! Use deterministic generators for that!) and it works great for me, personally (n=1 anecdote).

Or, if you're more into publishing an Openapi spec from your Go code, I do like danielgtaylor/huma[1] and swaggest/rest[2].

[1] https://github.com/danielgtaylor/huma

[2] https://github.com/swaggest/rest

I've started doing the same but with oapigen; github.com/deepmap/oapi-codegen

I thougt it would be boring writing the spec, but it was not nearly as bad as I thought. Also, a spec is needed, so might as well write it up front.