Mikroserwisy w akcji. Отсутствует
żądań.
WSKAZÓWKA Dostępne bramy API występują w postaci zarówno narzędzi open source, jak na przykład Mashape’s Kong, a także jako produkty komercyjne, jak na przykład AWS API Gateway.
Na rysunku 3.19 przedstawiono bramę API. Brama uwierzytelnia żądanie, a jeśli to się powiedzie, przesyła żądanie do odpowiedniej usługi backendu. Następnie przekształca otrzymane wyniki, tak że po ich zwróceniu są one w postaci odpowiedniej dla klientów.
Z perspektywy bezpieczeństwa brama pozwala także zminimalizować narażony na ryzyko obszar systemu, umieszczając wewnętrzne usługi w sieci prywatnej i ograniczając dostęp dla wszystkich, oprócz bramy.
OSTRZEŻENIE Czasami brama API może wykonywać kompozycję – złożenie w jedną odpowiedzi z wielu usług. Linia między tym a agregacją warstwy usług jest rozmyta. Najlepiej zachować ostrożność i unikać przeciekania logiki biznesowej do samej bramy, co może nadmiernie zwiększać wiązanie między bramą a usługami podstawowymi.
Rysunek 3.19. Brama API obsługująca żądanie klienta
3.5.2. Backends for frontends
Wzorzec backends for frontends (BFF) jest odmianą podejścia opartego na bramie API. Chociaż podejście oparte na bramie API jest eleganckie, ma kilka wad. Jeśli działa ona jako punkt kompozycyjny dla wielu aplikacji, zaczyna brać na siebie większą odpowiedzialność.
Wyobraźmy sobie na przykład, że obsługujemy zarówno aplikacje stacjonarne, jak i mobilne. Urządzenia mobilne mają inne potrzeby, wyświetlając mniej danych przy mniejszej przepustowości i dostępnych innych funkcjonalnościach użytkownika, takich jak lokalizacja i kontekst. W praktyce oznacza to, że potrzeby urządzeń stacjonarnych i mobilnych dotyczące interfejsu API są rozbieżne, co zwiększa zakres funkcjonalności potrzebnych do integracji w bramie. Różne potrzeby, takie jak ilość danych (a tym samym ilość istotnych informacji) zwróconych dla danego zasobu, mogą również powodować konflikty. Może być trudno zrównoważyć te przeciwstawne oczekiwania podczas budowania spójnego i zoptymalizowanego interfejsu API.
W podejściu BFF używamy bram API dla każdego typu obsługiwanego klienta. Biorąc wcześniejszy przykład z SimpleBanku, każda usługa dostępna dla użytkownika miałaby unikalną bramę (rys. 3.20).
Rysunek 3.20. Wzorzec backends for frontends dla aplikacji klienckich SimpleBanku
Dzięki temu brama może być bardzo specyficzna i reagować na potrzeby jej klientów bez konfliktów czy konieczności jej nadmiernej rozbudowy. Skutkuje to mniejszymi i prostszymi bramami oraz ich bardziej ukierunkowanym rozwojem.
3.5.3. Bramy consumer-driven
W obu poprzednich wzorcach to brama API określała strukturę danych, które zwraca konsumentowi. Aby obsługiwać różnych klientów, można tworzyć unikalne backendy. Odwróćmy to jednak. Co by się stało, gdybyśmy mogli zbudować bramkę, która pozwoliłaby konsumentom dokładnie określić, jakich danych potrzebują od naszej usługi? Pomyślmy o tym jak o ewolucji podejścia BFF – zamiast budować wiele interfejsów API, można zbudować pojedynczy superzestaw API, który pozwala konsumentom zdefiniować kształt odpowiedzi, której oczekuje.
Możemy to osiągnąć za pomocą GraphQL. GraphQL jest językiem zapytań dla interfejsów API, który pozwala konsumentom na określenie, których pól danych potrzebują, oraz na łączenie różnych zasobów w pojedynczym żądaniu. Na przykład dla klientów SimpleBanku moglibyśmy udostępnić następujący schemat.
type Account {
id: ID!
! wskazuje, że pole nie może być puste
name: String!
currentHoldings: [Holding]!
Rachunek zawiera listy Holding i Order (Aktywa i Zlecenie)
orders: [Order]!
}
type Order {
id: ID!
status: String!
asset: Asset!
quantity: Float!
}
type Holding {
asset: Asset!
quantity: Float!
}
type Asset {
id: ID!
name: String!
type: String!
price: Float!
}
type Root {
accounts: [Account]!
Zwraca wszystkie rachunki lub rachunek zgodny z identyfikatorem
account(id: ID): Account
}
schema: {
query: Root
Schemat ma pojedynczy punkt dostępu dla zapytań
}
Ten schemat udostępnia rachunki klientów, a także zlecenia i aktywa na każdym z tych rachunków. Klienci następnie wykonują zapytania na tym schemacie. Jeśli na ekranie aplikacji mobilnej są wyświetlane informacje o aktywach i niezrealizowanych zleceniach dla rachunku, można pobrać te dane w jednym żądaniu, jak pokazano na poniższym listingu.
{
account(id: "101") {
Filtrowanie rachunków według ID
orders
Żądanie określonych pól składowych w odpowiedzi
currentHoldings
}
}
W backendzie serwer GraphQL działałby jak brama API, przekierowując i łącząc dane z wielu usług (w tym przypadku zleceń i aktywów). W tej książce nie będziemy szczegółowo drążyć GraphQL, ale dla zainteresowanych oficjalna dokumentacja (http://graphql.org/) jest świetnym miejscem do rozpoczęcia. Odnieślibyśmy także sukces, korzystając z Apollo (https://www.apollographql.com/), aby zapewnić fasadę GraphQL API w stosunku do usług RESTful backend.
3.6. Klienci
Warstwa klienta, podobnie jak warstwa prezentacji w architekturze trójwarstwowej, udostępnia użytkownikom interfejs do aplikacji. Oddzielenie tej warstwy od tych pod nią pozwala na tworzenie interfejsów użytkownika w sposób szczegółowy i zaspokajanie potrzeb różnych typów klientów. Oznacza to również, że możemy rozwijać frontend niezależnie od funkcjonalności backendu. Jak wspomniano w poprzedniej części, aplikacja może wymagać obsługi wielu różnych klientów: urządzeń mobilnych, witryn internetowych, zarówno wewnętrznych, jak i zewnętrznych, z których każdy ma inne możliwości i ograniczenia technologiczne.
Nie jest typowe dla pojedynczego mikroserwisu udostępnianie swojego własnego interfejsu. Zazwyczaj funkcjonalności udostępnione danemu zbiorowi użytkowników są szersze niż możliwości pojedynczej usługi. Na przykład pracownicy administracyjni SimpleBanku mogą zajmować się zarządzaniem zleceniami, konfiguracją