https://kotlinlang.org logo
#ktor
Title
# ktor
t

Toddobryan

12/01/2023, 4:31 PM
So, I'm trying to write an up to date generator that will take an OpenAPI spec and produce a starter Ktor project. The current one in https://github.com/OpenAPITools/openapi-generator is a couple of versions behind, but the big problem/concern is that it just overwrites the routing files when you re-run it. What would be nice is if the routing and the implementation could be separated, so that it generated an
interface
that you need to implement, the methods of which correspond to each URL. That way, if you change things in the spec, when you re-generate, the interface will change and you'll be able to see what stuff needs to change in your implementation. (continuing in thread)
Untitled.py
a

andriyo

12/01/2023, 9:52 PM
I like Ktor more for just writing APIs directly comparing to OpenAPI APIs definitions monstrosity :) and you can generate OpenAPI spec out of that. I guess if there is already OpenAPI spec, then to kick star a Ktor project it would be nice to have a generator. But I personally prefer our Lord and Savior ChatGPT for one off tasks like that to generate initial code out of the spec.
t

Toddobryan

12/02/2023, 2:06 AM
But if you work in a multi-framework environment, you need some way to negotiate what the spec is going to be and another team may not be happy with "just look at our Ktor."
a

andriyo

12/02/2023, 3:25 AM
Why not, we always had "reference implementations". But,of course, whatever works for the team. In my experience maintaining a robust specification in some neutral spec is too expensive if it's only needed handful of times. Big shops do that though. I think generating DTOs is like 90% of why people use such generators, especially since many design their APIs with some Request and Response objects so there is no need to do anything fancy for routing files.
t

Toddobryan

12/02/2023, 3:27 AM
The big problem is when you have a central API that people need to access from multiple clients in multiple tech stacks. We have Java, Scala, Kotlin, and Go on the backend, and Typescript on the front.