Fuel: Why use Fuel over something like Retrofit, Volley?

[kaushalyap]

I came across this library, but it did not mention why one should use Fuel over something like Retrofit or Volley?

It is better to add what are advantages of using Fuel over other libraries to Read Me and documentation intro section.

[C06A]

Not diving deep (as I didn't use either library you mentioned) I see that Volley is Android only library, Retrofit works for Android and Java, but Fuel is for Android and Kotlin.

At the end it is a personal choice. I like Kotlin, so neither Retrofit nor Volley would work for me.

Comparing with other libraries is not necessary on the front of one's documentation. Choose one which fits your needs. There is no one size fits all...

[kaushalyap]

Actually you can use both Volley and Retrofit with Kotlin.

• https://medium.com/@elye.project/kotlin-and-retrofit-2-tutorial-with-working-codes-333a4422a890
• https://www.varvet.com/blog/kotlin-with-volley/

For me I usually reach to new library if it have some improvement over existing proven libraries.

[C06A]

Of cause you can. Kotlin has zero overhead inter-op with Java. Anything from Java can be called from Kotlin and wise versa.
Fuel is writing in Kotlin, so using it in Kotlin code much more natural.

Also using Fuel allows developer to reuse code (or at least experience) on server side app, not only Android.

As I said at the end it is a persanol choice.

[kaushalyap]

I am considering it for an android project. Lets see what repo maintainer have to say?

[kaushalyap]

Does this use Okhttp under the hood? how about performance?

[itscorey]

Does this use Okhttp under the hood? how about performance?

It doesn't. Fuel uses HttpUrlConnection internally. Retrofit, for example, is just a wrapper for OkHttp and is designed for Java.

Fuel is designed for Kotlin and I think this is one of the advantages of using it if you uses Kotlin as main language in your project. Also, it has a nicer support for Coroutines.

[kaushalyap]

Any benchmarks?

[itscorey]

Any benchmarks?

I do not think so.

[kittinunf]

Hi @kaushalyap, thanks for raising the concern and creating an issue here. Much appreciated.

For me personally, here are my thoughts over the project.

1. Fuel is built to be kotlin-esque. While other libraries you mentioned are great and nice, Fuel tries to fill in the different role which is to be the easiest or the most kotlin-esque to the project that already Kotlin as your main language. Retrofit or Volley or other libraries probably have different goals, but I do believe that one of their goals would be they are meant to be universally used in Java and/or Kotlin. This is great in one perspective (and this is not to undermine other libraries in any way), however, in our view (maintainer of Fuel), we viewed this as an obstacle to creating a much nicer API that is Kotlin-focused. We used to care on how the usage on the Java would be that that is no longer because we know entirely that if the Java users want to depend on the networking library, there are much better choices than us out there to use (and we don't try to compete that).

2. Fuel wants to be pervasive. This demonstrates with the many deserialization extensions that we provide out-of-the-box. It means that we know that you have a different object De/Serializer of your choice and we don't want to stand on your way. Rather, we want you to feel like home. We want to integrate with all of the major ones out there to provide a nicer usage experience. The ideal case would be solely adding dependency line in build.gradle file and you can jump start from the get-go. We want to make a difference in this area as well.

3. Regarding OkHttp, no we use HttpUrlConnection internally but in fact, we want this to composable in such a way that you can also plug the OkHttp as your main network driver as you can reference this as an example HttpClient. We haven't provided out-of-the-box for you, if you happen to have one and contribute back to the repo, feel free to do so.

4. Benchmark and performance are not one of our goals, we want Fuel to be on the easy-to-use side but not on the fast side. We certainly believe that Fuel will not win in a race of performance but at the same time we don't think Fuel is/will be a bottleneck in your application. (If it happens to be so, please file an issue because we want to get this right).

All in all, we think it is on your interest in evaluation for pros and cons. We believe we can do the best on the goal that we aim and provide something different in the market for developers to use. It is up to you to try out and evaluate what works best for your use case.

[kaushalyap]

@kittinunf Thanks for reply, keep up the great work! Add your project goals to the Read Me and doc it will be useful for users. Have not you done any benchmark of fuel throughout the development? (IMHO benchmarks are better to understand performance as library evolves.)

[SleeplessByte]

We have done internal benchmarks here and there, but this library is usually not the bottleneck in any application so there is no point sharing that data as it's not one of the design goals.