[00:00:00] Sofia: Så en sak som man saknar här. Det kan vara en upp i gateway. Jag vet. Jag vet att någon skriker säkert. Att svaret är att bara ha en BFF. I det här fallet Men vi. Vi kan ta det lite senare och det känns som att BFF är nästan ett helt separat avsnitt.

Du lyssnar på Developers, podden där du får följa med oss, Sofia och Madde, på allt inom mjukvaruutveckling. Vi träffar spännande gäster,

[00:00:33] Madde: testar nya teknologier, söker inspiration och tar upp aktuella ämnen. I dag så ska vi prata lite om API Gateways, det är ju ett sånt typiskt koncept som ofta dyker upp så fort man kanske går från ett lite mer monolitiskt system till något med en lite mer distribuerad arkitektur, typ microservice och liknande,

[00:00:56] Sofia: så

[00:00:57] Madde: det är väl bra att kunna lite mer om det,

[00:00:59] Sofia: men

[00:01:00] Madde: vi ska ju tacka våra skönsupportare på Patreon först, såklart Får vi inte glömma.

Viktigast av allt. Stort 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:21] Sofia: Tack så jättemycket till er och alla andra som stöttar oss på Patreon och alla ni som lyssnar på podden helt enkelt.

Men ja, som du säger vi ska ju prata om API Gateway det är ju ett riktigt sexigt ämne men det var vi bara känner väl att det finns vissa koncept som är vanliga och används ofta på ja men typ såhär alla företag det här är ett pattern som är ganska vanligt att ha så det är ju bra att ha koll på det även fast man inte är en del av de som implementerar det kanske det är bra repetition för oss själva också Ja, Jag tycker det här är ämnen som är krångliga för att det här är bara ofta en komponent i en stor arkitektur.

Men vi kan väl börja med att bara prata om några vanliga sätt att implementera en API-gateway. Jag tänker att om man hör det så kanske man känner igen någonting från sitt jobb även fast man inte implementerat det själv. Och blir lite såhär, okej det är nog det här de snackar om. Alltså vad har vi typ sett?

För typer av implementationer där vi har varit? Ja men det finns ju massa olika såklart

[00:02:31] Madde: och typ varje stor molntjänst har ju en egen implementation av det. Kör man till exempel Azure så har man ju Azure API Management. Det har jag använt ganska mycket inte som då att jag har implementerat API Management utan jag har använt API som har legat i API Management.

Men det skulle jag säga är en ganska vanlig I stora enterprisebolag Den är väldigt kraftfull och anpassad för att passa stora enterprises. Det finns stöd för olika policies, versionering, loggning. Och det minns jag ändå smidigt. Du bör bara autenticera dig mot den. Istället för att behöva ha koll på massa olika underliggande API-er.

Och samma med Google Cloud har ju sin API Gateway eller Apigee som också är mer enterprise-ig med versionering och policies och monitorering och allt sånt, olika typer av analytics.

[00:03:35] Sofia: Ja precis, deras vanliga gateway är en lightweight-produkt men sen har de typ köpt Apigee från företaget som heter eller heter det fortfarande Apigee.

Som är liksom mer som Azure's API management som har massa versioneringen och policies också. Mm. Och AWS har väl också någon tror jag? Ja, alltså jag har så dålig koll. Jag jobbar med AWS nu. De har väl typ AWS API Gateway som jag tolkar det som att den är lite mer som Google Cloud API Gateway. Alltså inte så...

Omfattande som Azures eller Apigee? Mm.

[00:04:18] Madde: Nej

[00:04:18] Sofia: jag

[00:04:19] Madde: har faktiskt inte alltså jag har så lite erfarenhet av just AVS själv. Men ja de har ju säkert någon egen i alla fall. Och sen så bygger ju folk egen också. Mm.

[00:04:31] Sofia: Ja det finns absolut tredjepart Gateways. Har du använt några? Nej har du varit på företag som har det?

[00:04:39] Madde: Nej, det har jag inte, utan det är mest API-management faktiskt som jag har använt eller kommit i kontakt med.

[00:04:49] Sofia: Det finns i alla fall större företag eller någon som har mer specifika krav, så väljer de istället att hosta sin egna gateway. Och de som är kända är i alla fall Kong. Det verkar vara någonting som kan användas med AVS API-gateway, så har du...

