assert-combinators

This can't be solved by static analysis - anything that crosses i/o boundary has to be asserted, refuted or predicated at runtime and you have libraries for it ie. [0] which doesn't throw (based on refutations which can be mapped to predicates without much cost and assertions) or [1] which throws (based on assertions). Predicates are the most performant but won't give you any indication on why it failed (ie. some nested field was null but was expected to be number etc). Refutations is great sweet spot as it's fast while giving information about error. Assertions are slow, but more often than not you don't care. You can map between any of them, but it doesn't make much sense for mapping ie. assertion to predicate as you'd be paying cost for nested try/catch while dropping error information. Refutation is great base for all 3. [0] https://g

We use in prod variant of no 1. [0]. Why? Because: * it's sql * it's extremely lightweight (built on pure, functional combinators) * it allows us to use more complex patterns ie. convention where every json field ends with Json which is automatically parsed; which, unlike datatype alone, allows us to create composable query to fetch arbitrarily nested graphs and promoting single [$] key ie. to return list of emails as `string[]` not `{ email: string }[]` with `select email as [$] from Users` etc. * has convenience combinators for things like constructing where clauses from monodb like queries * all usual queries like CRUD, exists etc. and some more complex sql-wise but simple function-api-wise ie. insertIgnore list of objects, merge1n, upsert etc all have convenient function apis and allow for composing whatever more is needed for the pro