What's the current state of yada vs apex? Is the latter still being developed?

yada is stable, but maintenance is slow. Apex is being actively developed. Apex has spun off a number of foundational libraries, which are progressing nicely - such as https://github.com/juxt/reap, https://github.com/juxt/vext, https://github.com/juxt/pick and https://github.com/juxt/spin. Apex will focus on OpenAPI rather than everything yada does. But the ensemble does/will-do more than yada does, and be much improved over yada. I hope it will be worth the wait, I think it will be really nice when it's ready to use.

I can't really give a time-frame because it depends on a number of factors (how busy we are at work, for example. But if you see how much it's progressed since ClojureD, it's been a very productive period recently (probably Covid related...)

Cool. So there will be an edge-like project showcasing the combination of these?

Yes, it's taking shape. There's https://github.com/juxt/site too which 'links' to Edge modules - which is a hack that @dominicm isn't a huge fan of 🙂

Not a preference thing, it just doesn't work over time 😛

Nice to hear

https://github.com/juxt/site is all this stuff with Crux at the bottom, but demonstrates how all these things work together. My current focus in this stack right now is https://github.com/juxt/spin - there's a tests branch there.

I've experimented with using some of these libraries in yada and had success. Particularly pick. Once there's maven release, I think that patch can make its way upstream.

It fixed a Charset bug you reported in fact @borkdude

A lot of these libraries are influenced by learnings from yada and other libraries. In fact, reap was pretty much extracted from code that was evolving in yada and jinx.

There's a lot of modularity here, and these libraries can be used independently of Apex. Yada is too big - overall it has something like 150+ transitive dependencies in the default version.

So a lot of this effort was figuring out how to break it up

@borkdude fwiw, I'm using yada in prod and I'd like to fix the bugs I'm hitting at least. Ideally by leveraging all this hard work. I'm trying to convince Malcolm that we can do a new yada that lives alongside the old one.

I notice that aleph is getting some love...

Plus leveraging lots of developments over the last few years (e.g. Ring 1.6 async handlers, OpenAPI 3.1, Vert.x/ReactiveStreams, and more)

@dominicm yes, that makes sense - I didn't want to pursue all these goals in the current yada code-base because it would have been too hard working within all the compatibility constraints. So it's better to leave yada as it is and figure out later how to upgrade it.

There's some fundamental things that yada and OpenAPI to differently - one is that yada determines content-type before status, OpenAPI determines status, which then influences the content-type decision. It's little things like that which are hard to resolve. Apex and friends are aligned more with the decisions OpenAPI makes, for right or wrong.