Så använder du det tillsammans med typ Kong. Men det finns Envoy Proxy. Sen är det, alltså kan du uttala namnet på den tredje? Traffic, nej vänta. Ja, det känns som att det är danskt eller tyskt. Ja. Ja, jag vet inte. Eller så kan man snickra någonting eget. Men det är lite trist att implementera alla de här sakerna.

Ja, samtidigt som jag har en känsla av att det kanske är rätt vanligt att göra det, men jag vet inte. Ja finns folk som alltid tycker att det inte är trist att göra det, såklart. Som sin egen implementation av JOT. Måste säga JOT nu efter vi har lärt oss det. Det finns väl också vanliga scenarion som kanske uppstår när man behöver ta till en API-gateway.

Och vi har väl skrivit ner ett litet exempel på vad som kan hända Jag tycker att man går med i något innovationsteam på jobbet. Man vet inte riktigt vad man är ute efter så man börjar bara... Köra proof of concepts ni börjar bygga en enkel sajt där till exempel kunder kan boka tid med ert företag för konsultation och i början så är allting byggt i ett jättestor monolitiskt API vilket säkert är helt rätt start ganska vanligt att börja

[00:06:33] Madde: så skulle jag säga ja

[00:06:34] Sofia: helt normalt men så är det verkligen fler och fler kunder som börjar använda tjänsten, det går liksom bra Ja Och då börjar det gå långsamt.

Och så blir det mycket kod också. Så blir man såhär, oh, microservices. Och så bygger man om hela systemet med massa separata tjänster Det är såhär, vi tar en för bokning och en för betalning och en för aviseringar. Men istället för att man har ett gemensamt API för att nå alla dessa. Då börjar ni publicera varje tjänst med egna API-er direkt mot klienterna.

Alltså de här frontend-apparna ni har. Och ni kanske har, tänk det här växer Ni har en native mobilapp. Ni har någon konsument som har byggt någon egen klient mot det här. Ni har er hemsida som anropar. Och alla de här behöver anropa varje microservice direkt mot Beroende på vad de ska göra och det här fungerar ju kanske helt okej tills det blir väldigt klyddigt och börjar typ krascha klienterna blir fulla av hårdkodade url du har olika autentiseringsmetoder kanske det här växer så mycket att du har olika team som har tagit över och olika microservicer blir rörigt Det blir kladdigt och det är såhär, era mobilanvändare, de får samma enorma svar som desktopanvändaren fast de verkligen inte behöver det.

Så en sak som man saknar här, det kan vara en app i Gateway. Och jag vet, jag vet att någon skriker säkert såhär att svaret är att bara ha en BFF i det här fallet men vi... Vi kan ta det lite senare, det känns som att BFF är nästan ett helt separat avsnitt Mm,

[00:08:23] Madde: det skulle kunna vara. Men ja, nu har du ju beskrivit när man behöver en API-gateway.

Men vad är en API-gateway då? Bra fråga. Man skulle kunna säga lite att den funkar som en hotellreceptionist. Så istället för att du då ska gå direkt till rummet, det vill säga microservicen, så går du ju först till hotellreceptionen. Och receptionisten där, det vill säga gatewayn då, kollar först, har du ens bokat ett rum?

Autentisering alltså. Har du gjort det så ger de dig nyckeln, alltså en token. Har du tur och det är ett lyxigt hotell kanske de till och med hämtar en sån här vad heter det? Piccolo som bär väskorna. Piccolo, det gör det faktiskt. Alltså hämtar fler sushor och du slipper prata med varje Avdelning själv och göra allting.

Jättefin metafor. Men en API-gateway, det den gör är att det är ett centraliserat sätt att hantera alla former av förfrågningar. Och hantera autentisering. Har du tio underliggande tjänster så slipper du ha det här att du ska outa på tio olika sätt. Och komma ihåg alla eller komma ihåg men behöva hantera det liksom och i vissa fall kan det också vara att den kanske strukturerar om datan på ett visst sätt eller slår ihop två API till ett för att ja, det är det som behövs jag vet på ett kunduppdrag då när jag satt och vi använde API management så var det en proxy för typ såhär on-prem och Tjänster.

