Hvilken dag er det i dag? hvilken dag er det idag? Er det zombie-dag? Ja!

Braaaaaaains morgen!

God morgen, ja 😊 Her er Episode 26: Max Payne https://www.zombieclj.no/s02e26.html

Brå slutt på jula

Som seg hør og bør. Andre juledag er det på hue og rævva ut med juletre og nisser. 😅

og inn med klassiske finske skytespill

I dagens episode hadde det vel vært fint med et typesystem, idet health gikk fra å være int til {:current int, :max int}?

tja, hvor mange minutter hadde vi spart på det? hvor mange minutter tapt?

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 deilig konsept!

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)

Velkommen til Conway's law 🙂

Allé har tilgang, men ikke alle har viljen.

Og, vi har videre forsterket Conway ved å ha forskjellige språk foran og bak.

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.

Ikke uenig.

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

er man bundet av legacy og andre språk, så har jeg noe mer forståelse

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.

Jepp

Og det er helt klart bedre enn et helt strikt skille

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.

noen ganger jobber Conway’s lov til vår fordel 🙂

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.