Fork me on GitHub
#malli
<
2021-10-05
>
Carsten Behring09:10:32

I could not get my head arround the best practices to use Malli for runtime checking of function parameters. I saw the docu about this, but wonder between "instrumentation", which seems to be dev oriented,

Carsten Behring09:10:02

vs call validate in the code

Carsten Behring09:10:51

I store my schema as function metadata if this helps.

Carsten Behring09:10:07

How do people do this ?

danielglauser14:10:03

When working with Malli we used it to test all API inputs to the system and sometimes the outputs from the system. We didn't use it to check common function calls. Why do you want to do that?

Noah Bogart14:10:24

for development it’s very nice to see when you meant to pass in a vec and passed in a map instead, but in prod i feel like those kinds of checks aren’t helpful (especially if the code actually runs how you expect anyways)

danielglauser15:10:02

I can see that though I usually accomplish those types of checks through my tests. It'll be interesting to see in anyone has a technique for using Malli for environment based assertions.

ikitommi15:10:07

@danielglauser it’s layered: malli.instrument can be used in prod too, it doesn’t contain any var-watches, clj-kondo emitting and thanks to it’s filters, you can annotate your functions with meta like {:malli/always-validate true} and instrument those in prod.

1
ikitommi15:10:01

have worked with a lot of codebases with Plumatic Schema where few (important) functions had the :always-validate on. e.g. when reading data from document-db or just Very Important Function (handling money) where the perf penalty is ok.

ikitommi15:10:47

malli.dev is built on top of malli.instrumentwith just start! and stop! , which both are stateful. would not use in prod.

ikitommi15:10:04

stateful as in watching the Vars and emitting (clj-kondo) files.

Carsten Behring22:10:26

I think "input checking" at runtime can be important for public functions. At the end, I only guarantee that my function works, if the caller does his part (giving valid input only). Failing so, resulst often in very ugly error message deep in Clojure, from which it is impossible to read what I have done wrong (as teh caller).

Carsten Behring22:10:08

"Output" checking is a complete different story. That I probably don't want to have in production code.

Carsten Behring22:10:25

Is somebody doing this ? I see various way to implement the parameter checking, and was wondering which works best. 1. Instrumenting

Carsten Behring22:10:36

2. direct calls of format

Carsten Behring22:10:44

Together with this come the different options, where to keep the schema ? as defn metadata or in some vars ? How can we the use those easely for documentation of a function ?