Och sen kunde de exponera ut det då i det publika nätet som inte alls hade kommit åt annars. Så att det finns jättemånga fördelar med en gateway. Ja, men

[00:10:16] Sofia: precis som du säger, beroende på hur avancerad gateway man har så kan det ha så mycket olika saker den gör åt det. Den kan typ rotera nycklar och Som du säger så här, strukturera omsvaren.

Alltså du kan ju ha egen custom-logik där i. Eller så kan du hålla det väldigt clean och bara exponera API-er. Man får ju titta lite på vad för typ av produkt man behöver. Det finns mycket att välja på som är jättebra men det är också ganska svårt att sätta upp när det blir sådana här jättestora produkter från måltjänster.

[00:10:56] Madde: Ja, alltså det är ju så himla många tjänster under tänker jag som du ska hålla reda på. Och vi har pratat mycket om microservices men jag skulle säga att det är inte bara för microservices som man behöver det Utan det kan ju bara vara att du har massa interna system som du ska kommunicera med Säg att du jobbar med e-handel som jag har jobbat mycket med.

Då har du kanske något lagerhanteringssystem för att se vad du har för stock. Vad heter det på svenska? Om det finns lager. Du har något orderhanteringssystem. Du har säkert något annat system för att skicka mejl. Du har tusen olika system du ska kommunicera med. Det

[00:11:44] Sofia: kan verkligen vara nice. Ja, liksom väljer du en målprodukt så behöver du liksom förutom den API-gatewayen så behöver du en massa andra tjänster ovanpå eller under, typ som lastbalanserare och sånt.

Så att ja, det blir väldigt mycket ofta och det är skönt om någon annan sköter det åt den när det blir riktigt stort. Det också kan vara krångligt för att vara ute Ett plattformsteam men vi kan dra basics i själva gatewayn ändå hur den brukar fungera bara om den är ganska bareboned så den som du beskrev med receptionisten så funkar den som en Som man kallar en single entry point, du går liksom till ett ställe så att när du är en klient till en sån här backend tjänst så skickar du en förfrågan till en API gateway då och gatewayen kör, jag vet inte, det här är väl optional också men Jag tror att oftast så har det en rate limiting för att du vill skydda din backend från att överbelastas.

Så det här är en stor, väldigt bra funktion i en gateway. Alltså att du inte kan skicka hur många requests på

[00:13:01] Madde: en viss tid som helst och så vidare.

[00:13:03] Sofia: Ja, och så kollar den också om den här klienten får göra en förfrågan och det är det här autentisering och autentisering Aktöriseringssteget. Den validerar också dina headers din body, att det följer schemat, så det sker redan på den nivån.

Där kan man ju göra det genom att du pushar ditt API-schema till den här gatewayn. Den kan också kanske transformera din request också. Och sen routar den vidare till rätt microservice. Beroende på URL-path, headers, metod eller query-parametrar som det har. Om det är så att. Du frågar efter någonting, kräver egentligen flera anrop, vanligtvis så är det också den som kombinerar ihop svaren från olika microservices och returnerar dem, också liksom optional men det är ju någonting verkligen som man kan använda den till Och så skickar den tillbaka svaret till klienten du kan också ha cachening i det lagret om det är relevant för dig cachening har vi ju pratat om lite grann innan den kan också ha funktioner som att att den identifierar vad det är för slags device enhet, typ är det en mobil som gör frågan eller är det en desktop så kan du anpassa responsen typ typ Om du vill ha ett mindre svar när det är en mobil.

Så att du minskar latencyn och sparar bandbredden. Det finns funktioner som om du har en tjänst som är överbelastad eller kraschar. Så kan gatewayen använda ett så kallat circuit breaker pattern. För att undvika att du skickar fler requests dit. Så det finns egentligen en massa saker som man kan sätta upp i den här gatewayen Men man hör ju att den är det är inte riktigt en sak och det är något som är väldigt mångsidigt och det är mer koncept av ett lager som gör vissa saker ja, precis det är nog lite jag tror att man kan känna sig ofta dum när någon säger, ja men vi behöver en gateway ja Och så blir det så här, vad menar personen?

