Drugi backend - jakie rozwiązanie dla UI?

Cześć. Jest sobie duży backend A z 50 mikroserwisami i ma swój UI.

W pewnym momencie zaczęla postawać nowa apka, która ma swój UI i dedykowany backend B (na razie 4 małe mikroserwisy).
Nagle doszło wymaganie, że jednak UI B musi odpytywać o pewne rzeczy Backendu A. Bezpośrednio robić tego nie może, bo inne klucze JWT itd.

Czy spoko rozwiązaniem będzie zrobić mikroserwis proxy w backendzie B, który będzie przyjmował request, podmieniał nagłówki, ucinał "/to_backend_a" z urla itd i robił reditect na backend A? Zdaje sobie sprawę, że ten proxy to wąskie gardło, ale ktoś ma lepsze rozwiązanie? Nie trzeba tłumaczyć dtosów, 0 logiki pomiędzy.

W zasadzie to, o czym piszesz, to integracja dwóch systemów, na co jest parę patternów. Dlaczego by nie zrobić tego poprzez jakaś kolejkę?

@Charles_Ray: też tak z początku myślalem ..

Ale to ma być generyczne i dynamiczne rozwiązanie. UI jeśli będzie potrzebował sobie uderzyć do istniejącego od lat backendu A ma po prostu wywołać daną usługę bez żadnych ingerencji w kod aby było to wygodne i nie pociągalo zmian. Dlatego to proxy aby użyć odpowiednich kluczy do podpisania tokenu. Tylko boli mnie, że to wąskie gardło.

No to możesz zrobić reverse proxy - postawić usługę, która będzie forwardować requesty na podstawie jakiegoś mapowania, np.
/legacy-proxy/customers/1 -> /customers/1. Zastanawiam się czy tego nie mógłby po prostu robić jakiś loadbalancer, to nawet usługi nie trzeba by było pisać.

Co rozumiesz przez „wąskie gardło”?

Bambo napisał(a):

Nagle doszło wymaganie, że jednak UI B musi odpytywać o pewne rzeczy Backendu A. Bezpośrednio robić tego nie może, bo inne klucze JWT itd.

Co to za problem, że "inne klucze"? Zróbcie, żeby były takie same, albo wzajemnie akceptowane. Ostatecznie po to się robi JWT, żeby token wystawiony w jednym miejscu był akceptowany w innym/innych miejscach. Pozostaje pytanie, dlaczego rozbijacie ten backend na 2 różne. Nie twierdzę, że to błąd, tylko jakiś powód za tym stał. No i pytanie co to jest "backend" w rozumieniu tego posta.

Czy spoko rozwiązaniem będzie zrobić mikroserwis proxy w backendzie B, który będzie przyjmował request, podmieniał nagłówki, ucinał "/to_backend_a" z urla itd i robił reditect na backend A? Zdaje sobie sprawę, że ten proxy to wąskie gardło, ale ktoś ma lepsze rozwiązanie? Nie trzeba tłumaczyć dtosów, 0 logiki pomiędzy.

Wiele rzeczy można - zrobić gateway, który będzie podmieniał autoryzację i przekierowywał zapytanie w inne miejsce, albo VNET pairing pomiędzy sieciami obu "backendów", albo backend B korzystający z API wystawionego przez A.

Do takich rzeczy stosuje się API gateways jak już zaproponował somekind, lub backends-for-frontends (tutaj: BFF) które też są niby takimi API gateways ale bardziej wyodrębnionymi na potrzeby konkretnego frontendu. Czasem stosuje się również te dwa podejścia razem, czyli każdy frontend ma swój BFF, który uderza do API gateway "stojącego na straży" całego systemu.