Przypadki użycia wielu niestandardowych endpointów
Oczekuje się, że GraphQL udostępni jeden endpoint do pobierania danych. Istnieją jednak sytuacje, w których bardziej sensowne jest udostępnienie wielu niestandardowych endpointów, gdzie każdy z nich prezentuje dostosowany schemat. Pozwala nam to zapewnić odmienne zachowanie dla różnych użytkowników lub aplikacji, po prostu zmieniając używany endpoint.
Udostępnianie wielu endpointów w GraphQL nie jest równoznaczne z REST. Podczas gdy w REST każdy endpoint zapewnia dostęp do predefiniowanego zasobu lub zestawu zasobów, każdy z wielu endpointów GraphQL nadal zapewnia dostęp do wszystkich danych ze swojego schematu, umożliwiając pobranie dokładnie tego, czego potrzebujemy. Jest to więc nadal normalne zachowanie GraphQL, z dodatkową możliwością dostępu do danych z różnych schematów.
Ta możliwość różni się również od schema stitching lub federation, które umożliwiają włączenie kilku źródeł danych do jednego, zunifikowanego grafu. W przypadku wielu endpointów mamy do czynienia z wieloma schematami. Intencją jest traktowanie ich niezależnie, a nie jako części większego schematu.
Udostępnianie różnych schematów może zapewnić dostęp do wielu niezależnych grafów. Twórca GraphQL Lee Byron wyjaśnia, kiedy może to być przydatne:
A good example of this might be if you've company is centered around a product and has built a graphql API for that product, and then decides to expand into a new business domain with a new product that doesn't relate to the original product. It could be a burden for both of these unrelated products to share a single API and two separate endpoints with different schema may be more appropriate.
[...] Another example is [...] - you may have a separate internal-only endpoint that is a superset of your external GraphQL API. Facebook uses this pattern and has two endpoints, one internal and one external. The internal one includes internal tools which can interact with product types.
Przyjrzyjmy się kilku dodatkowym przypadkom użycia, w których udostępnianie wielu endpointów GraphQL ma sens.
Oddzielne udostępnianie endpointów administratora i publicznego
Gdy używamy jednego grafu dla wszystkich danych w firmie, możemy weryfikować, kto ma dostęp do różnych pól w naszym schemacie GraphQL, konfigurując polityki kontroli dostępu. Na przykład możemy skonfigurować pola tak, aby były dostępne tylko dla zalogowanych użytkowników lub użytkowników z określoną rolą.
Jednak gdy istnieją pola zawierające wrażliwe lub poufne informacje, które w żadnym wypadku nie powinny być dostępne dla nieupoważnionych podmiotów, wolimy nie udostępniać tych pól w publicznym schemacie w ogóle, a jedynie w prywatnym schemacie, do którego dostęp ma tylko zespół. Ta strategia ochroni nasze prywatne dane przed niezamierzonymi problemami, takimi jak błędy w oprogramowaniu i niedbałość przy konfiguracji schematu, a nawet zwiększy bezpieczeństwo przez zezwolenie tylko odwiedzającym z określonych adresów IP na dostęp do prywatnego endpointu.
Dlatego możemy utworzyć dwa oddzielne schematy, schematy Admin i Public, i udostępnić je pod endpointami /graphql/admin (ograniczając dostęp do odwiedzających z określonego IP) i /graphql/public (dostępny dla wszystkich).
Bezpieczniejsze ograniczanie dostępu do prywatnych informacji
Ta sekcja jest uogólnieniem poprzedniej: nie chodzi tylko o publiczny kontra administrator, ale o każdą sytuację, w której zestaw użytkowników zdecydowanie nie może mieć dostępu do informacji innego zestawu użytkowników.
Na przykład, gdy musimy tworzyć dostosowane schematy dla różnych klientów, możemy udostępnić niestandardowy endpoint dla każdego z nich (/graphql/some-client, /graphql/another-client itd.), co może być bezpieczniejsze niż dawanie im dostępu do tego samego zunifikowanego schematu i weryfikowanie ich za pomocą kontroli dostępu.
Zapewnianie różnego zachowania różnym aplikacjom
Możemy przyznać różne zachowanie różnym aplikacjom uzyskującym dostęp do tego samego źródła danych.
Na przykład Reddit wyświetla inną odpowiedź w zależności od tego, czy dostęp następuje z przeglądarki desktopowej, czy mobilnej. Z przeglądarki desktopowej, niezależnie od tego, czy jesteśmy zalogowani, możemy bezpośrednio przeglądać treść:
Dostęp z urządzenia mobilnego wymaga jednak zalogowania się, a użytkownicy są zachęcani do korzystania z aplikacji:
To różne zachowanie można zapewnić, tworząc dwa schematy, schematy Desktop i Mobile, i udostępniając je odpowiednio pod /graphql/desktop i /graphql/mobile.
Generowanie strony w różnych językach
Jeśli chcemy wygenerować tę samą stronę w różnych językach, możemy uwzględnić kod języka jako część struktury niestandardowego endpointu, na przykład /graphql/en dla angielskiego i /graphql/fr dla francuskiego. Następnie serwer GraphQL może pobrać te informacje i przetłumaczyć dane na żądany język.
Na koniec wskazujemy każdy z tych endpointów w generatorze statycznych stron, aby wygenerować stronę w jednym lub innym języku:
Testowanie zaktualizowanego schematu przed wdrożeniem na produkcję
Jeśli chcemy zaktualizować nasz schemat GraphQL i pozwolić grupie użytkowników przetestować go z wyprzedzeniem, możemy udostępnić nowy schemat za pomocą endpointu /graphql/upcoming. Co więcej, możemy również udostępnić endpoint /graphql/bleeding-edge, który stale wdraża schemat ze środowiska DEV.
Obsługa podejścia BfF
Backend-for-Frontends (w skrócie BfF) to podejście do tworzenia różnych API dla różnych klientów, gdzie każdy klient „posiada" swoje API, co pozwala mu tworzyć najbardziej optymalną wersję opartą na własnych wymaganiach.
W tym modelu niestandardowy BfF jest pośrednikiem między usługami back-end a klientem:
Ten model można zrealizować w GraphQL, implementując wszystkie BfF w jednym serwerze GraphQL z wieloma endpointami, gdzie każdy endpoint obsługuje określony BfF/klienta (np. /graphql/mobile i /graphql/web):
