Hvorfor API Gateways er sejt

Ressourser:
Bog: Microservices Security in Action
Kursus: Ambar: Microservices architechture

API Gateway mønstret er det fedeste arkitekturmæssige valg jeg har truffet længe, og her vil jeg skrive om hvorfor.

Jeg hørte første gang om API Gateways i min helt tidlige research af microservice arkitektur igennem diverse youtube videoer. En af dem jeg husker bedst, var en video, som sagde at de var super fede, fordi man, når microservicene var bygget bag en API Gateway, behøvedes microservicesene ikke at kommunikere via TLS, men bare via http. Smart, tænkte jeg, det må reducere en masse overhead og ressoursekraft ved at undgå kryptering.
Der kan jeg så fortælle, at jeg efter at have hørt mere om hvorfor man bruger en API Gateway i kursuset hos Ambar og senere i Microservices Security in Action bogen, at jeg synes det er noget reduktionistisk fortalt, og det er slet ikke af denne grund, jeg har valgt at bruge en gateway.
En gateway er smart, fordi den taler ind i og forstærker bonusserne ved at implementere sin løsning som en samling af microservices.

Microservices skal så vidt muligt leve op til Single Responsibility Princippet. Det vil sige at ideelt set skal de ikke stå for autorisering og autentifikationslogik hvis det ikke er indenfor deres bounded context eller deres domæne. Alt denne screening kan uddeligeres fra de enkelte microservices og foregå ude i gatewayen, som også tit kaldes en reverse proxy, fordi den ikke står foran klienten, men foran ressourserne (microservicesene).
Microservices skal kunne skaleres horisontalt uden for meget overhead, og det ville bringe overhead til skaleringen, hvis autorisering og autentifikationen også skulle skaleres med hver gang. Hvis man havde bygget autoriseringen efter OAUTH 2.0 principper og microservicene enkeltvis skulle tale med autoriserings serveren, ville connectionpoolen også skalere med eksponentielt, og autoriseringsserveren ville blive overloaded.
En gateway tilvejebringer et homogent interface for frontenden at henvende sig til. Microservices kan fokusere på hvad de skal og expose sine APIs til gatewayen, hvorved frontenden og udviklerne ikke skulle tænke på hvilket domæne de skal rette deres enkelte requests til. De kan rette alt til gatewayen ifølge api kontrakten og få leveret hvad de gerne vil have. I stedet for at have mange APIerne frontenden henvender sig til, har man bare én.
Og en af de sikkerhedsmæssige grunde er, bl.a. at gatewayen kan agerer public edge for hele løsningen; microservicesene kan eksistere på deres eget isolerede netværk, og gatewayen kan have en fod inde i det, og en fode ude i et eksternt netværk, som gør, at public clients ikke kan tilgå microserviceserne direkte, såfremt de kender deres ip og port, men kun henvende sig igennem gatewayen, hvorved vi får én portal, og derved bliver det nemmere at lave ratelimiting på alle requests, load balance, security screene, og sidst og ikke mindst: med opsætning af mTLS i mellem gateway og klient kan vi føle os mere sikre på at klienten som henvender sig til vores løsning er den frontend app vi eller nogen andre har udviklet specielt til vores backend løsning.
Et sidste eksempel på hvorfor det er en fordel at have en centraliseret indgangsportal til backenden, er, at man når man bliver virkelig fokuseret på hvordan man bedst kan udnytte skalering til fordel for ressourseforbrug, kunne man have en microservice A som f.eks. har POST logic omkring f.eks. produkter, og en anden microservice B som har GET logic på produkter. Et scenarie hvor dette kunne være godt, er f.eks, når der er black friday, og man har kørt statistisk analyse og set at der er langt flere requests som henter produkter end der er requests som poster produkter, jamen så ville man kunne skalere microservice A uden at få overhead med i form af post logic, og frontenden ville ikke behøves at ændre sin ressoursetilgang, det kunne man bare som backend udvikler ordne i routingen i gatewayen. Det er sgu da agilt.
På den måde taler gatewayen ind i en decoupling mellem frontend og backend, og decoupling, skalering, agilitet over hele fladen, og sørger for, at alle kan fokusere bedre på deres business logic.