This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-08-26
Channels
- # announcements (1)
- # beginners (42)
- # biff (11)
- # calva (15)
- # cider (3)
- # clj-http-lite (3)
- # clojure (52)
- # clojure-europe (16)
- # clojure-nl (1)
- # clojure-norway (39)
- # clojure-uk (4)
- # clojurescript (52)
- # code-reviews (13)
- # conjure (1)
- # cursive (4)
- # data-science (1)
- # datomic (5)
- # emacs (6)
- # events (3)
- # graalvm (5)
- # hyperfiddle (7)
- # kaocha (14)
- # lsp (11)
- # malli (3)
- # nbb (13)
- # off-topic (87)
- # pathom (15)
- # polylith (23)
- # portal (5)
- # reitit (4)
- # shadow-cljs (110)
- # squint (114)
- # testing (1)
- # vim (13)
God morgen, ja 😊 Her er Episode 26: Max Payne https://www.zombieclj.no/s02e26.html
For å være ærlig så har vi laaang jul her i huset også, men det passet ikke så bra med narrativet her. 😅
I dagens episode hadde det vel vært fint med et typesystem, idet health
gikk fra å være int
til {:current int, :max int}
?
Uansett, poenget med å fordumme klienten er jo helt konge. Isteden for at klienten må være smart (og deale med tall og greier), så endte dere med at klienten bare looper over noe data, og ferdig.
Veldig fint når man klarer å finne en så ren arbeidsfordeling. Serveren er smart, klienten er dum. Når det blir “kode” på klienten så er noe gæernt.
Det er forøvrig en interresant påstand. Hos oss er vi helt klart delt i frontend og backend utviklere, selvom noen av oss er full stack. Historisk så er frontenden skrevet med Backbone, hvilket betyr at backenden startet som en relativt dum database med et forferdelig spørrespråk, REST.
Vi ser at vi “hele tiden” debaterer om hvor mye logikk som skal ligge på frontend vs backend, hvor skreddersydde endepunktene skal være for de operasjoner som gjøres, eks. PUT /api/user
vs POST /api/user/reset-password
Det er også et spm om hvem som skal sørge for denormalisering av data, om det gjøres på frontend eller backend.
Våger meg på en påstand til da: Det er lettere å håndheve en god arbeidsfordeling mellom frontend og backend når de samme folka har tilgang på begge steder. Kjør debatt!
Jeg tenker at det er lettere å ta gode valg på kodens vegne om det ikke også legger føringer for hvem som må gjøre jobben (og hvorvidt de er tilgjengelige, osv)
Et frontend-team og et backend-team skaper en illusjon om et skarpt skille, som i praksis er en stor gråsone. Det er noen ting som helt klart er “ren frontend”: designrammeverk, tilstandsløse komponenter, og lignende. Og så er det “ren backend”: persistering, integrasjoner osv. Men dataflyt foregår på begge sider av skillelinja. Det er lettere å lage god dataflyt om man ser på helheten, heller enn halve jobben på hver side av en mer eller mindre arbitrær grense.
Jeg syns ihvertfall at det er mye morsommere å jobbe i web-prosjekter som ikke har denne delingen, for man kan se løsningen mer under ett, og jeg opplever at mye av tiden min brukes “i midten” der, hvor ting kan være både frontend og backend, men hvor kontekst, gjeldende arkitektur, eksterne krav osv tipper balansen den ene veien eller andre.
Utrolig kjedelig å vente på en bestilling som aldri fullføres. I mine øyne så er fordelingen back-end/front-end helt meningsløs når man har Clojure som kan leve på begge sider
For å sette det på spissen: Tenk om backend-teamet måtte koordinere med et database-team for å få skrevet spørringer. Det er jo ulike språk! (SQL, Datalog osv.) Og koden kjører på en annen maskin! På en helt annet “stack”! Det blir jo absurd. Men det er den slags tankegang som synes å styre den utbredte oppdelingen i frontend og backend. Det er et skille som er trukket opp tvers over HTTP-protokollen og på tvers av hensynet til brukerne (de bryr seg ikke nødvendigvis om hvor koden kjører og hvilket språk den er skrevet i).
Noen steder med frontend-team har jeg sett at de med hell har tatt kontroll over “sin” del av backenden ved å lage en egen web-backend (BFF - Backend For Frontend). Denne kan ha ansvar for web-greier, autentisering og den slags, og delegere til den “ekte” backenden for forretningslogikk.
var på et prosjekt hvor vi hadde teams for frontend/backend separert. Men det handlet mere om hvem som var i møter og hvem som var pådrivere osv. Når vi på frontend/app trengte noe nytt i backend, lagde vi det sjæl
@msolli BFF åpner for å ta bedre avgjørelser for en større del av kodebasen, men i byttet mot enda en HTTP-vegg 😅 Det blir bedre, men fortsatt vil det være ting som må “bestilles”, og Conway lever videre
Absolutt - det var mer en observasjon jeg har gjort meg for noe som har fungert når man ikke kan, i hvert fall på kort sikt, ta kontroll over hele “verdikjeden”. Og så kommer det jo an på hvor ofte ting endrer seg i forretningen. Jo flere endringer, jo viktigere at ett team har kontroll på alt sammen.
jeg har jobbet i systemer med mye fysikk-basert forretningslogikk som jeg ikke nødvendigvis skjønner eller bryr meg så mye om. denne foregikk på en annen server og/eller prosess enn min web-backend, hvor jeg hadde kontroll på stacken frem til og med grensesnittet imot "alle de der ligningene", som noen andre jobbet med. det var egentlig fullstendig problemfritt.
hehe, gitt at kommunikasjonen mellom partene er god nok så er det Conway's lov i praksis det. når jeg tenker tilbake, hadde vi god kommunikasjon. selv om "fysikerne" etterhvert ble mer programmeringskyndige og klødde seg inn i kodebasene jeg satt med, gikk det også greit for det meste.
godt poeng! Conway’s lov adresserer jo spesifikt kommunikasjonshierarkiet, ikke beslutningshierarkiet
Hvis kompetanseskillet "noen kan frontend, andre kan backend" er problematisk, finnes det bedre måter å dele inn kompetanse? Som ikke antar at man trenger å kunne alt? Jeg har sett inndeling etter backend / frontend og inndeling etter "slice av produktet", men jeg har ikke sett noen andre måter å gjøre det på.
Jeg forstår egentlig ikke den tankegangen at man jobber på backend og ikke gidder å lære seg litt frontend. Da håper jeg de jobber med noe ekstremt kompleks, som et operativ system, relational database, osv. Men hvis man har ekstremt god kommunikasjon og sammarbeid med noen som kan det går det sikkert fint. Det blir kanskje også litt mere gøy enn å gjøre hele featuren selv.