Why is OpenAPI generation api not supported?

[J4sonZ]

I have worked in some large companies, and the go-zero I used was basically customized, and the function of generating api from open-api files was added. Why doesn't go-zero support it natively? As far as I know, in technology selection, self-developed APIs will become the reason for people not to choose them. Everyone is not willing to learn a grammar just because they choose a tool.

[kevwan]

Thank you for raising this question. We actually did consider using OpenAPI during the development of go-zero, but ultimately decided against it for several important reasons:

1. Verbosity and Complexity

The YAML-based OpenAPI specification format is overly verbose, which can make API definitions harder to read, write, and maintain. For developers working on microservices, the simplicity and conciseness of the .api format significantly improves productivity and reduces cognitive overhead.

2. Surprising Benefits in the AI Era

While AI-driven development wasn't a consideration when we first designed go-zero (LLMs weren't mainstream yet), looking back now, the .api format has proven to be exceptionally well-suited for modern AI-assisted and spec-driven development workflows. Large language models can understand and generate .api specifications much more efficiently due to their concise and intuitive syntax. This makes go-zero particularly powerful when combined with AI coding assistants, enabling faster prototyping and development cycles - a benefit we couldn't have anticipated but are excited to see emerge.

3. Go-Zero Philosophy

Our design philosophy prioritizes developer experience and practical efficiency. While OpenAPI is a widely-adopted standard, we believe that the right tool should fit the task. For the go-zero ecosystem, the .api format strikes the optimal balance between simplicity, expressiveness, and tooling integration.

That said, we understand the concerns about learning curves and ecosystem adoption. If OpenAPI interoperability is important for your use case, we'd be happy to discuss potential solutions such as bi-directional converters or plugins that could bridge the gap between .api and OpenAPI formats without compromising the core experience.

[J4sonZ]

Thank you for raising this question. We actually did consider using OpenAPI during the development of go-zero, but ultimately decided against it for several important reasons:

1. Verbosity and Complexity

The YAML-based OpenAPI specification format is overly verbose, which can make API definitions harder to read, write, and maintain. For developers working on microservices, the simplicity and conciseness of the .api format significantly improves productivity and reduces cognitive overhead.

2. Surprising Benefits in the AI Era

While AI-driven development wasn't a consideration when we first designed go-zero (LLMs weren't mainstream yet), looking back now, the .api format has proven to be exceptionally well-suited for modern AI-assisted and spec-driven development workflows. Large language models can understand and generate .api specifications much more efficiently due to their concise and intuitive syntax. This makes go-zero particularly powerful when combined with AI coding assistants, enabling faster prototyping and development cycles - a benefit we couldn't have anticipated but are excited to see emerge.

3. Go-Zero Philosophy

Our design philosophy prioritizes developer experience and practical efficiency. While OpenAPI is a widely-adopted standard, we believe that the right tool should fit the task. For the go-zero ecosystem, the .api format strikes the optimal balance between simplicity, expressiveness, and tooling integration.

That said, we understand the concerns about learning curves and ecosystem adoption. If OpenAPI interoperability is important for your use case, we'd be happy to discuss potential solutions such as bi-directional converters or plugins that could bridge the gap between .api and OpenAPI formats without compromising the core experience.

1. whether a specification is difficult to read or difficult to write, this problem usually does not become a big problem in technology selection, if a specification is difficult to read or difficult to write, but it has a generality, then it is worth to learn and easy to be recognized by the leadership.
2. The problem with a self-developed api specification is that it's an exclusive language, it has no use other than in go-zero, it has no consensus in the marketplace, whereas open-api has a consensus in the community, and how is the lifecycle guaranteed? What makes me believe that you won't abandon the api specification and move to the open-api specification in the next release, but I'm sure open-api is here to stay, so why don't I just go find a base framework that uses the common specification?
3. I've worked in a lot of big companies, and what they have in common is that they try to use as many common things as possible, or abstract common layers out of their code or middleware? They are sick of being kidnapped by a particular tool.
4. as I said, some company developed go-zero and used open-api file as api file, the principle is open-api ----" api ----" code
5. I think go-zero's own api specification is too ideal.

[J4sonZ]

Thank you for raising this question. We actually did consider using OpenAPI during the development of go-zero, but ultimately decided against it for several important reasons:

1. Verbosity and Complexity

The YAML-based OpenAPI specification format is overly verbose, which can make API definitions harder to read, write, and maintain. For developers working on microservices, the simplicity and conciseness of the .api format significantly improves productivity and reduces cognitive overhead.

2. Surprising Benefits in the AI Era

While AI-driven development wasn't a consideration when we first designed go-zero (LLMs weren't mainstream yet), looking back now, the .api format has proven to be exceptionally well-suited for modern AI-assisted and spec-driven development workflows. Large language models can understand and generate .api specifications much more efficiently due to their concise and intuitive syntax. This makes go-zero particularly powerful when combined with AI coding assistants, enabling faster prototyping and development cycles - a benefit we couldn't have anticipated but are excited to see emerge.

3. Go-Zero Philosophy

Our design philosophy prioritizes developer experience and practical efficiency. While OpenAPI is a widely-adopted standard, we believe that the right tool should fit the task. For the go-zero ecosystem, the .api format strikes the optimal balance between simplicity, expressiveness, and tooling integration.

That said, we understand the concerns about learning curves and ecosystem adoption. If OpenAPI interoperability is important for your use case, we'd be happy to discuss potential solutions such as bi-directional converters or plugins that could bridge the gap between .api and OpenAPI formats without compromising the core experience.

Maybe we can try to add official support for the open-api specification, so go-zero may become more popular