clojure-norway 2022-09-30

slipset05:09:55

God morgen!

cjohansen06:09:36

God morgen!

god morgen!

Morn!

Morn morn!

Morn! Er det noen her som har erfaring med validering av funksjoners input/output gjennom spec/malli instrumentering?

oddsor10:09:03

Vet ikke om jeg vil si at jeg har særlig mye erfaring med det, men jeg kan iallefall si at jeg har brukt det og syns det virker bra! Generelt er jo instrumentering av funksjoner helst noe man ikke gjør mye av i prod pga ytelse (man validerer heller “på kantene” av applikasjonen, som feks rest-endepunkter), men når man driver og utvikler så syns jeg det er en fin måte å både dokumentere funksjoner sine “kontrakter” og fange opp uventet input på. En ting jeg har lyst til å teste neste gang jeg rører Clojure-kode er å definere funksjons-spec via metadata på funksjoner i stedet for å bruke =>-funksjonen for å definere speccen “ved siden av”. Hvis man har en app som ikke trenger å validere input av en eller annen grunn kan man jo dermed slippe å ha malli som en prod-dependency: https://github.com/metosin/malli/blob/master/docs/function-schemas.md#function-schema-metadata

👍 1

👀 2

ingesol10:09:00

Jeg liker også metadata godt. Funker nesten som vanlig typedeklarasjon siden det står rett ved siden av parametervectoren

👍 1

slipset09:09:48

Vi bruker spec og har endel fdefs? Har også brukt schema og endel s/defn.

slipset09:09:02

Liten teaser. Neste Oslo Clojure Lunch vil bli avholdt i Ardoq sine lokaler. Denne gangen med (faglig) innhold. Gitt at alt går som det skal, da.

🎉 4

🚀 2

teodorlu07:10:11

Nice, gleder meg!

ingesol10:09:50

@slipset Vil du si at fdefs har vist seg å være nyttig? Husker du noen caser der du har tenkt “Jaggu bra vi har specs, ellers hadde dette gått rakt til prod”

slipset10:09:32

Tror ikke det har hendt så mye, men vi har en relativt stor test suite som tar hånd om mye. Og det meste smeller når du sender en string i steden for en database connection.

slipset10:09:35

Vi bruker specs til å validere input på rest endepunktene våre, og vi bruker vel fdefs for å dokumentere input til sub-systemer, hvis det gir mening.

slipset10:09:11

(s/fdef query! :args (s/alt :plain (s/cat :config ::repo-config :ctx ::specs/minimal-ctx :query ::query)
                            :with-fields (s/cat :config ::repo-config :ctx ::specs/minimal-ctx :query ::query :fields ::fields)))
(defn query!
  ([{:keys [postgres-read?] :as repo-config} ctx query]
    ...)
  ([{:keys [postgres-read?] :as repo-config} ctx query fields]
   ...))

Og så har vi eksempelvis:

(s/def ::repo-config (s/and ::config (s/or :both (s/merge ::repo/config ::postgres-repo/config)
                                           :mongo ::repo/config
                                           :postgres ::postgres-repo/config)))

og da til slutt i postgres ns’et

(s/def ::config (s/keys :req-un [::postgres? ::postgres-read? ::table]
                        :opt-un [::transform-keys ::prop->column-type-hint ::ds]))

Dette fanger aldri feil vi ellers ville ha sluppet ut i produksjon, men det gir en form for dokumentasjon som jeg ikke trenger, men som andre, kanskje ferskere til kodebasen, utviklere setter pris på.

slipset10:09:07

Det mest interessante er jo definisjonen av ::config i postgres-ns’et som forteller hva vi forventer av en config. og at den er ulik en mongo config som ser sånn ut:

(s/def ::config (s/keys :req-un [::collection] :opt-un [::db]))

med disse to definisjonene trenger man ikke løpe rundt i alle ulike config’er for å forstå hvilke muligheter man har.

ingesol16:09:40

@slipset Ja, jeg opplever at det er mye krutt å hente i ren dokumentasjon. Der liker jeg malli bedre, jeg synes hiccup-syntaxen deres er mye mer umiddelbar å lese

ingesol16:09:50

ser du også har en minimal-ctx der, høres ut som et pattern vi også veldig ofte støter på, at man trenger ulike versjoner av specs for en type, noen mer og noen mindre strenge

slipset16:09:04

Jepp. Det er også en måte å kommunisere hva dette laget trenger. Andre trenger andre ting av ctx’en.

slipset16:09:17

Det jeg liker godt med specs for å beskrive data er at de er åpne, slik at de viker som data interfaces mer enn data klasser, på den måten at du må gjerne ha mer ting enn det spec’en beskriver.

ingesol16:09:03

Ja, det er nesten det viktigste. At man står fritt til å spece så lite eller så mye som man vil. Jeg har laget en spec for vår re-frame app-db, hvor det eneste jeg gjør er å sjekke at 2 keys er til stede, med riktig type på value. Ingen solid sjekk, men i praksis mer enn nok til å gi masse verdi.

2022-09-30

Channels