[doubt]

Mirki, takie pytanie o design w świecie mikroserwisów.

Załóżmy, że mam jakieś duże X API restowe, które jakoś tam z głową domenowo jest zaprojektowane. X API wspiera autoryzację z OAuth2, ale też poza tym wystawia taki zwyczajny endpoint do uwierzytelniania (POST, który zakłada sesję i zwraca ciacho użytkownikowi). Czyli mamy do dyspozycji wszystkie grant typy OAuthowe i zwykłą autoryzację cookiesem.

Teraz chciałbym dorobić UI do tego X API. Tyle, że X API nie było projektowane na potrzeby jakiegokolwiek frontu, więc często będzie wymagane dociągnięcie danych z wielu endpointów by wygenerować pełen widok.

Czy lepiej zrobić jakiś cienki backend-for-frontend i tam zawrzeć logike mergowania danych (UI uderza do BFF i dostaje prawie wszystko co potrzebne od razu) czy lepiej to zrobić bezpośrednio na froncie?

No i jeszcze jest kwestia autoryzacji, jak to wszystko pospinać by koniec końców X API było świadome, że dany request zatriggerował taki i taki użytkownik/client w takiej i takiej sesji?

Dodam jeszcze, że obecnie X API jest zarówno Authorization serverem jak i Resource serverem. Na pewno będzie to dzielone, jak i same funkcjonalności X API rozpadną się na kilkanaście serwisów, które pewnie będą rozdzielnymi clientami w OAuth.

Dlatego skłaniam się ku opcji BFF, wprowadzenia JWT i forwardowania go z frontu do BFF. BFF będzie już autoryzować się w "backendowych" serwisach przez Authorization Code grant. Ma to sens?

Technologie tu nie są super istotne, ale jakby co to front w #angular, backend w #java, #spring, #springboot.

#programowanie #mikroserwisy #oauth

[thorin87]

@doubt: w projekcie przy którym pracuję używamy właśnie takiej warstwy pośredniej i sprawdza się to naprawdę fajnie. Frontend nie dostaje żadnych nadmiarowych danych tylko szyte na miarę struktury ukrywając szczegóły API. Z przeglądarki leci 1 request, BFF pod spodem może sobie robić tych reqestów ile zechce a i tak będzie szybko bo działa na tej samej maszynie co backend. Dzięki temu że BFF jest w node, to współdzieli z frontem wszystkie

[Ridicz]

@doubt: Pattern, którego szukasz to API Gateway. Możesz skorzystać z czegoś gotowego w stylu Zuul, albo zrobić go po prostu jako osobny mikroserwis, który pośredniczy w callach pomiędzy FE a BE. No i dobrze też mieć osobny serwis, który będzie służył stricte jako Authorization server.

[doubt]

@thorin87: git :) dlatego też w moim przypadku BFF wydaje się sensowniejszy, bo wtedy ukryje się całkowicie migracje na mikroserwisy przed frontem. Dla UI to będzie transparentna zmiana.

Tylko nie wiem co dalej z autoryzacją xD. Jeszcze innymi słowami: chciałbym żeby w tym grafie polączeń między usługami (BFF woła usługę X, usługa X woła Y, Y woła Z i T itd) nigdzie nie ginął kontekst usera, który wywolał operację na UI.

[Ridicz]

@doubt: Ale czemu Gateway miałby robić jakąś złożoną logikę? Ma zawołać odpowiedni serwis, który zajmie się resztą, on może zawołać inne, żeby dostać dane, których potrzebuje albo je przetworzyć. Co do OAutha, to nie bardzo rozumiem czemu korzystasz z sesji. Używając OAuth2 + JWT masz wszystko czego potrzebujesz do autoryzacji bez sesji.

[doubt]

Ale czemu Gateway miałby robić jakąś złożoną logikę? Ma zawołać odpowiedni serwis, który zajmie się resztą, on może zawołać inne, żeby dostać dane, których potrzebuje albo je przetworzyć.

@Ridicz: Ok, to ja źle zrozumiałem. Oczywiście takich backendów dla frontu może być więcej (też mogą być jakoś domenowo podzielone) i wtedy faktycznie można to machnąć Zuulem. Tak w ramach ciekawostki - dobry też jest Spring Cloud Gateway. Wymaga on reaktywnego stacku a