Clojurians Log v2

BTW https://www.meetup.com/london-clojurians/events/311402779/

i don't want to me mean, but why write in a less expressive language (openapi) and then convert into more expressive (malli)? why not just write malli and convert to openapi specs? yes, malli too is a spec so both ways are spec-first, but the malli approach is more expressive, precise and reflects the application better

That’s the whole idea, not to write code and not to generate the schema. In most cases when generating you will almost never have the openapi schema that you want without tinkering this and that and there’s always impedance mismatch between the what openapi defines vs what code opinions are. The idea here is to keep your users at centre and you code comes off it, not the other way round and it’s quite opinionated on it. The app needs to reflect the openapi and not the other way round too. @mpenet has https://github.com/mpenet/legba too on the same ideas, different approaches.

Legba for example doesn’t use reitit or malli

they are clearly different approaches, I guess it depends on the usage context and many other factors. That said openapi is very expressive nowadays

I can imagine that having the API specification on OpenAPI format as a source code file in a repo can probably also help AI coding tools such as Claude understand what the API does.

in my context it's shared between a few languages (so not only clj devs) and we want to be able to use the full expressivity of json-schema/openapi, not the subset a generator lib provides. It cuts a layer of abstraction we don't need/want

Navi for me was mostly born out of the need of a large set of teams wanting to have a common ground and some of them who don’t use Clojure too. Most of them suffered from openapis being generated and never “quite right”.

but we also have ways to convert specs -> json-schema and other tidbits like that make it a non issue

I also have the feeling malli cannot generate schemas with if/then conditions, dependentRequired & a few others nice things present in json-schema nowadays.

it can have arbitrary predicates, but these things won't be encoded in the schema

in short, as it's often the case: when it comes to choosing one of the other, "it depends"