Not familiar with Axios, but you might also want to take a look at https://github.com/gnarroway/hato or https://github.com/schmee/java-http-clj for no-dependencies options (if you’re on Java 11+).

https://github.com/http-kit/http-kit

Thanks! I'll check those out

@U3Q8MMREX since httpkit is part of babashka, you can also use it in shell scripts. Btw, I enjoyed the podcast interview on defnpodcast a while ago.

oh thanks!

it's funny to be getting back into normal JVM clojure, I've just been in the Arcadia pocket universe for years

I was trying to scrape the Notion API in python and I got really frustrated with the REPL experience. So here I am

Have you used Aleph at all? I was looking at it because I like Zach's libs, it does seem more complicated than http-kit in some ways

I've mostly used Aleph server, but I've also used the client. It works

I use clj-http and it supports async operations. Works great.

starting to use jdk11 client more and more, it's really good

had problems with both aleph/http-kit in the past. It was a long time ago for http-kit so maybe it's better now not sure. And aleph the fact it's in life-support + some deadlocks we had makes me reconsider its use

i've also had problems with aleph and http-kit and so would recommend clj-http.. unfortunately http-kit doesn't support true response streaming, it buffers the entire response into a byte array regardless of what you request: https://github.com/http-kit/http-kit/issues/90

I keep hoping someone will remake a clj-http library on top of OkHttp 🙂. maybe one day I can

I wonder why the problem in httpkit isn't fixed yet. One should maybe be able to pass in an object that is compatible with http://clojure.java.io which the response gets written to, without keeping it all in memory. That's the approach I took with babashka/process: https://github.com/babashka/process

Yeah I'm not sure why but it's one of the main reasons I never use it. Anyone have experience reports with https://github.com/schmee/java-http-clj ?

it's quite similar to hato, both are very minimalistic, the java api is not bad at all.

hato I think is somewhat compatible with clj-http api

I wrote a super thin wrapper for it as well with our specifics, interceptors at the bottom etc (not on gh for now)

I kind of regret having to make choices of what goes into babashka (right now it contains httpkit since it worked really well with GraalVM), but the Java 11 client space doesn't seem to have a clear winner yet. The java-http library seems simple enough to copy paste and base a babashka.http-client namespace on though, maybe in the future.

hato really didn't work well with GraalVM, since it has all kinds of dynamic require things. the java-http lib pulls in spec in the core namespace which also isn't great, but at least that's easy to get rid off

yeah it copied some of this stuff from clj-http I think

not a fan of dynamic requires either, but I understand the intention

(clj-http compatiblity)

aleph does more or less the same

btw, not async, but I have a very light weight clj-http like wrapper around curl: https://github.com/borkdude/babashka.curl

I ll see if we could make the repo for our client public eventually

one cool thing it does is not assuming input/output formats, everything is wired via an interceptor chain, you can use ring1, ring2, or just pain protocol fns depending on the interceptor chain you use with the client. So you can be extremely minimal / low overhead if you need to, or inject some crazy behavior to the chain if you need to

@U050SC7SV Interested in seeing that

I ll see on monday if I can have it open

that's interesting, what's wrong with pulling in spec @U04V15CAJ?

@U3Q8MMREX I’m reasoning from the perspective of building a GraalVM native image like babashka. Spec doesn’t yield optimal binaries because it has dynamic requires. But this is easy to fix.

I haven’t seen it mentioned here, but we have used aleph with great success so far. https://github.com/aleph-io/aleph