Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make KtorClient private and depend on ApiClient in generated code #207

Closed
nielsvanvelzen opened this issue Mar 30, 2021 · 5 comments · Fixed by #314 or #322
Closed

Make KtorClient private and depend on ApiClient in generated code #207

nielsvanvelzen opened this issue Mar 30, 2021 · 5 comments · Fixed by #314 or #322

Comments

@nielsvanvelzen
Copy link
Member

Although we do use the ApiClient interface in most places it doesn't include the request, get, post and delete functions. This is because we use inline functions with reified types, which are not supported when using interfaces. Preferably we'd fix this by passing the class as parameters instead of using generics but when I looked into this it didn't look like a possibility.

Separating the KtorClient (implementation) from the ApiClient (interface) it would allow the usage of custom HTTP clients and make it easier to change it if we decide to drop Ktor at some point.

@Maxr1998
Copy link
Member

Maxr1998 commented Mar 30, 2021

If you pass classes as parameters, you could define reified inline extension functions afterwards, like so:

import kotlin.reflect.KClass

interface ApiClient {
    fun <T: Any> get(clazz: KClass<T>): T
}

inline fun <reified T: Any> ApiClient.get(): T = get(T::class)

@nielsvanvelzen
Copy link
Member Author

The reified fun's are not in the interface so we won't be able to use the interface in the generated API classes with that approach, besides. Ktor doesn't allow passing the return type as a class, they ONLY support reified types (not sure why they chose to do that..).

@Maxr1998
Copy link
Member

You could import the extension function, or only support the extension functions (aka syntactic sugar) for consumers of the API. Also, if I'm not mistaken, reified actually means simply passing the class to the function as a parameter, hidden behind compiler magic.

@nielsvanvelzen
Copy link
Member Author

I get your point but the problem is that Ktor doesn't support passing the class as a parameter. It requires a reified type send via generic (https://ktor.io/docs/response.html) but interfaces do not support it.

@nielsvanvelzen
Copy link
Member Author

I'm thinking we might want to switch from Ktor to something more low-level (like okhttp). This would give us more control and reduce the libraries dependencies. Besides, we don't use most of the Ktor stuff. The biggest change would be to do the JSON serialization ourselves (using kotlinx of course).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants