[00:00:00] Madde: Det blev mycket lättare för dem att kunna optimera API-na för just då typ Xbox-appen eller för iOS-appen. Tack vare det så kunde ju varje team ta ansvar för helheten hela vägen från UI till API-t och slipper vänta på det här backend-teamet som ska råda ihop någonting och de kanske inte ens förstår hela användarflödet för just en API För hur det funkar på Xboxen jämfört med hur det funkar på desktopen till exempel.

[00:00:35] Sofia: Du lyssnar på Developers podden där du får följa med oss Sofia och Madde på allt inom mjukvaruutveckling.

[00:00:42] Madde: Vi träffar spännande gäster, testar nya teknologier, söker inspiration och tar upp aktuella ämnen. Vi hade ju en liten cliffhanger när vi pratade om API Gateways, om BFFs Best Friends Forever. Så vi tänkte att vi bränner på det direkt liksom.

[00:01:03] Sofia: Ja, men först ska vi tacka våra stjärnsupportrar på Patreon såklart Så tack till Alicia, Anders Nylund, Björn Jonsson, brother, Dag Rönnell, Kajetan Kazimierczak, Lars Nyström, Martin Haagen, Molly Haglund, Oskari, Per Nåtby, Selim Hjorthall, Stygg Hest och Tomas Nilsson

[00:01:23] Madde: Ja, stort tack till alla er och tack till alla som stöttar oss på ett eller annat sätt.

Det uppskattar vi supermycket.

[00:01:31] Sofia: Så idag ska vi fokusera på BFF som ärende Inte stå för best friends forever. Sorry. Back and for front end. Minst lika roligt. Som du sa, vi hade en liten teaser om det i API Gateway-avsnittet. För att det är en version av API Gateway. Men den här API Gateway är kanske lite smalare och lite annat koncept.

Men det är snarlika tankar i det om man skulle zooma ut och titta. I alla fall väldigt långt uppifrån. Men det tycker jag är kul att prata om var det kommer ifrån. För alla de här patternsen kommer ju från någon typ av känd arkitekt eller något företag ofta. Så det här konceptet är ganska nytt. Och det myntades av Sam Newman i en bloggpost från...

2015 som vi kommer att länka till och Sam Newman han är en känd arkitekt författare talare och han jobbade över 10 år hos ThoughtWorks

[00:02:41] Madde: Mm,

[00:02:41] Sofia: ja

[00:02:42] Madde: ThoughtWorks är ett sånt coolt företag ändå som jag vet inte, jag tror många känner till det, eller i alla fall om man jobbar i konsultbranschen för det känns som att många konsultbolag har försökt modellera sig efter ThoughtWorks och vill liksom vara lite som dem.

[00:02:57] Sofia: Ja, eller de jobbat ett tag. Överhuvudtaget så tror jag man har hört

[00:03:01] Madde: om

[00:03:01] Sofia: det. Men

[00:03:01] Madde: det har inte alla

[00:03:02] Sofia: som har gjort det.

[00:03:03] Madde: Nej om man inte har gjort det så kan vi berätta lite om det. Men som sagt, det är ett konsultbolag som globalt finns över hela världen och de är väldigt inflytelserika i techbranschen och har som sagt haft mycket påverkan på hur olika team jobbar idag.

De var väldigt med och drev liksom agila rörelsen tidigt när det började komma och Det är sjukt många kända namn som har jobbat där. Martin Fowler som är både arkitekt författare, bloggare. Jess Humble som skrev boken Continuous Delivery. De har varit med och hjälpt till att forma hela konceptet kring Continuous Integration och Continuous Delivery och DevOps och allt sånt till vad det är idag.

Så kommer därifrån. Mm,

[00:03:50] Sofia: jag tror att om det är någonting som folk har känt igen så är det Technology Radar. Och det någonting som kommer från ThoughtWorks Många företag speciellt stora företag har ju en egen typ av Technology Radar. Och Technology Radar är där man, det är liksom en så här En cirkel där man rankar tekniker verktyg och metoder i fyra kategorier och då är det som är närmast längst in i cirkeln saker som man ska adopt och sen längre ut så kommer trial och sen finns det assess och längst ut har du hold.

Och ThoughtWorks egna Technology Radar är väldigt respekterad och välkänd och den används av CTOer, arkitekter och alla möjliga utvecklare globalt. Fun fact, de har i sin metodkategori så såg just nu att det här Ja, inom kaninöron Agila säger framverket, det ligger i kategorin hold, och då var det lite kul man kan gå in och läsa liksom varför är det på hold och då hade de skrivit just det, och hold betyder typ såhär proceed with caution och de säger just såhär skapar silos och massa saker som vi har försökt kanske uttrycka själva genom åren och Ja, är inte sant.

Ja, så det var kul. Men så, med det sagt, varför behövs ett back-end for front-end? Det finns ett jättekort svar som är typ att en jättestor gemensam back-end den passar inte Någon konsument riktigt bra. Det kommer alltid bli kompromisser. Men det hade varit tråkigt att avsluta avsnittet här. Det blivit väldigt kort.

Ja. Men vi kan backa bandet lite. För det här mönstret uppstod inte bara så här utom att någon bara sa nej men en stor backhand är inte bra. Utan Sam Newman han beskrev det här i en bloggpost från 2015. Och det började Som ett sätt att hantera problemet när du har många olika typer av klienter. Så typ en mobilapp, du har en hemsida, du kanske har ett API för tredjepartsintegration, du har en smartwatch.

Och han såg liksom att man ofta försökte ha en enda backend som skulle vara till för alla de här typerna av klienter

[00:06:40] Madde: Ja, precis. Det blir ju då, antingen skickar du alldeles för mycket data till vissa klienter. Typ en smartwatch som har väldigt begränsad funktionalitet, den behöver ju verkligen inte all data.

Eller så blir det att man istället skickar för lite så får det stackars frontend-teamet sitta där och försöka pussla ihop från tre olika API-er och få ihop det till vad de behöver ha. Så att frontend-teamen de behövde antingen... Som sagt då slå ihop det från flera olika API-er eller få en så här gigantisk generisk payload som de ska tolka och ibland till och med lösa viss affärslogik frontenden och så ska man lösa den på en massa olika ställen och sånt.

Så det som Sam då föreslog var istället, vad händer om varje klient får sin egen backend, en backend for frontend som är skräddarsydd för just det behovet?

[00:07:31] Sofia: Mm, det var inte så dumt kanske, men med det sagt, det är ofta så här man börjar med en back-end, så det är inte ofta man vet att vi kommer ha en smartwatch och vad kommer det för device om tio år liksom, men i alla fall den här back-end for front-enden, Den vet exakt vad till exempel mobilen behöver, den vet exakt vad klockan behöver och den slår ihop datan och levererar det i ett slimmat eller lagom stort payload tillbaka till klienten.

Så det innebär att logiken kommer ändå hamna mer där den hör hemma Så fronten den slipper ha massa affärslogik, typ tar emot jättestora datamängden och teamen blir på det här sättet mer autonoma. De behöver inte gå till teamet som äger den här stora backend-tjänsten som Sitter på all data och ber dem skapa specialkriser hela tiden.

Ja, det är en

[00:08:39] Madde: stor vinst.

[00:08:41] Sofia: Ja, och jag känner i alla fall absolut igen det här. Nu är det inte alltid att man är nära ett back-end. Man har inte alltid tillgång till de här back-end-teamen som har API-erna på ett företag Och jag känner verkligen igen att man får skriva ett mejl till någon typ för dig i alla fall.

Och be dem exponera någonting mer. Jag tror att du också gör det va? Ja, jag har absolut varit med om det. Ja, så att det Sam pekar på är att de här back and for fronterna. De passar ofta också ihop med teamtopologier. Alltså att ett team som äger frontenden. Också kan äga sin back-end och då får du kortare feedback-looper som vi har nämnt här, men du kan också du kan ju deploya i din egen takt också så ja jag tänker det är lite lättare att förstå om vi kanske nämner några företag som faktiskt gör så här, alltså använder back-end for front-end På riktigt Så blir det lite lättare att förstå.

På riktigt.

[00:09:49] Madde: Det finns ju massa exempel såklart. Ett av de kanske mest kända Är ju Netflix. Och jag tror det är ett ganska bra exempel också. För att de har ju så himla många olika. Klienter. Du har ju Netflix på din mobil. På din Ipad. Eller sursplatta. Du har det som en webapp. Jag har en Netflix-app på min Samsung-TV.

Sen finns det ju en Netflix-app på Playstation. Och det finns alla. Xbox. Precis. Och alla har ju olika behov. Så... Från början så hade ju alla en gemensam back-end. Men ganska snabbt så blev det lite ohållbart. Så då började Netflix införa BFF-er. Små back-ends då som varje team ägde själv. Så det blev mycket lättare för dem att kunna optimera API-erna för just då typ Xbox-appen eller för iOS-appen.

Så... Tack vare det så kunde ju varje team ta ansvar för helheten hela vägen från UI till API och slippa vänta på det här backend-teamet som ska råda ihop någonting och de kanske inte ens förstår hela användarflödet för just hur det funkar på Xboxen jämfört med hur det funkar på desktopen till exempel Mm.

Det är ju annars rätt typiskt att man har en klient som behöver anropa massa olika tjänster och pussla ihop datorn för att få det man behöver. Eller att man tycker att det blir för mycket och bara ber back-end-teamet som tillhandahåller API-et att göra ändringar hela tiden. Och det tar ju sjukt lång tid.

Alltså om du ska sitta och vänta. Särskilt om man då kör typ safe till exempel som du nämnde som någonting man inte vill göra så... Det kan ju ta jättelång tid. Alltså nej det vill vi göra om sju sprintar liksom. Visst det är väl en sak att bara be back-end-teamet att bara exponera lite mer data kanske.

Det kanske är lätt för dem. Men det är ju en helt annan sak att komma till dem och bara du skulle du kunna ändra den här business-logiken som gör att det går att filtrera för att det ska vara lättare att visa i vårt UI. Alltså det blir så här. Jaha, men hur många andra påverkar det liksom? Så det kan bli väldigt ohållbart i längden och jätterörigt för dem också för den delen.

[00:12:10] Sofia: Ja, jag tycker jag har varit med så många gånger om att typ även om de bara ska exponera till property. Nu är det ändå så här legit case att man bara ska exponera mer data men att de typ så här Man har inte varit tillräckligt tydlig med vad de ska döpa det till. Man vill ju gärna ha rätt och mänspråk Och så har de döpt det till någonting dåligt.

Och så ber man dem döpa om det. Man är aldrig klar. Men som du säger, när man ber dem just det på. Business, logik. Eller kan ni leverera mindre mängd för att vi har en klocka. Det blir så mycket för dem att maintaina till slut om de har många klienter Ja,

[00:12:55] Madde: och det går ju typ inte att hålla det om du nu bygger ett REST-API.

Det går ju inte att hålla det RESTfull om du ska ha Get Products eller Get Movies om vi tar Netflix-exemplet. Ja, men ska de ha 15 olika versioner av den? Det blir jättekonstigt.

[00:13:13] Sofia: Ja, och det är lite där vi pratade om Gateway. Där kan Gateway komma in. Och göra omsvaren. Det blir lite som en back and for fronten.

Men det är inte helt samma sak ändå. Du kanske inte vill ha affärslogik i din gateway heller.

[00:13:29] Madde: Men

[00:13:29] Sofia: det finns massvis med exempel. Alltså det är Zalando, Spotify har det också. Och har skrivit om det på sina bloggar. De är lite mer... De är lite mer svåra att förklara tycker jag, men det är jätteintressant att läsa om, typ Zalando's arkitektur.

Men ja, så vi har fortfarande kvar då massa tjänster om vi tänker att det här är ett stort företag som har de här generella API-erna kvar. Det finns massa backends som har liksom... Kärndatan och kärnappierna och så säger vi att de exponerar dem via någon gateway-typ. Men i och med att vi har de här också små backend-for-frontends så betyder att vi låter aldrig webb eller javascript-kredenter prata direkt med de här stora kärnbackendsarna.

Och det är det här som är Det är lite finare med det här mönstret. Någonting som jag själv har insett lite senare själv. Det är att vi kan börja prata back-end till back-end. Och just slippa webbläsaren överhuvudtaget. Och det här blir ju en stor säkerhetsvinst. För att du kan göra saker som kräver autentisering mellan back-ends.

Så om du till exempel har en token- Och du pratar med många olika API'er som har olika typer av autentiseringar och tokens du behöver skicka så är det ingenting du behöver sköta i webbläsaren alls när det sköts de har liksom bara webbläsaren och din backend har bara kommunikation mellan varandra så att det är någonting man kan ta med sig som är en stor vinst med BFF-mönstret

