Hyggeligere å ta det her. 😊

Jeg pleier be Optimus skrive optimaliserte assets til disk for mine statiske nettsider.

Den bruker da optimus.export/save-assets

Jeg kjenner til optimus.export/save-assets, den er fin. Da kan jeg pakke disse filene i uberjaren. Men så, på andre siden, når appen skal starte, så trenger middlewaren å få vite om disse assetene.

Kan du ikke da bare servere de as-is fra resources?

Du tenker kanskje på å få på lange expires headers og sånt. Det gjør jo jeg da med nginx-konfig.

Skulle gjerne brukt de fine hjelperne, ja.

Høres ut som man må eksportere en slags manifest-fil som inneholder metadataene om assetene.

Ja, det er så langt jeg har kommet, men så stanger jeg på binære assets: de med :resource.

Hvis du eksporterer, så ligger jo alle som resources

Et øyeblikk, straks tilbake.

Det gjør de, men verdien til en :resource er en java.io-dings. Så ikke "rene" data. Kan altså ikke bare spit/slurp-e en slik manifest.edn-fil.

Men kan alltids rekonstruere objektene etter lesing, da.

:resource #object[java.net.URL 0x66601b05 "file:/Users/martin/c/foo/bar/image.gif" - sånn ser det ut.

Her er mitt forslag.

Det blir litt pseudo-kode, for jeg husker ikke alle detaljene.

Ved bygg:

(defn export-assets []
  (let [assets (optimize (get-assets ,,,))]
    (optimus.export/save-assets assets export-directory)
    (spit "assets-manifest.edn" (for [asset assets]
                                  (dissoc asset :content :resource)))))

(defn get-prod-assets []
  (for [asset (slurp "assets-manifest.edn")]
    (assoc asset :resource (io/resource (:uri asset)))))

Da lagrer du alle metadata om alle assets, men fjerne innholdet (som du lagrer på disk)

ved oppstart, så hydrater du assetene fra manifest + resources på disk

Hehe, dreiv akkurat å skrev noe sånt!

Fin-fint. Det funker, tror jeg.

Herlig! Hold meg oppdatert 🙂

Skal prøve litt nå - kanskje du vil ha noe til en liten seksjon in README-en om dette hvis det virker?

Ja, hadde vært supert 😚 🤌

Foreløpige resultater er veldig gode. Har barbert gode 20 sekunder av oppstartstiden på en app her. Skriver mer i morra neste uke!

Husk også at du kan bruke var-quota funksjoner i mappet ditt, slik at den nyeste versjonen blir brukt, selv uten å re-evaluere mappet.

Jeg har gjort det samme selv noen ganger - først skrevet en makro, så funnet ut at jeg like gjerne kunne brukt en funksjon. Funksjon+annen datastruktur kan noen ganger gi det samme som en makro, med færre overraskelser enn det en makro gir.

Har aldri hatt noe behov for var-quoting før. Visste ikke at en funksjonsreferanse kunne kalles direkte uten å derefereres. Burde kanskje lese litt mer av Java-kildekoden til Clojure en gang. Fra Var:

public final IFn fn() {
        return (IFn)this.deref();
    }

    public Object call() {
        return this.invoke();
    }

Ja, det er ganske praktisk!

En fordel med å ha en funksjon og et atom er at om jeg skal legge til nye handlere (handlere er gruppert i forskjellige navnerom for de forskjellige APIene de kaller videre på), så blir de nye handlerne registrert med en gang. Hmm, må tenke litt på hva som er mest praktisk. Liker å slippe å bruke tilstand om jeg kan det.

Bruker en merge på toppnivå i dag for å slå sammen maps fra hvert navnerom, men kunne jo lagt alle på toppnivå. Synes bare at den store mappen blir litt rotete.

Legger du til nye handlere runtime, eller bare når du jobber med koden?

Bare når jeg jobber med koden. Så det har ikke noe å si i produksjonsmiljøet.

Da ville jeg nok gått for def og alter-var-root, https://clojuredocs.org/clojure.core/alter-var-root

Jeg vil bare ha litt bedre ergonomi når jeg jobber med koden, så jeg slipper å reloade et ekstra navnerom. Også kjent som latskap.

Med var-quoted funksjonsreferanser som magnar foreslår (`#'handler`)

Jeg har pleid å gjøre noe sånt:

;; Et sentralt register for handlere:

(ns my-app.handlers)

(defonce handlers (atom {}))

(defn defhandler [id params]
  ;; bra plass for validering av params
  (swap! handlers assoc id params))

(defn by-id [id]
  (get @handlers id))

;; Hver handler kan da registrere seg selv:

(ns my-app.handlers.foo-handler
  (:require [my-app.handlers :refer [defpage]]))

(defn handle [,,,] ,,,)

(defhandler :foo-handler
  {:param 1
   :infos 2
   :fn #'handle})

;; Og så må alt dras inn en plass

(ns my-app.the-handlers
  (:require '[my-app.handlers.foo-handler]))

Da kan de som trenger finne en handler gjøre (my-app.handlers/by-id :foo-handler)

Det blir en ja-takk-begge-deler-versjon. Da får man registreringen gjort på samme plass som definisjonen, som er det jeg liker med atom-varianten, og den registrerer seg i registeret med en referanse, så man kan endre funksjonen i REPL uten å swappe den inn på nytt.

Endte opp med å bare bruke var-quote og et namespace som bare inneholder registeret, med grupperinger av handlere som merges sammen i samme fil:

(ns my-app.handler-registry
  (:require [my-app.services.ns1 :as ns1]
            ...)

(def ns1-handlers
  {:ns1/handler1 #'ns1/handler1
   ...})

(def handlers
  (merge
    ns1-handlers
    ...))

Det er ikke alltid en-til-en i navngivning mellom funksjoner og IDer.