3 ms·

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

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.

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.