Men då är det ju liksom, det är okej att fråga vad menar du, vad är det du vill lägga i det lagret? Ja vad är för problem du vill

[00:15:36] Madde: lösa? Det är ju en bra fråga att ställa sig. Det är ju inte en one size fits all utan det är ju ändå ganska... Anpassningsbart beroende på vad det är man behöver men ja, där är ju många fördelar alltså som du säger det är ju väldigt bra för klienten att bara behöva prata med ett ställe istället för att behöva göra det på tusen olika ställen jätteskönt att kunna centralisera all liksom autentisering och all logik kring säkerhet och liknande det blir liksom mindre pratigt på något sätt jätteskönt Ja,

[00:16:13] Sofia: det blir väldigt svårt att skala det om du har requests som flyger överallt och just så här säkerhetsaspekten tänker jag som är ganska viktig.

Att det är lättare att hantera det centralt.

[00:16:29] Madde: Ja, åtminstone så kanske det är så att det följer en viss standard. Sen får man hoppas att den standarden är låg istället för att få obehagliga överraskningar i varje API liksom. Och sen som du sa det här att man kan anpassa payloaden till olika typer av klienter är ju faktiskt också riktigt kan vara väldigt användbart och cachening och throttling kan man lägga på och sen bara jag vet inte, det som jag kanske tycker är the nicest är att man kan ha monitorering du behöver bara ha det på ett ställe Du behöver liksom inte sätta upp en egen grafana dashboard för att hålla koll på 70 olika microservices utan du kan liksom ha din observability på ett ställe.

Det är iallafall de grejer jag tänker är bra men som allt så finns det väl nackdelar också antar jag.

[00:17:23] Sofia: Ja det är inte magi. En sån här självklar sak är bara att du får mer latens i systemet. Det är ett extra steg nätverket. Så det är jag vet inte om det är ett så stort problem som någon bara så här, ja men det blir mer lite sen när vi använder en gateway så att vi skiter i det.

Men det kan bli det tror jag att, för ibland kan man hamna i ett scenario där man har typ så här två gateway-lager. Alltså en tjänst anropar en gateway och sen behöver din gateway anropa en gateway som någon har satt upp framför sin app i sitt egna team. Det har jag ändå sett på jobbet, att det blir lite kaka på kaka i alla fall För att något team vill gärna hantera vissa saker själv och litar inte på det här plattformsteamet som kanske har satt upp den större gatewayn.

Det kan bli så Enterprise i alla fall. Sen är det väl... Ja, det är klart. Det är just den här aspekten med drift och underhåll Varför man just får plattformsteam. För att när du ska... När det blir komplicerat och det är mycket säkerhet och policies och du ska ha väldigt hög availability, då har jag i fall sett att ett större företag har ett plattformsteam för att det är ganska svårt att implementera.

Du får ju typ, som där jag jobbar så får man ju ha kontakt med... Nu kör vi typ alla cloud-plattformar, men när vi sätter upp Azure API Management så får man ha kontakt med Microsoft för att lösa lite större problem eller ställa frågor till dem. Och det är ingenting som man har tid med i ett team.

[00:19:20] Madde: Nej, alltså det kan ju bli otroligt komplext.

Och som sagt ska du då ha... 20 olika tjänster alltså säkert många, många många fler men säg att du har ett team Som använder 20 olika tjänster. Det blir ju som en proxy däremellan. Och så undrar de. Jaha men varför funkar inte den här tjänsten? Då ska du först kolla. Okej ligger problemet i plattformen? Nej okej vi får fel när vi anropar tjänsten direkt.

Ja men då ska du plötsligt gå och felrapportera det till dem. Alltså det blir ju väldigt mycket arbete kring det på något sätt. Eller kan bli. Jag tycker egentligen lite synd om dem som jobbar med det. Alltså de som sätter upp plattformen. Ja men jag tror att de ofta får mycket skuld som inte är befogen.

Jaha, och när

[00:20:11] Sofia: endpointen svarar med 500, vad har ni gjort? Eller typ så. Nej, men det är ju de här noobsen som har släppt en trasig version av sitt API igen Men typ så. Ja, det tror jag också. Det blir ett team som får bara routa en massa tickets hela tiden.

