Gebruikssituaties voor meerdere aangepaste endpoints
Van GraphQL wordt verwacht dat het één enkel endpoint beschikbaar stelt om gegevens op te vragen. Er zijn echter situaties waarin het zinvoller is om meerdere aangepaste endpoints beschikbaar te stellen, waarbij elk van deze endpoints een aangepast schema presenteert. Dit stelt ons in staat om een ander gedrag te bieden aan verschillende gebruikers of applicaties door simpelweg het gebruikte endpoint te wisselen.
Meerdere endpoints beschikbaar stellen in GraphQL staat niet gelijk aan REST. Terwijl in REST elk endpoint toegang biedt tot een vooraf gedefinieerde resource of set van resources, biedt elk van de meerdere GraphQL-endpoints nog steeds toegang tot alle gegevens uit zijn schema, waardoor je precies kunt ophalen wat je nodig hebt. Dit is dus nog steeds het normale GraphQL-gedrag, met als toevoeging dat je gegevens uit verschillende schema's kunt benaderen.
Deze mogelijkheid verschilt ook van schema stitching of federation, die het mogelijk maken om meerdere gegevensbronnen te combineren tot één, unified graph. Bij meerdere endpoints hebben we te maken met meerdere schema's. Het is de bedoeling om ze onafhankelijk te behandelen, en niet als onderdeel van een groter schema.
Het beschikbaar stellen van verschillende schema's kan toegang bieden tot meerdere onafhankelijke graphs. GraphQL-bedenker Lee Byron legt uit wanneer dit nuttig kan zijn:
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.
Laten we een aantal aanvullende gebruikssituaties verkennen waarbij het beschikbaar stellen van meerdere GraphQL-endpoints zinvol is.
Admin- en publieke endpoints afzonderlijk beschikbaar stellen
Wanneer we één graph gebruiken voor alle gegevens in het bedrijf, kunnen we valideren wie toegang heeft tot de verschillende velden in ons GraphQL-schema door toegangsbeheerbeleid in te stellen. We kunnen bijvoorbeeld velden configureren zodat ze alleen toegankelijk zijn voor ingelogde gebruikers of gebruikers met een bepaalde rol.
Wanneer er echter velden zijn die gevoelige of vertrouwelijke informatie bevatten, zodat deze onder geen enkele omstandigheid toegankelijk mogen zijn voor onbevoegde partijen, willen we deze velden liever helemaal niet in een publiek schema blootstellen, maar alleen in een privéschema waartoe alleen het team toegang heeft. Deze strategie beschermt onze privégegevens tegen onbedoelde problemen, zoals softwarebugs en onachtzaamheid bij het configureren van het schema, en verhoogt zelfs de beveiliging door alleen bezoekers van bepaalde IP-adressen toegang te geven tot het privé-endpoint.
Daarom kunnen we twee afzonderlijke schema's maken, de Admin- en Publieke schema's, en ze respectievelijk beschikbaar stellen onder de endpoints /graphql/admin (met beperkte toegang voor bezoekers van een bepaald IP) en /graphql/public (toegankelijk voor iedereen).
Toegang tot privégegevens op een veiligere manier beperken
Deze sectie is een generalisatie van de vorige: het gaat niet alleen om publiek versus admin, maar om elke situatie waarbij een groep gebruikers zeker geen toegang mag hebben tot informatie van een andere groep gebruikers.
Wanneer we bijvoorbeeld aangepaste schema's moeten maken voor onze verschillende klanten, kunnen we voor elk van hen een aangepast endpoint beschikbaar stellen (/graphql/some-client, /graphql/another-client, enz.), wat veiliger kan zijn dan hen toegang te geven tot hetzelfde unified schema en ze te valideren via toegangsbeheer.
Verschillend gedrag bieden aan verschillende applicaties
We kunnen een ander gedrag toekennen aan de verschillende applicaties die toegang hebben tot dezelfde gegevensbron.
Reddit geeft bijvoorbeeld een ander antwoord afhankelijk van of het wordt benaderd vanuit een desktopbrowser of een mobiele browser. Vanuit de desktopbrowser kunnen we, ongeacht of we ingelogd zijn, de inhoud direct bekijken:
Wanneer je echter mobiel toegang hebt, moet je ingelogd zijn om de inhoud te bekijken, en word je aangemoedigd om de app te gebruiken:
Dit verschillende gedrag kan worden geboden door twee schema's te maken, de Desktop- en Mobile-schema's, en ze respectievelijk beschikbaar te stellen onder /graphql/desktop en /graphql/mobile.
Een site in verschillende talen genereren
Als we dezelfde site in verschillende talen willen genereren, kunnen we de taalcode al opnemen als onderdeel van de structuur van het aangepaste endpoint, zoals /graphql/en voor Engels en /graphql/fr voor Frans. De GraphQL-server kan deze informatie dan ophalen en de gegevens vertalen naar de gewenste taal.
Ten slotte verwijzen we naar elk van deze endpoints in de statische sitegenerator om de site in de ene of andere taal te genereren:
Een geüpgraded schema testen voordat het naar productie gaat
Als we ons GraphQL-schema willen upgraden en een groep gebruikers het van tevoren willen laten testen, kunnen we dit nieuwe schema beschikbaar stellen via een /graphql/upcoming-endpoint. We kunnen ook een /graphql/bleeding-edge-endpoint beschikbaar stellen dat het schema continu vanuit DEV uitrolt.
De BfF-aanpak ondersteunen
Backend-for-Frontends (afgekort BfF) is een aanpak voor het produceren van verschillende API's voor verschillende clients, waarbij elke client zijn eigen API "bezit" en zo de meest optimale versie kan produceren op basis van zijn eigen vereisten.
In dit model is een aangepaste BfF de tussenpersoon tussen de back-endservices en zijn client:
Dit model kan in GraphQL worden gerealiseerd door alle BfF's te implementeren in één GraphQL-server met meerdere endpoints, waarbij elk endpoint een specifieke BfF/client afhandelt (zoals /graphql/mobile en /graphql/web):
