I just read through yada’s docs and it seems a very well-crafted high-level library for HTTP. Are there plans within JUXT to continue to add “sister” libraries like bidi to address other aspects of modern web-dev like e.g. websockets, auth, i18n? And what about operational concerns like deployment, logging, monitoring etc?
I see there is an “edge” project that aims to tackle some of these things so perhaps?
yada supports sse, which we generally prefer to websockets. auth is handled in yada too. i18n is something we have explored enough for our work, but there's some options about.
Operationally, we do have roll/mach which we use for deployments. Mostly we're generating terraform based on our aero configs though.
Logging - tools.logging works good.
Monitoring, we're figuring this out ourselves right now 😛
we use CloudWatch for a lot of things though.
I’ve only skimmed the docs so apologies if this is mentioned there — is there a way to add a pervasive middleware across all handlers/routes?
Or perhaps a bit more interestingly, across some handlers?
BTW, thanks for all this!
@orestis yada doesn't have middleware 😛. It does have interceptors, you can add it to some by using clojure.walk/postwalk on a routing data structure.
Cool, sounds like having the resources being data structures enables a lot of cool stuff 🙂
@orestis yes, that’s very convenient
speaking of yada, anyone have thoughts on https://github.com/juxt/yada/pull/223 ; it's pretty simplistic and just allows you to directly pass the return schema directly through to https://github.com/metosin/ring-swagger/ ; currently the only thing that's preventing it is that the schema doesn't allow the key :schema
in responses
(and yes, of course we're speaking of yada on #yada )
looks good to me (didn’t try running it) I guess the next step would be to actually use the schema to check/validate the reply and not use it just for documentation.