Backend

[oliyh]

No description provided.

[marksto]

@oliyh Is this an Easter gift for us all? 😅 This already looks super cool! Godspeed!

[marksto]

This seems to be the only place where impedance mismatch occurs. These "collection formats" are not inherent in schemas, right? Maybe we can decompose it into atomic methods instead — two predicates (string-schema?, array-schema?) and one constructor? Or, given that we've already allowed OpenAPI specifics to leak into this protocol (the leaf-schema method), is it fine to leave this method as is?

[marksto]

Oliver, if you need any help porting the Plumatic Schema-specific part of the codebase I recently implemented in order to fully support the "parameter aliases" feature, just give me a nod. These are basically:

• the more or less self-contained martian.schema-tools ns, which is specific to Schema and is only used by
• the martian.parameter-aliases ns that exposes 3 functions: alias-schema, unalias-data, and registry

Hopefully, for Malli we won't have to re-implement alias-schema/unalias-data with custom pre-walks with path, but will rather use Malli schemas built-in introspection capabilities (if they are sufficient enough, I didn't check yet, but it looks like we should be able to leverage mu/subschemas, mu/path->in, and friends). As for the registry, since Malli is fully supported by Babashka, we'll only need to implement a lazy variant (similar to the LazyRegistry instance).