https://kotlinlang.org logo
Join Slack
Powered by
I finally got time to try `arrow-endpoint`, but it...
# arrow
s
I finally got time to try 
arrow-endpoint
, but its not on 1.1.2 and all my apps are now on 1.1.2 Can I help in bumping versions and releasing ? cc: @simon.vergauwen
s
Hey @Satyam Agarwal, Sure thing. @Imran/Malic has been keeping it up to date, but there has not been much development there because there seems to be a lack of interest.
What is your use-case for using it? I've been brain storming some other ideas/solution for the things it tries to achieve. I.e. one of the motivations of this library was generations of OpenAPI documentation which is functionality that is completely missing in Ktor. That is/was one of the reason for me at least.
Client/Server generation is a nice extra, but it could also be achieved based on a generated OpenAPI spec... Perhaps even with a compiler-plugin that on the fly exposes a synthetic API that is implemented by Ktor, or an abstract impl.
s
I am basically interested generating docs based on suspend (Input) -> Either<ErrorResponse, Output> type signature. Ktor has swagger integration on roadmap for this year so let's see. But I am not sure it would be very optimal when you use arrow-kt from top to bottom. Same problem is with spring boot as well which already has open api/ swagger support.
Generating client server isn't that interesting for me as I don't consume neither I publish many apis. For me generating docs are more important for visibility and helping my frontend and apps team
Prototypes floating around on GitHub have a general idea by leveraging routes api. To provide locations and output type itself to the route. And I don't like that idea. With Eithers, everything is contained. And most of the times responses are just sealed types. Especially error responses.
So something like arrow-endpoints really piqued my interest.
Scala has same type of support.
s
Thanks, that is perfectly in line with what I expected 🙂
The biggest issue for the project is time investment of people 😕 There is still quite some work to be done before it can live up to its potential
Biggest hurdle being the manual creation of Schema / Codec atm. Dropping client generation could potentially simplify that issue by a lot (Only decoding, no longer serialising) , backing in KotlinX Serialization could reduce it again by a lot (Schema for free) and or could solve the Codec issue since KSerializer is isomorphic.
s
hmm. I see. Okay. Its summer time, and may be I can help out a bit. Should I do a fork, and raise a PR to delete client generation code to begin with ?
and bump dependencies ?
I can read through the code too, perhaps we can discuss how we want to solve doc generation
I was basically thinking, if the library does just one thing but properly to begin with, it's good enough. Maybe it'll get enough traction that people will start demanding dropped features.
Also it will solve my purpose. I have vested interest in this 😆
s
I was basically thinking, if the library does just one thing but properly to begin with, it's good enough
I agree, but maybe we should set out with those things are 😄 So I think there are a couple of questions we need to ask: • What do we want to be able to do with an 
Endpoint<I, E, O>
• Should we be able to install it as a 
Route
in Ktor, but also turn it into a 
RouteHandler
for Spring WebFlux? Or is 
Ktor
"enough". • It needs to be able to generate OpenAPI/AsyncAPI documentation • What about serialisation, are we going to force people to use KotlinX Serialization or do we need a more flexible approach where users can install their own serialization format? • How composable does each individual part need to be? Is it important that we can define 
val nameQuery: EndpointInput.Query<String>
or is there not such a strong requirement on the composition of "leafs" but are we happy more of a DSL approach.
Depending on the answers of these questions the Ktor OpenAPI feature on the roadmap might make this slightly obsolete. I.e. I don't think it's worth maintaining a whole library if Ktor offers good support for this out of the box, and/or we can probably implement a micro-library to support typed OpenAPI docs for Ktor.
s
I totally agree. Correct me if I am wrong, while going through the code of the arrow-endpoints, it looks like the library is baked into the route. (Just thinking out loud here and being a bit selfish) I, personally, don’t like this. Its basically this :
Should we be able to install it as a Route in Ktor, but also turn it into a RouteHandler for Spring WebFlux? Or is Ktor “enough”.
I want to have things nice to have completely separate from the main code flow. I agree this has the potential to make the generation of the openapi docs outdated, but I think we should be able to manage something bound tightly to input and output but also separate from the routes. Anyway, I agree we should atleast find out what ktor team has in their minds regarding openapi support. And I don’t care for spring 😛
Should we then table the discussion until we have found out more from the ktor team ?
s
it looks like the library is baked into the route
I'm not sure what you mean. The "core" of the library is just the ADT + a route resolver (so it effectively takes over routing from the used integration). That is done so you can simply install it as an interceptor as long as it supports 
suspend (Request) -> Response
. I don't care for Spring, but I have to deal with it from time to time 😅 But personally I am okay with targeting just Ktor, especially if it can reduce complexity / maintenance drastically.
Should we then table the discussion until we have found out more from the ktor team ?
Getting more info on this would be great! I need OpenAPI gen for some Ktor projects, and have been contemplating writing a compiler plugin with some DSL since I didn't know this was on the roadmap.
s
So we can nudge in ktor channel.
Let me ask.
👍 1
5 Views
Open in Slack
PreviousNext
Powered by