I've put a lot of thought into the design of Anterofit, and I've tried to anticipate the most common and the most interesting use-cases, but there's some parts I'm still not quite sure about and I'm interested in feedback.
Should calling service methods immediately submit the request, like Retrofit does, and return Call<...>?
Should the return type of Request<...> (or Call<...>) be explicitly required in service!{}, instead of being rewritten from the declared return type (assumed to be () if not provided)?
This could potentially allow abstracting Call/Request behind a custom user type or impl Future<...> in order to completely conceal Anterofit as an implementation detail.
Should there be request modifiers for mapping the deserialized response to another type, executed on the executor? (This is currently provided as Request::on_complete() and ::on_result(), but if the request changed to being immediately submitted then this won't be accessible.)
Allowing user code to run on the executor (via Request::on_complete() and ::on_result()) is a potential footgun, in that the user could block the executor (single-threaded by default) with some long-running code and prevent requests from being completed. Is this a significant concern or is a warning in the documentation enough?
I've put a lot of thought into the design of Anterofit, and I've tried to anticipate the most common and the most interesting use-cases, but there's some parts I'm still not quite sure about and I'm interested in feedback.
Should calling service methods immediately submit the request, like Retrofit does, and return
Call<...>?Should the return type of
Request<...>(orCall<...>) be explicitly required inservice!{}, instead of being rewritten from the declared return type (assumed to be()if not provided)?Call/Requestbehind a custom user type orimpl Future<...>in order to completely conceal Anterofit as an implementation detail.Should there be request modifiers for mapping the deserialized response to another type, executed on the executor? (This is currently provided as
Request::on_complete()and::on_result(), but if the request changed to being immediately submitted then this won't be accessible.)Allowing user code to run on the executor (via
Request::on_complete()and::on_result()) is a potential footgun, in that the user could block the executor (single-threaded by default) with some long-running code and prevent requests from being completed. Is this a significant concern or is a warning in the documentation enough?Bikeshed: "delegate" vs "wrapper" vs ... ?