This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-25
Channels
- # anglican (2)
- # babashka (53)
- # beginners (99)
- # brompton (1)
- # calva (28)
- # circleci (43)
- # clj-commons (4)
- # clj-kondo (176)
- # cljsrn (22)
- # clojars (7)
- # clojure (175)
- # clojure-australia (2)
- # clojure-europe (20)
- # clojure-germany (1)
- # clojure-uk (5)
- # clojurescript (195)
- # cursive (18)
- # datomic (13)
- # emacs (2)
- # farolero (9)
- # find-my-lib (6)
- # fulcro (8)
- # graalvm (12)
- # gratitude (5)
- # helix (11)
- # improve-getting-started (36)
- # introduce-yourself (3)
- # jackdaw (21)
- # jobs (2)
- # joker (2)
- # malli (65)
- # meander (24)
- # nbb (2)
- # off-topic (4)
- # pathom (2)
- # polylith (17)
- # portal (5)
- # react (3)
- # reagent (22)
- # releases (1)
- # ring (4)
- # shadow-cljs (79)
- # show-and-tell (2)
- # testing (5)
- # tools-deps (9)
- # xtdb (12)
@borkdude Any thoughts on adding the java.net.Http* packages introduced in JDK 11 to babashka? Working with them in Clojure is quite nice, and would provide a method of doing http requests without additional dependencies. babashkalorians can then use their own simple wrappers if desired—in the spirit of http-kit but without buying into http-kit’s idiosyncrasies.
@grzm Yes, worth considering and perhaps in favor of the httpkit client at some point? In an early version I've tried out hato as a built-in client but it bloated the image considerably. Just adding the vanilla classes might work, but it remains to be seen how much the image grows. Worth a shot though, if you would like to experiment with this.
I think the httpkit client works pretty well for most things though and it was a really tiny increase in image size for both the client and server
I tend to write a lot of cljc babashka, and the clj version of http-kit has quite a few warts that we don’t like to work with in our clj code.
I’m sympathetic to the bloat issue, though, so I hear you there. Which is why I floated the question 🙂
it's not that hard: you can just add the classes you need to babashka.impl.classes.clj
I wrote some thoughts about that here: https://github.com/babashka/babashka/wiki/HTTP-client-and-server-considerations
one of the problems with adding an off-the-shelf clojure java 11 client is that there is no one popular canonical client yet
Indeed. That's my thinking, too. (I also think the clojure clients tend to try to do too much and as a result end up being more opinionated than I like. But that's a taste thing.)
Most of the concrete implementations of the http://java.net.http.* stuff are hidden inner classes (the interfaces and builders are what is exposed as the API). Is there anything I need to keep in mind for babashka.impl.classes.clj ?
@borkdude have you seen https://github.com/schmee/java-http-clj?
might be worth a shot, have no idea if it will be bigger or smaller than Hato when it comes to image size
@U3L6TFEJF I have seen it, but the dependency on spec may be trouble-some with image size.
hmm… I’d be happy to try to find a solution to that. would it work if I just remove the dependency on spec? spec is bundled with Clojure so it should work anyway, right?
In general I think it helps when you move the specs to a different namespace and also the loading of spec itself
ahh, just saw the wiki page you linked above, didn’t know you’ve already created a test branch with it, nice 😄
I can def move the specs to a separate namespace if you’re interested in moving forward with this
That would help general graalvm usage of your library so regardless of if babashka is going to use it, I'd do it :) There is still this consideration: > one of the problems with adding an off-the-shelf clojure java 11 client is that there is no one popular canonical client yet But if we added those classes to bb, then we could perhaps try to make your library work from source in bb
There is also the telex client which is similar to yours I think but has some interceptor stuff
So choosing one off the shelf is a bit hard. Perhaps starting with your client and vendor it as babashka.http-client
can work as well
understandable! I intentionally didn’t mimic the clj-http API in my client, which might be a drawback for this use-case since that’s what most other clients do
I’ll see about moving the specs to a separate namespace, if you want to use it for something then that’s awesome, if not that’s no problem at all 😄
I'll keep an eye out, I've seen several people use your lib, so I do think it's a good option :) Just needs some hammock time
At the moment, I am using this - which is pretty stinky.
(def url-parameter-of get "%7B%0D%0A%0D%0A++%22address%22%3A+%7B%0D%0A++++%22city%22%3A+%22Boston%22%2C%0D%0A++++%22country%22%3A+%22USA%22%2C%0D%0A++++%22postalCode%22%3A+%2202123%22%2C%0D%0A++++%22state%22%3A+%22MA%22%2C%0D%0A++++%22stre")
(-> url-parameter-of-get
(str/replace "+" " ")
(str/replace "%2C" ",")
(str/replace "%0D" "")
(str/replace "%0A" "")
(str/replace "%7B" "{")
(str/replace "%3A" ":")
(str/replace "%22" "\"")
)