This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-06
Channels
- # announcements (33)
- # babashka (13)
- # babashka-sci-dev (23)
- # beginners (94)
- # calva (105)
- # cider (37)
- # circleci (1)
- # clj-kondo (45)
- # cljs-dev (59)
- # cljsrn (2)
- # clojure (145)
- # clojure-czech (1)
- # clojure-europe (19)
- # clojure-nl (18)
- # clojure-norway (13)
- # clojure-portugal (1)
- # clojure-uk (5)
- # clojurescript (19)
- # community-development (2)
- # conjure (3)
- # copenhagen-clojurians (1)
- # core-async (34)
- # data-science (6)
- # datomic (25)
- # emacs (43)
- # fulcro (19)
- # graalvm (7)
- # graalvm-mobile (12)
- # graphql (10)
- # honeysql (3)
- # hyperfiddle (3)
- # improve-getting-started (2)
- # interop (20)
- # kaocha (3)
- # lsp (16)
- # meander (7)
- # off-topic (22)
- # other-languages (14)
- # portal (15)
- # releases (1)
- # rewrite-clj (2)
- # ring (1)
- # shadow-cljs (119)
- # spacemacs (19)
- # sql (65)
- # testing (4)
- # tools-deps (11)
- # xtdb (29)
@borkdude In reference to this from the babashka book:
In the future babashka (1.0.0?) may come with an HTTP client based on the JVM 11 java.net.http package that ticks all the boxes (async, HTTP/2, websockets, multi-part file uploads, sane memory usage) and is a suitable replacement for all of the above options. If you know about a GraalVM-friendly feature-complete well-maintained library, please reach out!
... which boxes does https://github.com/schmee/java-http-clj not tick?
I'm thinking we may need that best-of-both-worlds option beyond curl & http-kit soon for our lambdas
great!
is that a candidate for inclusion in bb soon then? (just curious)
b/c that paragraph from the book says you might
that I pasted above
I didn't anticipate that we would include the full java.net.http classes, but we now did
I am planning to work on an http client solution that is more general and can be swapped out with other implementations
so then you can say: hmm, bb uses clj-easy.tools.http-client with java-http-clj as the backing implementation, but in our app we want to use httpkit, so then it's just a matter of swapping out the implementations while programming against the same API
I see
I wish I'd done that from the start, so I could freely choose between e.g. cheshire or jsonista or clojure.data.json as the json lib in bb for example, without exposing that
yeah, it's a great idea
what is it that you think are the best parts from bb.curl + httpkit? input for that API is surely welcome
I'm proxying an API w/ one of my lambdas, so it's going to be a mix of their two sweet spots (i.e. lots of small reqs for http-kit and some large reqs for curl). so having something that can handle both well would be ideal. so less API and more behavior.
yeah I'll probably do that
@cap10morgan The overhead of loading that lib is pretty tiny:
$ bb -e '(babashka.deps/add-deps (quote {:deps {java-http-clj/java-http-clj {:mvn/version "0.4.3"}}})) (time (require (quote [java-http-clj.core :as http])))'
"Elapsed time: 14.39565 msecs"
@cap10morgan Here's a demo of clj-easy.tool.json in bb: https://github.com/clj-easy/tools.misc/discussions/2#discussioncomment-2518657