Casi d'uso per più endpoint personalizzati
GraphQL dovrebbe esporre un singolo endpoint per interrogare i dati. Tuttavia, esistono situazioni in cui ha più senso esporre invece più endpoint personalizzati, dove ciascuno di questi endpoint presenta uno schema personalizzato. Questo ci consente di fornire un comportamento distinto per utenti o applicazioni differenti semplicemente cambiando l'endpoint a cui si accede.
Esporre più endpoint in GraphQL non equivale a REST. Mentre in REST ogni endpoint fornisce accesso a una risorsa predefinita o a un insieme di risorse, ciascuno dei molteplici endpoint GraphQL fornirà comunque accesso all'intera quantità di dati del suo schema, consentendo di recuperare esattamente ciò di cui abbiamo bisogno. Si tratta quindi ancora del normale comportamento di GraphQL, con in più la possibilità di accedere ai dati da schemi differenti.
Questa capacità è anche diversa dallo schema stitching o dalla federation, che permettono di incorporare diverse fonti di dati in un unico grafo unificato. Con più endpoint stiamo trattando con più schemi. L'intenzione è di trattarli in modo indipendente, e non come parte di uno schema più grande.
Esporre schemi differenti può fornire accesso a più grafi indipendenti. Il creatore di GraphQL Lee Byron spiega quando questo può essere utile:
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.
Esploriamo alcuni casi d'uso aggiuntivi in cui esporre più endpoint GraphQL ha senso.
Esporre separatamente gli endpoint admin e pubblico
Quando utilizziamo un singolo grafo per tutti i dati dell'azienda, possiamo verificare chi ha accesso ai diversi campi del nostro schema GraphQL configurando politiche di controllo degli accessi. Ad esempio, possiamo configurare i campi affinché siano accessibili solo agli utenti autenticati o agli utenti con un determinato ruolo.
Tuttavia, quando esistono campi che contengono informazioni sensibili o riservate, tali che in nessun caso questi dovrebbero essere accessibili ad attori non autorizzati, allora preferiamo non esporre affatto questi campi in uno schema pubblico, ma solo in uno schema privato a cui ha accesso unicamente il team. Questa strategia proteggerà i nostri dati privati da problemi non intenzionali, come bug software e disattenzione durante la configurazione dello schema, e rafforzerà persino la sicurezza consentendo l'accesso all'endpoint privato solo ai visitatori provenienti da determinati IP.
Pertanto, possiamo creare due schemi distinti, gli schemi Admin e Public, ed esporli rispettivamente sotto gli endpoint /graphql/admin (e limitarne l'accesso ai visitatori provenienti da un determinato IP) e /graphql/public (accessibile a tutti).
Limitare l'accesso alle informazioni private in modo più sicuro
Questa sezione è una generalizzazione della precedente: non si tratta solo di pubblico contro admin, ma di qualsiasi situazione in cui un insieme di utenti non deve assolutamente poter accedere alle informazioni di un altro insieme di utenti.
Ad esempio, ogni volta che abbiamo bisogno di creare schemi personalizzati per i nostri diversi clienti, possiamo esporre un endpoint personalizzato per ciascuno di essi (/graphql/some-client, /graphql/another-client, ecc.), il che può essere più sicuro che dare loro accesso allo stesso schema unificato e validarli tramite il controllo degli accessi.
Fornire un comportamento differente a diverse applicazioni
Possiamo concedere un comportamento differente alle diverse applicazioni che accedono alla stessa fonte di dati.
Ad esempio, Reddit produce una risposta differente a seconda che vi si acceda da un browser desktop o da un browser mobile. Dal browser desktop, che siamo autenticati o meno, possiamo visualizzare direttamente il contenuto:
Accedendo da mobile, invece, dobbiamo essere autenticati per accedere al contenuto, e siamo incoraggiati a utilizzare l'app:
Questo comportamento differente potrebbe essere fornito creando due schemi, gli schemi Desktop e Mobile, ed esponendoli rispettivamente sotto /graphql/desktop e /graphql/mobile.
Generare un sito in lingue differenti
Se vogliamo generare lo stesso sito in lingue differenti, possiamo fare in modo che il codice della lingua sia già parte della struttura dell'endpoint personalizzato, come /graphql/en per l'inglese e /graphql/fr per il francese. Quindi, il server GraphQL può recuperare questa informazione e tradurre i dati nella lingua desiderata.
Infine, puntiamo a ciascuno di questi endpoint nel generatore di siti statici per produrre il sito in una lingua o nell'altra:
Testare uno schema aggiornato prima di rilasciarlo in produzione
Se vogliamo aggiornare il nostro schema GraphQL e far sì che un insieme di utenti lo testi in anticipo, possiamo esporre questo nuovo schema tramite un endpoint /graphql/upcoming. Ancora meglio, potremmo anche esporre un endpoint /graphql/bleeding-edge, che continua a distribuire lo schema da DEV.
Supportare l'approccio BfF
Backend-for-Frontends (BfF in breve) è un approccio per produrre API differenti per client differenti, in cui ciascun client "possiede" la propria API, permettendogli di produrre la versione più ottimale in base alle proprie esigenze.
In questo modello, un BfF personalizzato è l'intermediario tra i servizi back-end e il suo client:
Questo modello può essere soddisfatto in GraphQL facendo sì che tutti i BfF siano implementati in un singolo server GraphQL con più endpoint, dove ciascun endpoint gestisce uno specifico BfF/client (come /graphql/mobile e /graphql/web):