[00:20:37] Madde: Ja, jag tror det blir lätt förekommande så. Nu ska vi inte avskräcka folk från att jobba i plattformsteam.

[00:20:43] Sofia: Nej men det är ganska tacksamt när man har ett plattformsteam. Det är bra att centralisera det när det växer. Jag tycker inte det här är någonting som... Varje team ska sätta upp själva Man kan göra det bara för att testa och lära sig kanske. Men oftast så är det ganska svårt att hantera det. Ja, jag skulle tro det.

Vi nämnde BFF i relation till Gateway. Mm. Ja. Jag tänkte bara att vi kanske bara så här, jag tycker att det är ett helt mönster för sig som är helt fantastiskt, men jag vet att Jag har varit med om att det misstolkas ibland att det skulle på något sätt vara samma sak. Men jag tänker att det är bara saker som relaterar till varandra och bygger lite på det patternet redan.

[00:21:42] Madde: Vi

[00:21:43] Sofia: kan väl bara nämna lite

[00:21:43] Madde: snabbt vad det är då. BFF. Är ju inte best friend forever. Det är det också. Det har jag alltid trott. Nej men det står ju för. Back and for front end. Och som sagt Det bygger vidare lite på hela. Idén kring APA gateways. Men. Om man kollar upp på vad skillnaden är. Så NAPI Gateway är ju en gemensam ingång för alla typer av klienter.

Oavsett om du kommer från mobilen eller webben. Eller om det är någon partner som har byggt en egen integration eller liknande. Och tar hand om all säkerhet All monitorering. Precis. Och visst den kan ju anpassa till olika klienter Precis som vi sa. Ja. Men det en BFF gör är att en BFF är strikt för en

[00:22:37] Sofia: klient,

[00:22:38] Madde: alltså det är en backend för en frontend.

Så har du en mobilapp så har du en backend som är specifikt för mobilappen. Har du en webapp så har du en frontend Det verkar inte specifikt för den, för att det kan skilja sig så himla mycket. Webben kanske vill ha mycket mer data för att kunna rendera hela sidan medan mobilen där är det mycket viktigare att det är snabba små svar för att du vill spara bandbredd eller...

Batteri liksom. Och jag vet då på mitt förra kunduppdrag också. Så hade vi så här partners som kunde ha en del av vår produktkatalog. Men de fick ju bara se sina produkter Så då fick de bara en delmängd av datan. Så att ja det är egentligen det som är syftet med en BFF.

[00:23:29] Sofia: Ja så mer liksom den är till för klienterna.

Och väldigt klient-specifik logik ligger i den. Den kan också slå ihop svar från API-er egentligen. Men så att man inte misstolkar vart man ska lägga vilken logik i vilket lager. Men sånt där är ju svårt. Men ja, ordningen är väl liksom. Du har klient, du har ofta gatewayn sen har du BFFen och sen har du microservices i botten.

Så gatewayn är... Ditt största skydd och så gör BFFen det lite enklare för frontenden och båda behövs det är en utslutning det andra och båda behövs oftast men det vore kul att göra ett avsnitt om BFF också för det här är ju massa att folk att man misstolkar man skapar en BFF och sen börjar man använda den för två klienter och så börjar det bli riktigt kladdigt igen Så det kan vi göra ett avsnitt om.

[00:24:37] Madde: Kanske vi skulle göra. Sitter du inne med någon war story kring det?

[00:24:40] Sofia: Nej men jag tycker om patternet väldigt mycket. Jag vet inte varför. Och jag tycker om historien. Det finns historia var det kommer ifrån. Så det kan vi prata om längre fram.

[00:24:52] Madde: Ja en liten cliffhanger Vad spännande.

[00:24:55] Sofia: Men ja.

[00:24:56] Madde: Ja nämen. Det var en supersnabb genomgång om API-gateways.

Om åtminstone har lite koll på det.

[00:25:03] Sofia: Ja, det är svårt att prata om det just för att det är så himla stort. Om man skulle kunna prata om ett specifikt företag och hur de har satt upp sitt. Men det kommer inte vara samma på ett annat. Men det är bra att känna till att det finns ett sådant koncept. Ja som med det sagt så hörs vi nästa vecka.

[00:25:26] Madde: Det gör vi, adjöken!