looks like it's gotta be a collection. not a bad thing 😅

An approach I took when trying to do this was to define a route like

{:name :add-book
 :view book/add-book
 :requires-auth? true}

Great, actually that's a nice idea. Thanks. Do you have any kind of demo so it helps me to do this. Yes, I'm also wondering what are the different approaches that we can use for this situation.

Something like this:

(defn router-component []
  (let [current-route @(subscribe [::subs/current-route])
        user-is-authenticated? @(subscribe [::subs/is-authenticated?])
        current-route-requires-auth? (-> current-route :data :requires-authentication?)]
   (when current-route
     (if (and  current-route-requires-auth? (or (false? user-is-authenticated?) (nil? user-is-authenticated?)))
       [(login-view)]]
       [(-> current-route :data :view)]]]))))

Yes, I'm using reitit + re-frame. So, you might be calling this function from rdom/render , right? Like this,

(rdom/render [router-component] (.getElementById js/document "app"))

Yes, you’re right.

Thanks, buddy. 🙂

Non primitive type hints are there only for the compiler to help it with java interop

And “String” isn’t a java primitive, I take it?

https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html says no, cool

thanks, good to know

In clojure, the only primitives which can be used as argument type hints are long and double

filter only filters the content, it won't give you parts of elements and will return the element for which the filter condition is true.

