What is wrong with open api tools generator?

[jvmlet]

Given the latest MS shift to support /encourage/embrace /etc. open source, why yet another open api generator ? What's is wrong with https://openapi-generator.tech/? Folks will be more than happy to accept PRs from MS team that generates better clients. Why Kiota?

[baywet]

Hi @jvmlet,
Thanks for your interest in kiota and for reaching out.
There are multiple reasons why we started yet another OpenAPI generator instead of contributing to existing ones:

• A tool that's simple to use: not too many command lines options, no templating mechanism.
• A tool that was blazing fast (the description for Microsoft Graph v1 is 60MB).
• A fluent API and models that are not tied to any specific serialization format/library, http client, authentication scheme.
• Broad support of OpenAPI specification features.
• Open Source approach.

Before taking on the work of starting yet another generator, we took a long time to analyze the existing tooling (about 30+ at the time) and none checked all the boxes. None were even close if we had heavily invested in contributions.

Let us know if you have further questions.

[jvmlet]

Thanks for answering this, @baywet, I can't tell I'm convinced though:

• A tool that's simple to use: not too many command lines options, no templating mechanism.
  They (open-api-gen) also provide build tools (gradle plugin/ ect ) to automate the stuff.

• A tool that was blazing fast (the description for Microsoft Graph v1 is 60MB).
  We generate/process a lot of open api docs - c#, kotlin, ts ,java, python .... the tool is definitely not the bottleneck of CI/CD pipeline.

• A fluent API and models that are not tied to any specific serialization format/library, http client, authentication scheme.
  It provides tons on binders for different libraries.

• Broad support of OpenAPI specification features.
  Just had a look at latest release, one of the release notes : OpenAPI 3.1.0 Add webhooks support. Is kiota capable as well ?

• Open Source approach.
  Exactly. Have a look at stars (18.7K), contributors(2.7k), history... I'm not sure even the giant can compete with open source community.

None were even close ???

[baywet]

Thanks for your reply.
I've provided some broad context here, I'd be happy to dive into specifics if you have more precise questions?

[jvmlet]

No more questions. Let's see Kiota in 1 year and how it evolves, time will tell...

[baywet]

Absolutely! For information the project is now 3 years old since the initial proof of concept and we're seeing healthy growth.

[rahuldhole]

Hey @jvmlet and @baywet, great discussion here! Competition among OpenAPI generators like Kiota, OpenAPI Generator, Orval, Fern, Kubb, and heyAPI is healthy and pushes the ecosystem forward.

That said, as a noob focused on frontend clients (TypeScript), I’m noticing Kiota is losing ground in the SEO game. Since both Kiota and OpenAPI Generator support multiple languages, it’s hard to find clear insights specifically for the TypeScript client. OpenAPI Generator is not closing GitHub issues, making it tricky to gauge the actual state of things.

The lack of recent comparison content for frontend use cases is frustrating. I’m stuck choosing between:

• Kiota (feels like it wants to dominate - MS is leading openapi v4. still can't see competitiveness for modern frontend clients, maybe TypeScript client is self-sufficient),
• OpenAPI Generator (mature and promising, but feels a bit bloated, I like config options. Won't be able to contribute if needed due to the Java codebase. I don't understand the logic of keeping all git issues open),
• Orval (solid but small community),
• Kubb (small community. deprecated),
• Fern (Haven't seen yet due to paywall)
• heyAPI (tried, looks amazing, but plugin's config is failing. Not stable yet. They are winning the SEO searches.)

I'm just sharing my struggle. I hope visibility on workflow management and modern frontend (Next, Nuxt, TanStack Query, etc.) use cases catches up!

The only way to decide is by manually testing each tool to see what fits best for long-term use.

[mrlubos]

I know you wrote this a while ago but let me know or open an issue if you run into any problems with plugin configuration!

[M-Yankov]

A little off-topic, not exactly generation of open api specification, but for the code generation

I come here because one of the first results in google for generate c# client from openapi is "Generate the API client with Kiota", wait that ?
The hell is this? Looking at the first example :

var authProvider = new AnonymousAuthenticationProvider();
// Create request adapter using the HttpClient-based implementation
var adapter = new HttpClientRequestAdapter(authProvider);
// Create the API client
var client = new PostsClient(adapter);

I saw Provider, Authentication, Adapter keywords and I'm done ... 😅 , I'm really scared of this words, because I know I have to read docs, make some setup, bla bla...
I remembered years ago there was something like "NSwag". I agree it is kind of confusing what exactly to use for a simple console app, but once understand it you might love it. No one uses NSwag nowadays 😅 ?

I will explore for my use case how scary is to setup Kiota and compare it to NSwag.

[jvmlet]

We are using NSwag for client and server stub generation. Because it produces well designed code. Open api tools for other clients.