23 ms·

What does this offer that openapi-generator and swagger-codegen don't already do?

by 10000truths 2y ago

ari-hacker 2y ago
Probably nothing except being an official microsoft backed project.
- baywet 2y ago
  Kiota allows you to select the operations/APIs you care about for your client application instead of generating the whole API surface. That makes for a more nimble client.
  - dartos 2y ago
    Who’s optimizing for the size of their http client and using AI code generators?
chipdart 2y ago
I've ran a few tests with Kiota and I found that the generated code is awkward and needlessly hard to integrate. It's good to have options available but with openapi-generator around I hardly see the point of bothering with Kiota.
- baywet 2y ago
  do you have specific examples of what lead you to this conclusion?
  - chipdart 2y ago
    > do you have specific examples of what lead you to this conclusion? Just get a spec, run kiota,and check the output. Compare with the output from, say, openapi generator. No one can miss the difference.
    - baywet 2y ago
      Being different does not imply being better or worst. Again, any specify example on how the generated code could be better? (e.g. nullability information, etc...)
neonsunset 2y ago
For .NET, it produces "recommended" boilerplate, specifically serialization that uses correctly configured System.Text.Json in source generated mode. This makes it usable in AOT workloads and there have been fixes by Filip Navara to significantly reduce binary size impact. For other languages, I suppose it's an organizational effort within MS to standardize and consolidate SDK generation to produce consistent experience. More on .NET, last time I compared OpenAPI generator options - other generators did not do this or did it in a worse way. Even still, I do not consider Kiota to have the kind of UX that .NET deserves. For example, to consume gRPC-based API, your workflow is just: dotnet add package Grpc.Tools dotnet add package Grpc.Net.Client dotnet add package Google.Protobuf # add <Protobuf Include="myapi.proto" /> to .csproj That's it - the client is generated transiently and is a part of the project without getting in your way, I have a small shell script to do it as a one-liner. And maintaining a dependency of an application on a remote API of this kind is also easy if .proto is available via git - add it as a submodule or a subtree and just bump commits automatically (or manually if review is needed). You never need to manually re-generate and possibly re-reference or re-publish a separate client package for this to work. The sheer convenience of this at both individual and organizational level alone makes a compelling case for choosing gRPC over REST, architectural preferences notwithstanding. Last time I checked, Kiota required much more effort and ceremony. I understand that it's a "big generator to rule them all" that made to address both simple one-off APIs and ginormous Azure SDK, but .NET has all necessary building blocks to have similar or even better UX to what gRPC tooling provides. I suppose, it's just a matter of doing it and promoting the project.
- Atotalnoob 2y ago
  The azure SDK is terrible, mostly due to Kiota…
  - baywet 2y ago
    No Azure SDK is generated with Kiota today. Some use Autorest, some are handcrafted. This is mostly because kiota came out after all those SDKs, partly because Autorest assumes REST API conventions from the Azure design guidelines https://azure.github.io/azure-sdk/dotnet_introduction.html https://azure.github.io/azure-sdk/dotnet_introduction.html The only set of public SDKs generated by kiota from Microsoft are the Microsoft Graph SDKs.
dvfjsdhgfv 2y ago
If you don't use MS stack, nothing really.

What does this offer that openapi-generator and swagger-codegen don't already do?

ari-hacker 2y ago

Probably nothing except being an official microsoft backed project.

baywet 2y ago
Kiota allows you to select the operations/APIs you care about for your client application instead of generating the whole API surface. That makes for a more nimble client.
- dartos 2y ago
  Who’s optimizing for the size of their http client and using AI code generators?

chipdart 2y ago

I've ran a few tests with Kiota and I found that the generated code is awkward and needlessly hard to integrate. It's good to have options available but with openapi-generator around I hardly see the point of bothering with Kiota.

baywet 2y ago
do you have specific examples of what lead you to this conclusion?
- chipdart 2y ago
  > do you have specific examples of what lead you to this conclusion? Just get a spec, run kiota,and check the output. Compare with the output from, say, openapi generator. No one can miss the difference.
  - baywet 2y ago
    Being different does not imply being better or worst. Again, any specify example on how the generated code could be better? (e.g. nullability information, etc...)

neonsunset 2y ago

For .NET, it produces "recommended" boilerplate, specifically serialization that uses correctly configured System.Text.Json in source generated mode. This makes it usable in AOT workloads and there have been fixes by Filip Navara to significantly reduce binary size impact. For other languages, I suppose it's an organizational effort within MS to standardize and consolidate SDK generation to produce consistent experience. More on .NET, last time I compared OpenAPI generator options - other generators did not do this or did it in a worse way. Even still, I do not consider Kiota to have the kind of UX that .NET deserves. For example, to consume gRPC-based API, your workflow is just: dotnet add package Grpc.Tools dotnet add package Grpc.Net.Client dotnet add package Google.Protobuf # add <Protobuf Include="myapi.proto" /> to .csproj That's it - the client is generated transiently and is a part of the project without getting in your way, I have a small shell script to do it as a one-liner. And maintaining a dependency of an application on a remote API of this kind is also easy if .proto is available via git - add it as a submodule or a subtree and just bump commits automatically (or manually if review is needed). You never need to manually re-generate and possibly re-reference or re-publish a separate client package for this to work. The sheer convenience of this at both individual and organizational level alone makes a compelling case for choosing gRPC over REST, architectural preferences notwithstanding. Last time I checked, Kiota required much more effort and ceremony. I understand that it's a "big generator to rule them all" that made to address both simple one-off APIs and ginormous Azure SDK, but .NET has all necessary building blocks to have similar or even better UX to what gRPC tooling provides. I suppose, it's just a matter of doing it and promoting the project.

Atotalnoob 2y ago
The azure SDK is terrible, mostly due to Kiota…
- baywet 2y ago
  No Azure SDK is generated with Kiota today. Some use Autorest, some are handcrafted. This is mostly because kiota came out after all those SDKs, partly because Autorest assumes REST API conventions from the Azure design guidelines https://azure.github.io/azure-sdk/dotnet_introduction.html https://azure.github.io/azure-sdk/dotnet_introduction.html The only set of public SDKs generated by kiota from Microsoft are the Microsoft Graph SDKs.

dvfjsdhgfv 2y ago

If you don't use MS stack, nothing really.