[00:15:24] Madde: Men det löser väl egentligen en API-gateway också?

[00:15:28] Sofia: Det gör det också, men ibland har du ändå så saker som du skulle vilja ha en backend till backend till, där du liksom just har backend-komponenter som du kan dra in, vilket du inte får på en webbläsare.

[00:15:42] Madde: Mm. Ja det är klart Det är nice. Men ja, det finns ju nedsidor också, såklart. Kommer här? Jävlandsadvokat.

Du bara älskar BFFs kommentarer Ja, men vad är de stora då? Liksom Ja men samma som API Gateway, till exempel då att det introducerar ju mer latens i systemen, alltså du får ju plötsligt en extra backen du ska hoppa mellan, så det tar ju längre tid för requesten, men samtidigt så oftast märks det inte, för ofta så har man ju deployat både BFFen och BFFen Liksom den generella back-end-tjänsten i samma datacenter.

Så att det är inte så att ett androp går från Singapore till liksom Haparanda.

[00:16:35] Sofia: Nej, nu får du ju trist. Jag håller med dig. Jag tror att vissa kan ha det som något slags argument. Men det är liksom försumbart.

[00:16:46] Madde: Ja, men sen något annat skulle kunna vara... Om man tänker på teamen då, de teamen som traditionellt sett har varit väldigt frontend-fokuserade behöver ju plötsligt nu kunna mer om backend.

Och visst en erfaren frontend-utvecklare kan ju skriva en backend, men när den börjar växa och bli större och större så krävs det ändå att man har... Erfarenhet av att vara verkenutvecklare sen är det ju såhär, ja visst du kan ju bygga dig en node till exempel och det är ändå liksom javascript men ja, det är kanske inte för alla man ska ju fortfarande skriva bra kod Nej

[00:17:25] Sofia: det

[00:17:26] Madde: här

[00:17:27] Sofia: är väl såhär den största nedsidan, eller uppsida alltså, absolut det är en uppsida att ditt team blir mer autonomt men jag tycker den här är svår för att Det här kan ju bli en enorm kostnad för företagen.

Eller så blir det inte det. Jag vet inte, vad jag menar. När man har centraliserat backenden i de här teamen Som sitter och försöker tolka krav från alla möjliga klienter. Så märker man att det skapar mycket buggar. De får en helt ohantelig jättestor kodbas. Det här stora back-end-teamet, de får fler och fler mikrotjänster, kanske.

De börjar själva splitta upp. Och då säger man istället så här, nej låt oss ha sådana här vertikala team som äger sin front-end, sin egen back-end. Och, ja... Det är svårt att veta vad som är bäst tycker jag. Just nu vet jag att det moderna är att ha vertikala produktteam som äger mer. Ja, och till och med kösa microfrontends och sånt också.

Ja, så det här är någonting... Jag vet inte, det är en kostnad man behöver tänka på. Som jag tycker är jättesvår att... Jag tänker på det i alla fall själv i mitt egna team där det är ett vertikalt team som ska äga en stor slice av det här hela. Men hur vet man att man tar rätt beslut och inte att det bara är så här, det här är det moderna sättet som vi går på 2015 och sen kommer vi igen gå tillbaka till att inte göra så här.

[00:19:16] Madde: Går det inte alltid lite i cykler också alltså om man hör på folk som har jobbat riktigt länge i branschen så säger de ju alltid att det har gått fram och tillbaka och jag tycker dessutom att man börjar se mer och mer trender mot monoliter igen och helt ärligt så föredrar jag alltså monoliter framför microservices egentligen, så länge de är typ modulärt byggda och liksom med bra vettig arkitektur så tycker inte jag att det behöver vara en nackdel alls att bygga en monolit Det är ett

[00:19:46] Sofia: Nej jag tycker väl att monoliter är fine, men det är det när monoliten själv växer,

[00:19:56] Madde: det

[00:19:58] Sofia: är väldigt svårt för det här teamet som ska anpassa sig efter varje konsument, det kanske är lätt när det är interna konsumenter visst det är verkligen din mobilapp, din klocka och din browser.

