Det er herlig. :smiling_face_with_3_hearts:

FP er topp!

Bittelitt uenig i deg her. Vi har modellert ctx omtrent sånn:

(s/def ::ctx (s/keys :req-un [::org
                              ::org-ds
                              ::ardoq-ds
                              ::org-db
                              ::user-db
                              ::common-db
                              ::user]
                     :opt-un [::branch ::scope ::client-request-id :context/provenance ::user-time]))

Det jeg ikke kunne gjort i Haskell (gitt den definisjonen over) var

(assoc ctx :jeg-bare-trengte-denne-akkurat-nå bla)

(og, for å gi litt credit til Haskell, det er jo f*ckings umulig å vite hva folk assoc ’er på ctx rundt om i kodebasen. Det over er jo muligens kanskje et hint om et subset som kanskje er i bruk 🙂

Godt poeng, type for ctx er en mulighet.

dere har da et sett med funksjoner som alle tar et ctx-argument først, ala

(f ctx x y z)

Sånn ca.

Alt som herjer med databasen må ha en ctx parameter.

Da vet man at alt som ikke har en ctx ikke herjer med databasen.

aaah, interessant.

så ctx har en database-connection også?

Selvom det ikke er helt sant over alt, og det tripper meg hele tiden.

Ja, du ser jo det fra spec’en, den har vel en 4 -5 db connections til mongo og pg.

Vi har funksjoner som gjør

(defn bla [ctx]
   (fn [lol]
       (repo/query! foo-repo/config ctx pq/all)))

Skjønner.

Her kunne kanskje Haskell ha hjulpet, i og med at type-systemet ville tracka at du var i impure-land?

Jepp, du måtte returnert en IO noe hvis du skulle kunne gjort sideeffekter. (selv om det går an å ødelegge den garantien med unsafePerformIO)

En sånn halvveis artig greie som jeg kunne tenkt meg å leke med når jeg blir pensjonist er hvis du tar funksjonen over og gjør den om til:

(defn bla []
   (fn [lol]
       (make-query foo-repo/config pq/all)))

Mao, typen til bla måtte vært Ctx -> IO Noe, der Noe er typen til resultatet fra (repo/query! ,,,)

Dvs at du tilslutt har noe som:

(run-queries! ctx all-the-collected-queries)

Da har du kommet tett på hvordan Haskell funker i praksis! Du kan fint evaluere noe som gir et IO-resultat, men det skjer ikke noe hvis det resultatet ikke “bobles opp” til at IO-effekter skal kjøres.

Jepp

Det er litt kult hvis man tenker på dette litt (og det hender det at jeg får tid til å gjøre)

Heller enn å kombinere resultatet fra flere queries, kan man kombinere queriene og få et resultat.

Hva vil motivasjonen være for å “dytte sideeffektene helt til slutten”? Jeg kjøper at kontroll på sideeffekter er nyttig. Men ville du konkret vunnet feks ergonomi fra REPL-en eller testbarhet hvis du hadde gjort det i dag?

Litt avhengig av alt, lissom, men en tur til databasen koster skjorta. Så la oss ta no’ helt gal kode:

(let [record (db/query! db record (by-id 3)]
  (map #(db/query! db song (by-id %)) (:songs record))

(let [record (record-dao/by-id db 3)]
   (map #(song-dao/by-id db %) (:songs record))

Jaa, mye bedre ytelse.

Men, det kan også være (og det ser vi) at PG snubler i indeksene sine og at av og til så er det billigere å utføre to spørringer enn det er å konbinere dem.

Fristende å komme trekkende med datomic igjen 😄

Jepp. men ville tro at man står fritt til å skyte seg selv i foten med Datomic også, selvom det kanskje er vanskeligere enn med Mongo.

(let [record (record-dao/by-id db 3)]
   (map #(song-dao/by-id db %) (:songs record))

hvis du kjører spørringer mot en peer som kjører i samme prosess som JVM-koden din, kan du vel gjøre så mange spørringer som du vil uten at det er noe problem?

Ja, n+1 er ikke en problemstilling i datomic

Det var det ene, det andre jeg tenkte på er at les i prinsippet er pure, og side-effekter utføres ved å bygge transaksjoner av data

Så den svarte på ønskene lenger opp i tråden 😊

> les i prinsippet er pure Så lenge man sender inn en DB-versjon til funksjonen, feks ved å putte en DB-versjon på et ctx-map eller et req-map?

En db-verdi, ja

Jeg synes det er helt utrolig hvor dypt det funksjonelle kaninhullet går. Jeg trodde liksom jeg hadde skjønt det da jeg skrev Haskell for første gang, og kunne stole på hva som skjedde hvor — i kontrast til java-kode jeg hadde skrevet tidligere. Men det har så utrolig mye å si for arkitektur av én app, og design av systemer hvor flere apper skal snakke sammen.

Det er mye trygghet i å samle side-effekter på én avgrenset plass ihvertfall.