@bbss :

(:require [aleph
             [http :as http]
             [netty :as netty]]
            [bidi.ring :as bidi]
            
  ... 

  (let [http-server (http/start-server
                     (bidi/make-handler api)
                     (::http config))]
    (netty/wait-for-close http-server)))

am working on a synchronous event sourcing approach using yada …

my initial approach is to have a method :response that publishes a command on an event server and then waits for the event signalling the resource creation

I am using core.async as a strawman for the event system and it all works fine

… but am wondering if it would be more idiomatic to tie the publish / look up resource events into the yada lifecycle

I’ve gone back and forth over the docs and can’t determine simple places to hook in so maybe the first approach is more idiomatic 😉

If you can get the first approach to work that would be better. Only because yada's interceptors are designed to work in a linear ordered sequence, which took a long time to refine. It's generally OK to add interceptors, but not much more than that

yada 2.0 has a more 'monadic' design to the interceptor chain and it will be possible to add all kinds of user-provided instrumentation adaptors etc.

ok, cool well it does all work now so I will leave it as is

e.g. for dev, your interceptors get more instrumented and the context is captured (for inspection) between each interceptor

I look forward to an depth discussion soon!

there is also a concept of profiles, so you can run the yada resource in different profiles (e.g. for dev and prod), which helps to balance trade-offs between raw performance, security and debuggability.

great stuff, thanks @malcolmsparks … once I got my head around the ctx I was good to go

@malcolmsparks does that allow for metrics capturing like in Zach's talk about the pumpkin carvers? 🙂

yes

but yada 2.0 is some way off, and even when I release it it will be some time before it gets to the feature-list of 1.1.x

I'll still be supporting 1.1.x for a long time yet

🙂

i have a question on 1.1.x

can I avoid this Cannot JSON encode object of class: class java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: No implementation of method: :charset of protocol: #'yada.charset/Charset found for class: java.lang.String?

the problem with these is that the stacktrace of the original error is no longer available in the server log

hmmm via :responses maybe?

@stijn: did you answer the question?

Would it be possible to use something like this in yada https://github.com/yeller/clojure-miniprofiler ?

I guess I would have to make an interceptor - what would be a good starting point?