Hi all, that is recommended method to generate ktor client from OpenAPI v3 specs nowadays? Ktor support in openapi-generator seems to be outdated, it uses kotlin 1.3.50/ktor 1.2.4/serialization 0.12.0.

If you’re not already bought-in to using OpenAPI-generated clients, I wouldn’t recommend starting with this. I tried to use this a few months ago, and quite frankly the quality of the SDK it generated was pretty bad. There were some notable issues with the templates (I can’t remember exactly, but things like it wouldn’t even compile with certain configurations), and the fact that it generates an entire Gradle project rather than just the source code is really annoying (can’t really fit into CI for with app). Plus, there’s no way to customize the Ktor HttpEngine at runtime (among many other annoyances) I think if they could set it up to use something like KotlinPoet instead of Handlebars templates, the quality of generated code would be better, but overall it wasn’t a very pleasant experience for me. It might be worth it if you have a large API with perfectly-documented endpoints, otherwise I’d say it’s not worth it. It doesn’t do that much more than what you’d do by hand with Ktor, and I think you’ll find it to be much more flexible and usable to just do it yourself

Hi, Casey, thanks for the answer. We're now just testing possible ways to automate rest api client generation, as for now it looks not so bad idea. Definitely, from time to time we have to edit generated files manually but as for me it's much better than write it from scratch 😉 Our API well documented via OpenAPI and generated automatically on backend side, so my target in this case is to reduce api change adoption cost as much as possible and also to reduce the possibility of trivial errors, like mistype in field names between backend and frontend layers. BTW, we found moko-network library which supports modern kotlin version (1.4.10 at the moment), we'll try it.

Despite we ourselfs still use forked OpenApi code generator from ktor, which is quite simple via "buildSrc", the next time I will mess around that code I will definitelly chcek "vanilla" Openapi code generator gradle plugin, they put a lot of energy into kotlin support. I can imagine that jvm is working well, I have no actuall experiences with the current state for multiplatform, thats probably reason why moko exists. Here a sample https://github.com/dukecon/dukecon_mobile/blob/feature/kotlin-1.4-migration/shared/backend/dukecon/build.gradle.kts#L3 despite naming, its indeed a local plugin ....

I’ve struggled with codegen some time ago at work, we used OpenApi to generate server code for Spring. I agree the quality of output code is not great and sometimes lacks what you need; the only solution is to write your own templates and plug them into the generator https://openapi-generator.tech/docs/customization