Ah! Nei, det var kanskje dumt. Jeg må vel ha en funksjon der inne for å kunne endre app uten å måtte restarte serveren.

(fn [req] (app req)) Er vel det samme som #'app ?

I før-eksempelet

eneste som typisk kan være annerledes er at objektet man får i body i diverse settinger kan være forskjellig. Typ om du laster opp en fil eller gjør noe annet “rart”, da er det typisk en Jetty-klasse eller en http-kit-klasse man får inn der

Jepp! Det gikk, @teodorlu

(defn start-server []
  (stop-server)
  (reset! server (hk-server/run-server #'app {:port 3001})))

Men jeg er litt usikker på hva #'app betyr egentlig, lol—Vanskeligere å lese.

Da bør det funke å bare oppdatere app uten å restarte alt :)

Det gjør det, ja!

Tror det er shorthand for (var app). Vars kan brukes dirkete som funksjoner. Men da slår du opp "hva er dette definert som nå?" før hvert funksjonskall.

Jeg forstår at det er short-hand for fn

Ellers sender du inn nåværende verdi (immutable)

har aldri helt skjønt meg på #' sjæl

Men hva gjør ' foran app der?

#'x er vel fort noe helt annet enn #(...)

#'x er vist en snarvei for (var x)

#'x er kort for (var x) var er en special form (Tror Jeg)

(beklager ræva formatering, skriver fra mobilen

ville vel nesten argumentert for å bare bruke var i stedet for, litt lettere å slå opp i dokumentasjon osv 🙂

næva formatering - skriver du med hele nævan?

Tror jeg først lærte dette av å lese dokumentasjonen til http-kit, men den ser ikke ut til å være tilgjengelig på nett lenger. http://Http-kit.org peker til noe annet.

#' er var-quoting, ja. Samme som var . Grunnen til at du vil bruke denne er at du da snakker om referansen, ikke selve verdien. Den praktiske forskjellen er at (do-thing my-fn) får en konkret implementasjon av funksjonen i my-fn, så om du reevaluerer definisjonen dens i REPL-et vil ikke do-thing kjenne til den nye versjonen. Dersom du heller gjør (do-thing #'my-fn) så vil do-thing få var-en/referansen i stedet, og hver kan den kaller den som en funksjon så ruter Clojure frem den gjeldende verdien til var-en.

Basically: Hvis du vil ha et REPL med fungerende reload så må du var-quote navngitte funksjoner som sendes rundt.

(Eller gjøre #(my-fn %), som i praksis oppnår det samme)

@U9MKYDN4Q godt formulert! Jeg prøvde å si det samme, men følte ikke helt at jeg traff 😄

Kult, fant ut at jeg kan bruke ring.middleware.params for å parse URI params:

(defn app [req]
  (case (:uri req)
    "/greet" {:status 200
              :headers {"Content-Type" "text/plain"}
              :body (greet (get-in req [:params "name"]))}
    {:status 404
     :headers {"Content-Type" "text/plain"}
     :body "Not found."}))

(defn start []
  (stop)
  (reset! server (hk/run-server (wrap-params #'app) {:port 3001})))

Jepp!

Veldig nice faktisk! Jeg ser for meg at app funksjonen kan bli ganske stor etterhvert med flere routes, men det er vel ikke noe problem Men kanskje det er vanlig/lurt å flytte den ut i et eget namespace, eller dele den opp på en måte? :thinking_face:

Det du vanligvis ville gjort var å lage en funksjon for hver case. Denne funksjonen kan ta req som param og returnere en response

jeg er sykt glad i å ha alle “routes” eller endepunkter eller hva man vil kalle det i én og samme fil, så det er kjempelett å greppe etter “hvor er koden som kalles når…. ”

og da gjerne uten nøsting osv Nay:

(context "/api"
  (GET "/foo" ...)
  (GET "/bar" ...))

(context "/user"
  (GET "/:id" ...)
  (GET "/create" ...))

(GET "/api/foo" ...)
(GET "/api/bar" ...)

(GET "/user/:id" ...)
(GET "/user/create" ...)

Var det noe slik du tenkte på, @U04V5VAUN?

(defn greet-handler [name]
  {:status 200
   :headers {"Content-Type" "text/plain"}
   :body (greet name)})

(defn not-found-handler []
  {:status 404
   :headers {"Content-Type" "text/plain"}
   :body "Not found."})

(defn app [req]
  (case (:uri req)
    "/greet" (greet-handler (get-in req [:params "name"]))
    (not-found-handler)))

Jeg ville sendt req. Ellers vet routeren din for mye om hva handlerne trenger.

Videee ville jeg, mår handlerne blir større og mer komplisert, la dem kun gjøre det som trengs for å gå fra http-domenet til forretningsdomenet, og ha egne funksjoner som utfører forretningslogikken uten å være bundet til http

Når du sier "sendt req" mener du at handler-funksjonene bør ta req som parameter? Sånn?

(defn greet-handler [req]
  {:status 200
   :headers {"Content-Type" "text/plain"}
   :body (greet (get-in req [:params "name"]))})

(defn not-found-handler []
  {:status 404
   :headers {"Content-Type" "text/plain"}
   :body "Not found."})

(defn app [req]
  (case (:uri req)
    "/greet" (greet-handler req)
    (not-found-handler)))

Sånn som din greet funksjon er.

Jepp

Ja, skjønner! Det var smartere. Takk igjen for tipset!

Er det forresten god praksis å samle alle handler-funksjonene i et separat/eget handlers-namespace?

Det gjør du etterhvert. Når su ser at du trenger det.

Kult, men da vet jeg i alle fall at jeg ikke er heeelt ute og kjører med tankesettet.

Jeg synes det er viktig å påpeke at din initielle løsning er helt super! Det jeg har påpekt kan være nytting for veien videre. Det er superviktig å få lov til å starte med det enklest mulig, og dele ting opp etterhvert som du set behov for det.

Det som er skikkelig drit er rammeverk som tvinger deg inn i en oppdeling som krever masse arbeid initielt.

Det som er viktig er å skjønne når ting trenger å deles opp, og ta seg tid til å gjøre det da, ikke før, ikke etter.

Enig! Godt poeng. Det er dog svært tilfredsstillende å se server-namespaces så clean:

(ns server
  (:require [org.httpkit.server :as hk]
            [ring.middleware.params :refer [wrap-params]]
            [handlers :as h]))

(defonce server (atom nil))

(defn app [req]
  (case (:uri req)
    "/greet" (h/greet-handler req)
    (h/not-found-handler)))

(defn stop []
  (when-some [s @server]
    (s :timeout 100)
    (reset! server nil)))

(defn start []
  (stop)
  (reset! server (hk/run-server (wrap-params #'app) {:port 3001})))

(defn -main []
  (start))

(comment
  (start)
  (stop))

tenker at man ihvertfall bør være konsekvent. Routeren bør enten kalle funksjoner som får req sendt inn, og returnerer et response i ring-format, eller så bør routeren kalle funksjoner med spesifikke parametere sendt inn, og som returnerer data som ikke har noe med ring-responses og gjøre, som routeren så oversetter til ring

i og med at ring-requests ikke er en type, men bare data, så er det vel liten/ingen grunn til å ha et mapping-lag her (altså gå for førstnevnte)

i Kotlin-boka så tar alle handlers inn data som ikke har noe med Ktor (router-rammeverket) å gjøre, og returnerer en generisk WebResponse som er en klasse man lager selv i boka. Men i Clojure-land så er formatet på ring-requests såpass universelt at man oppnår samme “frikobling” fra router/rammeverk/… om man bare tar inn ring-data direkte

En mental øvelse som jeg ofte gjør er hva om jeg skulle skrive om denne app’en til å ikke være en webapp, hvordan kan jeg skrive den sånn at endringene blir minimale.

Eller om du skulle finne på å bytte ut ring med The next Big thing

Ja, på en måte er det kanskje en nyttig øvelse å gjøre utvikling av web app og CLI (eller en annen type klient) mot samme API samtidig.

hvis man skal ha et sånt lag, altså noe som frikobler deg helt fra ring, så tenker jeg at routeren ikke nødvendigvis er feil sted å gjøre det på. Om man ikke gjør det i routeren, så ender man jo opp med en hel del “boilerplate-aktige” handler-funksjoner hvor alt de gjør er å ta i mot request, sende inn noe data til funksjon, ta data fra funksjon og gjøre om til ring-request. Ofte greit å bare gjøre det in-line i route-definisjonen synes nå jeg ihvertfall 🙂

men om jeg jobbet sammen med @U04V5VAUN ville jeg pratet med ham om det og så gått med på hva nå enn vi kom frem til sammen - ser ikke på dette som noe pattern som man bare må følge, mange veier til Rom, osv

Enig!

i Kotlin-boka så har jeg gjort denne frikoblingen som sagt, men det er fordi de samme handlerene kalles både i serverless lambdaer, i Ktor, i Jooby (et alternativ til Ktor), og i det hele tatt. Der skal faktisk samme kode kjøre i flere settinger

usikker på om future proofing om at ring plutselig forsvinner er viktig. Men, det er jo noe med at man sitter igjen med business-logikk som tar imot data og returnerer data, uten å vite noe om verden rundt, som er vakkert og deilig

(og jeg ser på business-logikk som vet om postgres-spesifikke SQL-er og sånne ting som “uten å vite noe om verden rundt”, det er core for domene-koden spør du meg. Havnet plutselig i det reflekterte hjørnet her jeg sitter)

utrolig spennende å se hvordan dere alle tenker her! > Videee ville jeg, mår handlerne blir større og mer komplisert, la dem kun gjøre det som trengs for å gå fra http-domenet til forretningsdomenet, og ha egne funksjoner som utfører forretningslogikken uten å være bundet til http Merker at jeg blir gira selv — får lyst til å prøve å ha minapp.web med web-ting og ring-requests, og minapp.api eller minapp.problemnavn som tar inn og returnerer idiomatisk clojure-data — som er lett å bruke i REPL og i tester. Har tidligere lagt HTTP-handlers som er litt store og gjør litt mye, føler på at det er litt kjipt å sende {:uri "…", …} inn i app for at den videre skal kalle handlers, og det jeg får ut er html som tekst, ikke data som data.

Nå ble det straks vanskeligere å teste en handler da, fordi jeg må fake en request på et vis! 😅 Jeg gjorde det slik:

(ns server-test
  (:require [clojure.test :refer [deftest is testing]]
            [clojure.string :as str]
            [server :as s]))

(deftest greet-test
  (testing "Greeting includes person's name"
    (is (str/includes?
         (s/app {:uri "/greet" :params {"name" "Leif"}})
         "Hello, Leif!"))))

ville definitivt gjort testingen på hakket etter routeren ja, så :uri ikke har noe med saken å gjøre

Ja, jeg ble litt usikker på om jeg skal/bør teste routeren eller handlerne, eller begge deler.

hvis man først skal teste hva som skjer når man kaller en URL, ville jeg lagt inn et ord for å faktisk spinne opp en server, og bruke en http-klient, osv

ville definitivt gjort testingen på hakket etter routeren ja, så :uri ikke har noe med saken å gjøreSant. Men da får du jo ikke en fullstendig, 100 % riktig Ring-request? Putter du bare inn det du trenger fra map-et da, feks :route-params? (jeg har lurt litt på hva som er vanlig å gjøre for andre folk her)

tenker da at man gjør testingen på funksjonene man har (?) som ikke vet noe om Ring

ville definitivt gjort testingen på hakket etter routeren ja, så :uri ikke har noe med saken å gjøreSå slik, da? Bad:

(ns server-test
  (:require [clojure.test :refer [deftest is testing]]
            [clojure.string :as str]
            [server :as s]))

(deftest greet-test
  (testing "Greeting includes person's name"
    (is (str/includes?
         (s/app {:uri "/greet" :params {"name" "Leif"}})
         "Hello, Leif!"))))

(ns server-test
  (:require [clojure.test :refer [deftest is testing]]
            [clojure.string :as str]
            [handlers :as h]))

(deftest greet-test
  (testing "Greeting includes person's name"
    (is (str/includes?
         (:body (h/greet {:params {"name" "Leif"}}))
         "Hello, Leif!"))))

ja. (hvis jeg forstår August rett)

Teodor er en god August. Jeg kan endelig trekke meg tilbake og la tingene gå sin gang her i denne tråden

Det som er fint er at en ring request er bare data, så det er ganske trivielt å mekke en passende request, i motsetning til i Javaland hvor du må til med en MockHttpServletRequest eller deromkring. Når det er sagt, kommer ring med helpers for å generere mock requests https://github.com/ring-clojure/ring-mock

Jeg bruker biblioteket Sluj: https://github.com/rawleyfowler/sluj

(require '[sluj.core :as sluj])
=> nil
(sluj/sluj "æøå")
=> "aoa"

Takk!

Skjønner. Takk!!

Altså, kun å av de. Det der tar også unna tødler, tider og masse annen bokstavpønt 😊

Jeg ble egentlig skikkelig positivt overrasket av at dette på sett og vis er løst i Unicode. Jeg trodde jeg måtte finne et bibliotek som støttet URL-normalisering på en rekke språk, der norsk er støttet. Hadde ikke hørt om "diakrtitske tegn" før i dag!