This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-08-31
Channels
- # announcements (1)
- # babashka (27)
- # beginners (107)
- # calva (2)
- # cider (1)
- # clara (1)
- # clj-kondo (17)
- # clojure (74)
- # clojure-europe (18)
- # clojure-nl (4)
- # clojure-norway (3)
- # clojure-spec (11)
- # clojure-uk (3)
- # clojurescript (10)
- # conjure (12)
- # datomic (4)
- # figwheel-main (1)
- # fulcro (28)
- # graalvm (11)
- # hugsql (12)
- # joker (1)
- # klipse (5)
- # malli (2)
- # meander (1)
- # membrane (9)
- # off-topic (26)
- # pedestal (6)
- # remote-jobs (1)
- # ring-swagger (5)
- # shadow-cljs (4)
- # test-check (14)
- # vrac (8)
- # xtdb (8)
Http-kit has an http client which is modelled after clj-http, but probably much lighter on GraalVM, so it becomes a contender in this space. So far clj-http-lite was the only light-weight GraalVM-compatible http client library. Clj-http recently became compatible, but still results into bloated binaries. Is anyone familiar with http-kit as a client?
I’ve used http-kit as a client, but not through Graalvm
btw, aleph was compatible as well it seems https://github.com/BrunoBonacci/graalvm-clojure/tree/master/aleph
@borkdude familiar in what way? It works as a http client - although we're standarizing on clj-http (we have a couple of custom middlewares for it). We've run into issues in the past, but as far as I know everything has been addressed. The only thing that always bothers me is the need to deref
the result of a request (I get it, it's async, but still)
I use http-kit almost exclusively. I've built firebase tooling around it. And a few other system too.
@borkdude I like it for the lightness. I often use google libs, so that adds a ton of bloat so I appreciate the lightness.