(mapcat #(map :q %) vals)

@U01M742UT8F that makes sense, ty

@U3JH98J4R : o that was fast -- could you explain the logic behind that one for me?

not 100% sure on how to invoke

sure. mapping :q over a collection of maps gets you a sequence of the q’s

(map :q [{:q 5} {:q 3}]) -> (5, 3)

if you map that over each one of the collections you end up with

((5 3) (1 7 9 8) (4 2 0) (9))

and you want to concatenate each one of those to get your result

excellent explanation thanks 😄

which mapcat -> map and con*cat* does in. one step

so for the vals in there... are you passing in the data there?

yep

because I get clojure.lang.LazySeq@###

maybe i need to make it realize the sequence somehow

user=> (def data [ [{:q 5}{:q 3}] [{:q 1}{:q 7}{:q 9}{:q 8}] [{:q 4}{:q 2}{:q 0}] [{:q 9}] ])
#'user/data
user=> (mapcat #(map :q %) data)
(5 3 1 7 9 8 4 2 0 9)

(i'm passing this in as a value to Selmer which seems to be okay with unrealized lazyseq)

okay cool thank you just confirming 😄

the other way to do it is

user=> (for [row data
             {:keys [q]} row]
          q)
(5 3 1 7 9 8 4 2 0 9)

which is measurably less clever looking

yes quite 🫖

destructure by ... keys 😅 that one makes me think

cool to see an alternative!

ah the for sets it as one coll/chunk/part of the vector at a time

thanks a ton 😄 calling vec on the lazySeq seems to have made it realize

I'm using clj-http-lite because I can use it the same from clojure, babashka, or graalvm native.

First, regarding support for core.async, you just need to deliver a promise channel in the callback and you're in CSP land, I wouldn't worry about it in particular • httpkit: maintained, no external dependencies, convenient API • clj-http: Big dependency, rich API • aleph: not sure about its status, brings in large dependency and manifold's async model • yada: don't know about it

hato is a good one. Uses the standard java http client and no apache dependency

added requirement: tracing support, for APM

What resolution of tracing

id like to be able to easily instrument datadog apm tracing for http calls. see latency and such, also on jvm level

Metrics and instrumentation - on the JVM you just need to export JVM metrics

For latency, in asynchronous processes you either have support of whatever metrics library you're using, or you could go with a low-tech solution

(let [start (System/currentTimeNanos)] (some-async-fn params (fn callback [response] (let [diff (- (System/currentTimeNanos) start)] (report diff))))

yeah i don’t think that will do it^. Sidecar monitoring is a whole separate game

@U011QKW5RGF What are you using right now?

I'm using http-kit ad hoc, no APM instrumentation at all. From what I understood, an advantage for clj-http is that it leverages Apache HttpClient, which should have good APM support since it is good ol' java

Practically speaking, I'm about to write an in-house http library for my company. It should have our own instrumentation and other in-company requirements. Reason for opening this discussion is that I'd like to start with some research and community recommendations.

The first question is what are you monitoring. "APM instrumentation" is wide net. What do you want to see, in what context?

Edited more detail in that APM requirement: cross-process instrumentation

Example scenarios: We have one app which makes http request i.e. it's a client. Another one is a server. I'd like to see spans joining these two "processes" over a single trace. See example screenshot. Primary use case is to identify performance bottlenecks between http client and server.

Can't upload a screenshot, but see the ones in this link https://docs.datadoghq.com/tracing/visualization/#trace Notice it shows different colors for different processes (can be different apps too), and how much time it took for every process to run different functions.

Maybe Aleph is more appropriate for me requirements? Considering it is based on Netty which means free Java APM instrumentation, considering it's a popular library

@U011QKW5RGF We switched from http-kit to Hato at work -- we rely heavily on New Relic and it works great with Hato (but didn't work with http-kit).

We previously used clj-http (which also worked great for New Relic) but dragged in dependencies we did not want. I blogged a bit about this at https://corfield.org and I'm happy to answer any follow-up questions.

(Hato wraps the built-in JDK HttpClient)

thanks Sean for the thorough answer, I'll check it out. is it maintained? last commit was 4mo ago, don't know what to make of it

Hato? Yeah, it's "done" (i.e., complete) so I wouldn't expect much work needed on it.

And four months is nothing in the Clojure world. Several popular libraries haven't had much in the way of updates for years because they're "done". They solve a single, simple problem and they do it well.

Thanks Sean. Damn, it looks like JDK HttpClient is still not supported in DataDog https://github.com/DataDog/dd-trace-java/issues/1478 Did you have to do something special to integrate it with New Relic?

Looks like New Relic added automated support on March 2021

Hmm, I'm a bit surprised it was so recent with New Relic -- but we were mostly blocked by their lack of support for JDK 16 and 17 until recently so we'd held off a lot of refactoring (including the switch to Hato) until they were closer on that.

@U011QKW5RGF We use a specific executor for our HTTP client calls (Clojure's own Agent executor) and we create a single client instance for each combination of connection timeout and follow redirects.

(defn- build-client
  "Supports :timeout (treated as :connect-timeout).

  Uses :redirect-policy :normal by default.

  Uses the Clojure Agent executor."
  [opts]
  (http/build-http-client (assoc opts :executor clojure.lang.Agent/pooledExecutor)))

(def ^:private client-cache (atom {}))

(defn- ensure-client
  "Given a possible client, a connect timeout (or nil),
  and a redirect flag (boolean), return the client if
  passed in, else get a client that matches the policy
  being requested."
  [client connect-timeout follow-redirects]
  (if client
    client
    (let [cache-key [connect-timeout follow-redirects]]
      (if-let [client (get-in @client-cache cache-key)]
        client
        (get-in (swap! client-cache
                       (fn [cache]
                         ;; avoid race condition on creation:
                         (if (get-in cache cache-key)
                           cache
                           (assoc-in cache cache-key
                                     (build-client (cond-> {:redirect-policy
                                                           (if follow-redirects :normal :never)}
                                                    connect-timeout
                                                    (assoc :connect-timeout connect-timeout)))))))
                cache-key)))))

thanks! . wait, are you sure that clojure agent pool executor actually creates different os connection pools using http clients?

That's just to reduce thread usage to a "safe" level -- otherwise hato can overwhelm your process creating it's own threads for its default executor. The connection pool is per client instance as I recall? And we just rely on the default behavior (which works fine for us with the above setup).

from what i saw the connection pool is global and static as a jvm parameter, so if i deduce correctly it's shared across all client instances. am i wrong? 😬

I don't remember. I'd have to go read the docs and the source. We do not specify any JVM parameters related to the HttpClient and we have some pretty heavy usage of it so I guess the defaults are good -- modulo my notes above about using a fixed pool executor and a handful of specific singleton client instances.

alright. thanks for all the thorough information sean

The default executor for Hato is not a good default, in my opinion (we tried it -- briefly! -- but had to switch to a fixed thread pool executor and decided to reuse Clojure's rather than risk adding a new pool and overwhelming our systems).

sounds like a good idea

Creating a new client for every connection is also not a good default approach. Again, we tried it and quickly decided it wouldn't work for us -- although I don't remember the specific details of that issue. I'd have to dig through our JIRA history for the ticket that switched to singleton client instances based on client options, as noted above.

yeah I intend to use a single client as well so I wound reuse the same threads, I'm just worried I won't have os connection pool granularity for different use cases in the same application

i’m trying to replicate but i’m not seeing your error

cd /tmp
dan@mbp-m1 /tmp % clj
Clojure 1.10.3
user=> (fn [x y]
   (println "Making a set")
   #{x y})
#object[user$eval136$fn__137 0x648ee871 "user$eval136$fn__137@648ee871"]
user=>

can you paste in here exactly what you are typing in?

or a screenshot of your repl?

Sorry, the HTML version of the book has a button to copy the code, and surely the copied text has some non-valid character. If I paste the code copied from the book's web page I receive the error, but if I type it, the result is correct. What a shame! Excuse me. I will not re-copy the code with the copy button that appears in the HTML version of the book. :man-facepalming: I attaching the screenshots. Thank you very much for your interest in helping me and again I sincerely apologize. 🙏

Thanks a lot @U11BV7MTK

my pleasure!

In the REPL, how do you split the line like that? I type (fn [x y]) ...and with the point before the trailing paren, put in by Paredit in my emacs clojure REPL, I want to be able to indicate that it's to continue onto the next line but hitting return submits it to be evaluated. C-RTN doesn't work.

Got it - C-j,