[Feature] Investigate the scope of fixing the auto-generated Cosmos SDK OpenAPI spec

[Olshansk]

Problem description

The auto-generated OpenAPI spec in the Cosmos SDK is bug-prone per the description here.

This feature request is an ask of the fern ecosystem, with experience and expertise in this field, to look into the amount of effort it would be to enable native fern integration with the gRPC services in the Cosmos SDK. The actual work can be tracked in a followup ticket.

Why would it be useful?

The Cosmos SDK is the leading framework for building custom blockchains. Lots of small teams rebuilt SDK tooling which is Fern's core value proposition.

Describe the solution (optional)

The fern SDK hooks into the gRPC services and related protobufs to generate language specific SDKs.

Additional context

I have personally done a deep dive trying to get this to work via the OpenAPI spec resulting in these two issues: https://github.com/fern-api/fern/issues?q=olshansk

The discussion here points to the fact that we should potentially bypass the OpenAPI spec and reference the gRPC service and related protobufs directly.

[amckinney]

Following up with the context from #2813 -

We recently did some investigation into this and found that Google's protoc-gen-openapi is better suited for mapping .proto to OpenAPI. Please give that a shot and let us know how it goes - you might see that the original issue with the Cosmos API is resolved.

With that said, we'll still need to build in proper support for calling the services defined in your .proto files from Fern SDKs (i.e. supporting gRPC instead of REST), but this will at least show you what the Fern-generated SDK will feel like in the meantime. If you're happy with the result, we'd be happy to work with you on making this happen!