Clojurians Log v2

@ben.sless thanks for the pointer, this is useful. Will add it to my list of things to consider. Though I am starting to lean towards the downsides with the reactive pattern weighing more than the upsides, i.e. perhaps a clojure api would be best served staying away from this pattern.

I share the feeling, however, until we get project loom (unless you want to run experimental JDK in production) your options are: - synchronous code - buy in to async world which colors all your code - buy into streaming abstraction (such as core async pipelines) which will dictate your entire architecture If all of this happens in a web handler perhaps you could try interceptors as well. I also saw you mentioned synchronous db access due to jdbc. You can try to square that circle with core async, or alternatively give the vertx client a try. I saw metosin used it in porsas but haven't tried it myself. (http://github.com/metosin/porsas)

I don't buy the "boring code" argument. This problem is not essential to reactive/functional programming, it's purely about syntax, and it's only an issue in languages with poor metaprogramming support. The infamous snippet shown around 9:33 could be written like this :

(require '[missionary.core :as m])
(m/ap
  (let [user (m/? (find-user-by-name ws name))
        cart (m/? (m/aggregate conj (load-cart user)))
        uuid (m/? (pay (transduce (map get-price) + cart)))]
    (m/? (send-email (m/?= (m/enumerate cart)) uuid))))

Any chance you can share the container model? I.e. are you running this inside of say jetty as well or are you running an aleph server which is world facing?

The sync db comment was not from me. In my particular case for this particular api it would be making calls to rest apis to assemble a response to a client http request

For our public APIs, the aleph endpoints are fronted by a pretty standard loadbalancer setup (with some machinery to handle dynamically-allocated instances). Aleph is built on Netty, so I’m not sure how you’d use it with Jetty anyway. Our internal services also use Aleph, but those endpoints get routed to directly by the service mesh.