Men typ exempel från vårt egna team så är det båda team som vi sitter nära så man kan gå till och prata med direkt men det är också externa konsumenter från andra företag som vill ha den datan och de kommer ju säga såhär Där kan det verkligen komma så, vi har en drop-down-lista där vi behöver presentera de här olika alternativen Ska ni kunna sortera dem åt oss och göra den här logiken?

Då är det jättesvårt, det är dels svårt att säga nej för det kanske är någon betalande kund. När egentligen det rätta svaret är så här. Ja, alltså ni får ju bygga er egna back-end som filtrerar det här. Det kanske inte alltid man vill säga det, ja. Nej när det är så självklart liksom så vill man inte så komma som bäst servicer och bara då har ni inte en egen back-end som ni kan filtrera det här på.

Men man vill ju hålla sin egen kod liksom. Ren och fin, ja exakt. Ja men då blir det verkligen så här... Okej vi vill inte besudla våran fina microservice-core-app här. Ska vi bygga en egen backend från frontend till den här klienten?

[00:21:43] Madde: Nej det blir lite konstigt kanske. Alla vill bara flytta ansvaret närmare.

Ja

[00:21:54] Sofia: Det är ju rätt, ingen vill äga mer affärslogik själv. Det är mer maintenance. Men det är ett fint mönster. Jag märker att folk glömmer bort det i alla fall. Och lägger mer och mer blot på mer generella byr Och önskar att fler visste om. Att man kan ha en back-up på fronten. För att lösa sina egna problem.

Sina egna specialfall.

[00:22:24] Madde: Ja. Alltså jag har ju aldrig direkt jobbat med. Någon applikation som har olika klienter. Såhär att det. Du har liksom din webb-app. Du har en native iOS. Du har en native Android och så. Så att jag har liksom inte direkt behövt använda det. På det sättet. Så att vore kul faktiskt att få prova på något mer.

Vi får se. Någon gång kanske.

[00:22:50] Sofia: Men du har. Men ni har ju haft. Alltså ni har ju haft en back and forth frontend I ert team. För jag vet att vi har ju suttit i team. Där du har bara en webbklient. Men du har liksom en back and forth frontend. Till den. Ja

[00:23:08] Madde: Ja, absolut. Det är ju vår back-end som det har varit.

Jag vet inte vad du tänker på rent specifikt. Jag

[00:23:17] Sofia: vet inte exakt hur ni hade det, men när du och jag var hos samma kund.

[00:23:21] Madde: Jag

[00:23:21] Sofia: vet att vi byggde ganska likt då för vi använde samma stack och så. Men i vår team så hade vi bara en webbaserad applikation. Och sen hade vi kanske tio mikrotjänster Och liksom nio eller ja, tio eller ja, jag vet inte, de flesta av dem gjorde någonting väldigt specifikt den här producerar bara detta, den här producerar bara detta, och så hade vi en backend som var ansvarig för att anropa alla dem och sätta ihop liksom svaret till frontenden

[00:23:58] Madde: Okej ja nej riktigt så byggde inte vi, utan vi hade liksom en stor back-end i .NET som var allt, sen så kommunicerade vi med andra API som inte vi själva ansvarade för, men vi hade inga egna microservices eller någonting.

Sen hade vi dessutom en express-server i fronten. Men det var mer för att få till server-side-rendering och bättre SEO och sånt. Så den skulle man ju kunna kalla för en BFF. Men det var ju inte i det bemerkelsen att den filtrerade data och byggde ihop svaren till oss så som klienten ville ha det.

[00:24:32] Sofia: Ja, men jag tror att i så fall skulle era back-enden då, det är en BFF då.

För ni hade ju kunnat göra alla anropen via browsern istället. Lite

[00:24:44] Madde: oldschool kanske. Men i så fall är ju alltid en backend-server en BFF. Men typ, men typ. Ja, kanske. Det känns... Nej, det gillar jag inte. Jag håller inte med.

[00:24:59] Sofia: Ja. Jag tror att folk fattar ändå vad vi är ute efter. Så ja, det var ett kort avsnitt.

Men jag hoppas att ni har lärt er något nytt.

[00:25:11] Madde: Mm.

[00:25:12] Sofia: Eller bara så

[00:25:15] Madde: här. Det blir påmind. Nu behöver man ibland bara just det. Ja. Ja Vi hörs som vanligt i nästa vecka.

[00:25:24] Sofia: Det gör vi. Ha det bra.

[00:25:26] Madde: Hejdå.