3 ms·

My team evaluated adopting kiota and we found the ergonomics to be really poor and the generated libraries to be needlessly over complicated and difficult to us

My team evaluated adopting kiota and we found the ergonomics to be really poor and the generated libraries to be needlessly over complicated and difficult to use. We evaluated c# and typescript. Which sucks, because the alternatives aren’t much better. Maybe I’m missing something but the swagger/openapi client generators shouldn’t be this bad as a rule…

neonsunset 2y ago
It is an unfortunate situation. I have this side project sketch since a year ago or so to implement a new gRPC-tooling-like OpenAPI generator for .NET, but sadly haven't had enough time for this kind of project as of lately. We could have had so much better UX, there really is no reason to have it as bad...
vbezhenar 2y ago
Yeah, now I'm just writing openapi yamls by hand and separately I write necessary code. Generators are so bad that I'm not going to use them. May be I should just write my own generator, but so far it seems like unnecessary complication.
- Atotalnoob 2y ago
  The openapi yaml can be generated (in dotnet) by swashbuckle. I hand roll the http client libraries, too
everforward 2y ago
I tried for Typescript and was likewise surprised when I opened the code; it leveraged a lot of dynamic features that felt unnecessary in code that was already templated. I think the code might be the result of dealing with highly variadic endpoints (e.g accepts either JSON or XML, and accepts either basic auth or OAuth, and produces one of 4 different response objects), combined with trying to minimize the bundle size for browsers. The code looks extremely lean; I wouldn't be surprised if more explicit code was 10x the size. That doesn't really explain the C# code; I'm not a C# dev, but I wouldn't expect "lines of code" to directly impact performance the way it does for browsers.
- baywet 2y ago
  one of the main advantages of kiota is that is doesn't assume anything about the API you're consuming, contrary to other generators. This means it'll need to carry more information like the media types etc... in the generated code as opposed to dependencies. And yes! one reason why TypeScript is not yet "stable" when compared with other languages is because we've spent a great deal of time optimizing for size. One of the many optimizations was to use interfaces over classes whenever possible, and when not, use proxies over actual classes. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... This is why for a small set of operations (<100) the added weight of a TypeScript client at runtime is almost negligeable. For dotnet size matters as well, especially when you consider scenarios like embedded or front end development or large APIs. Similarly, we've spent time optimizing for runtime size.
- elvis19 2y ago
  we are using the nswag tolchain (https://github.com/RicoSuter/NSwag https://github.com/RicoSuter/NSwag) for generating c# and typescript clients based on openapi specs generated by swashbuckle. you can tweak some details using config file too. it works quite well and even has integration in msbuild to avoid manual cli steps.
deleted 2y ago
[deleted]

neonsunset 2y ago

It is an unfortunate situation. I have this side project sketch since a year ago or so to implement a new gRPC-tooling-like OpenAPI generator for .NET, but sadly haven't had enough time for this kind of project as of lately. We could have had so much better UX, there really is no reason to have it as bad...

vbezhenar 2y ago

Yeah, now I'm just writing openapi yamls by hand and separately I write necessary code. Generators are so bad that I'm not going to use them. May be I should just write my own generator, but so far it seems like unnecessary complication.

Atotalnoob 2y ago
The openapi yaml can be generated (in dotnet) by swashbuckle. I hand roll the http client libraries, too

everforward 2y ago

I tried for Typescript and was likewise surprised when I opened the code; it leveraged a lot of dynamic features that felt unnecessary in code that was already templated. I think the code might be the result of dealing with highly variadic endpoints (e.g accepts either JSON or XML, and accepts either basic auth or OAuth, and produces one of 4 different response objects), combined with trying to minimize the bundle size for browsers. The code looks extremely lean; I wouldn't be surprised if more explicit code was 10x the size. That doesn't really explain the C# code; I'm not a C# dev, but I wouldn't expect "lines of code" to directly impact performance the way it does for browsers.

baywet 2y ago
one of the main advantages of kiota is that is doesn't assume anything about the API you're consuming, contrary to other generators. This means it'll need to carry more information like the media types etc... in the generated code as opposed to dependencies. And yes! one reason why TypeScript is not yet "stable" when compared with other languages is because we've spent a great deal of time optimizing for size. One of the many optimizations was to use interfaces over classes whenever possible, and when not, use proxies over actual classes. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... This is why for a small set of operations (<100) the added weight of a TypeScript client at runtime is almost negligeable. For dotnet size matters as well, especially when you consider scenarios like embedded or front end development or large APIs. Similarly, we've spent time optimizing for runtime size.
elvis19 2y ago
we are using the nswag tolchain (https://github.com/RicoSuter/NSwag https://github.com/RicoSuter/NSwag) for generating c# and typescript clients based on openapi specs generated by swashbuckle. you can tweak some details using config file too. it works quite well and even has integration in msbuild to avoid manual cli steps.

deleted 2y ago

[deleted]