Det var veldig koselig bilde, da 😊

Absolutt 😊

Det var deilig lesning for en stakkar som i den siste tiden har sittet og oppgradert tjenester fra .NET 3.1 → .NET 6, vel vitende om at, så fort jeg er ferdig med alle tjenestene, kommer det en ny LTS release av .NET, så starter reisen på nytt. Recurrere ad infinitum.

I mitt stille sinn tenker jeg at bakoverkompatibilitet ala Rich er lettere å gjennomføre i Clojure enn i feks ts/js. Men det handler kanskje mer om idiomer enn språk. Hvis man kun trenger noen keys, bruk kun noen keys. Ikke krasj når det kommer nye. Men da må man også vite når man bør bruke select-keys.

Halve teamet sitter og oppgraderer rammeverk og andre deps kontinuerlig mellom andre oppgaver. Det tar mye tid. Det er en stor ulempe med å ha ~400 mikrotjenester.

@U3X7174KS Jeg tror det er veldig gjennomførbart i mange flere miljøer. Men klart, et sterkere typesystem gjør dette vanskeligere å få til - men også noe lettere å håndtere, ettersom kompilatoren kan guide deg gjennom type-endringer. Men det er fortsatt mulig å legge til ting, ikke ta bort ting, osv. Løsningsforslagene i blogginnlegget fungerer i alle språk.

Hvis man bruker "destructure everything or crash" får man vel problemer en ny attributt legges til. Men da er kanskje svaret ditt. OK, da er å legge til en ting en breaking change. Da beholder du det gamle API-et, markerer det som deprekert, skriver om docs, og lager et nytt API ved siden. :thinking_face: Det skjer litt rubber-ducking her. Enig!

"Accretion only, please. Only add, never change or delete."

Hva i all verden er argumentene for "destructure everything or crash" ?

Jeg mener ikke at å legge til ting er en breaking change @U3X7174KS

Fun fact: Erlang/OTP (og Elixir) miljøet har et slagord "Let It Crash!" (som ofte er misforstått).

@U07FCNURX jeg argumenterer ikke for at "destructure everything or crash" er lurt - men det finnes syntax for det i enkelte språk. Og den brukes. Feks Haskell: http://learnyouahaskell.com/making-our-own-types-and-typeclasses Surface-funksjonen vil krasje hvis det legges til et ekstra felt på Circle.

Skjønner

Ja, da har dogmatismen tatt overhånd mener nå jeg 😅

Det må kanskje til for at kompilatoren skal kunne levere på garantiene den har gitt? 🤷 Men i så fall ville jeg si at man må i større grad shippe nye funksjoner og typer for å innfri på idealet mitt.

Men nei, det fremstår ikke direkte pragmatisk

Deprekering ..Måtte lese to ganger for å skjønne hva dette ordet var, men det er kanskje allerede endel brukt? 😅 “deprecate” - to pray away https://www.etymonline.com/search?q=deprecate “Be bort”, “ønske vekk”? - Hadde vært gøy med et norsk uttrykk som fanget at vi skal ikke fjerne dette, men vi skulle ønske vi kunne fjerne det.

Ja, beklager den, litt grell fornorskning

Enig, vi burde ha et godt etablert norsk begrep for det 🙂

Jeg liker egentlig pensjonert ganske godt. Det beskriver ikke bare at funksjonen ikke er i arbeid, men også at den har vært nyttig en gang i tiden og at det sannsynligvis finnes en arvtager.

Jeg har likt tanken på å returnere informasjon om hva som ble rettet på, men ikke funnet mediet. Men, en ekstra header på responsen kan bære en mulighet.

Hvorfor ikke bare ha det i body?

Fordi vi allerede for lenge siden har definert returverdien.

men hvis returverdien er et map…. 😇 (Apropos: i de siste årene har jeg begynt å pakke nesten alle returverdier fra API-er inn i maps, nettopp så jeg kan legge til flere ting senere uten å brekke callers)

De er jo det, men: POST /api/user returnerer idag et map som representerer en user. Det synes uelegant å legge til nye attributter som ikke hører til user i det map’et. Vi har litt det samme problemet med GET /api/user som returnerer alle users. Det var sikkert fint den gangen man hadde tre av dem, men det hadde vært fint å gjort det med paginering når man får fler. Det er vanskelig å bolte på det i ettertid.

enig - captain hindsight sier at man kunne returnert {user: {...}} , føles ofte litt overkill i nåtiden, men har aldri angret på det i ettertiden

Skjønner @slipset

Jeg vet ikke hvor mange ganger jeg har returnert en liste fra et API for litt senere å angre bittert på akkurat det

Så det har jeg slutta med

Mulig det hører til å i samme kategori at man alltid bør ha en "envelope" rundt maps også, som @augustl foreslår

Det er vel også min logikk, men det er edgecaser som man kan ønske å plukke opp.

Eksempler?

Si at du har et endepunkt som tar noe som tilfredsstiller denne spec’en:

(s/def ::data (s/keys :req-un [::foo] :opt-un [::bar]))

{:foo 1 :bae 2}

Ja, den er litt kinkig

Kanskje en mulighet kunne være å ha et strengt validerings-endepunkt? Altså en opt-in streng sjekk. Vet ikke om det har noe for seg egentlig.

Ulempen med den konteksten er at nå finnes ikke strengen "/html-demo/button/clicked" noe sted i rutene din lengre

Ja, det er et godt poeng.

Ikke et kjempeproblem i den størrelsesordenen der, men gi det litt tid, så har det vokst og deler av rutene er flytta ut i egne filer osv. Da kan det bli litt krøkkete.

Ikke nødvendigvis bare dårlig altså, men greit å ha i bakhodet.

Noen av dem finnes i content namespace:

(def htmx-demo-button
  [:section.section
   [:div.container
    [:h1.title "HTMX Demo"]
    [:button.button {:hx-post "/htmx-demo/button/clicked"
                     :hx-swap "outerHTML"}
     "Click Me!"]]])

Men ett nivå opp, typ /htmx-demo/button, finnes ikke som en streng noe sted.

Jeg korrigerte fra "koden" til "rutene" 😅

Og det er litt irriterende å måtte se på routeren og tenke ut strukturen for å skrive inn den strengen i hx-post.

Ja, du må bygge den i hodet

Indeed.

Kanskje dette ikke var så nyttig allikevel 😅

Jeg tenker at dersom det kun er for å klippe opp URL-en er det ikke verdt det, men dersom du vil bruke konteksten til å ha autentisering på et sett med ruter eller lignende kan det være verdt det. Men dette er litt det jeg snakket om da jeg nevnte at jeg syns routing-biblioteker har det med å bli for clever. Det er veldig lett å legge litt for mye funksjonalitet inn der som kanskje hører bedre hjemme andre steder.

Interessant trade-off egentlig: mer logisk strukturerte/penere paths vs. enklere å lese/jobbe med koden.

Jeg var veldig glad i sånt før, men etter å ha slitt med å finne igjen ting i sånn kode litt for mange ganger har jeg lært meg å sette mer og mer pris på å optimalisere for at koden skal leses når jeg har glemt alle de gode idéene jeg hadde da jeg skrev den.

skal sies at man også kan bruke context (mulig den heter noe annet?) men uten en path, for å wrappe en gruppe routes i autentisering osv

min erfaring og er at det på sett og vis blir like srukturert å ha alle rutene som starter med “/foo” samme sted i fila, så lenge man har nok disiplin til å vedlikeholde det