Home
topics
GraphQL Federation
Data di pubblicazione: 7 febbraio 2024
Autori: Chrystal R. China, Michael Goodwin
La GraphQL Federation è un approccio architettonico distribuito che consente agli sviluppatori di utilizzare una singola API su più servizi GraphQL (ovvero servizi scritti nel linguaggio di query open source, GraphQL).
La Federation divide lo schema, ovvero il contratto tra operazioni di back-end e front-end, in componenti e microservizi più gestibili, consentendo ai team di creare, implementare e gestire parti di uno schema in modo indipendente, mantenendo al contempo un grafico di dati unificato con cui i clienti possono interagire.
In un ambiente GraphQL federato, un gateway GraphQL integra più schemi, chiamati anche sottografi o servizi, in un unico grafo (o router). Ogni sottografo definisce una parte dello schema generale e gestisce la logica aziendale e il recupero dei dati per i propri tipi e campi. Il gateway poi unisce i sottografi indipendenti in un supergrafo, consentendo ai clienti di eseguire query sulle fonti di dati tra i servizi come se interagissero con un unico schema GraphQL.
Scopri come abbattere i silos di dati con le API GraphQL altamente reattive.
Prima della federation, uno dei metodi principali per combinare più schemi GraphQL era lo stitching degli schemi, in cui diversi schemi e risolutori venivano combinati manualmente. Gli sviluppatori dovevano definire come unire gli schemi e come unire i dati. Sebbene lo stitching degli schemi offrisse una soluzione unificante per gli schemi GraphQL, era anche complesso e soggetto a errori, il che ne rendeva difficile la gestione.
Per risolvere questi problemi e semplificare i processi di stitching degli schemi, gli ingegneri dietro Apollo, un'implementazione GraphQL per la progettazione di prodotti e app, hanno sviluppato l'Apollo federation. L'Apollo federation ha introdotto le parole chiave "key", "external", "requires" e "extends" per definire le connessioni tra i tipi in diversi servizi. Le nuove funzionalità di riferimento incrociato hanno permesso agli sviluppatori di utilizzare un gateway Apollo per costruire un grafo di dati coeso senza fare affidamento su una logica di stitching eccessivamente complessa.
Tuttavia, la federation Apollo GraphQL non era solo un nuovo set di strumenti e librerie. Era anche una specifica di sistema che descriveva l'architettura e il modo in cui i servizi possono comunicare per formare un grafo distribuito. Ciò ha consentito ad altre implementazioni e strumenti di adottare i principi di federation e ha contribuito a stabilire uno standard per la creazione di API GraphQL federate.
Dalla sua introduzione, GraphQL Federation ha subito numerosi miglioramenti. La federation gestita, ad esempio, può facilitare la raccolta di metriche e abilitare aggiornamenti automatici del gateway quando cambiano i sottografi, il tutto senza intervento manuale o tempi di inattività del sistema.
I progressi includono anche lo sviluppo di Federation 21, un'innovazione che ha semplificato l'unione degli schemi tra servizi e l'esecuzione delle query, una maggiore modularità per un maggiore controllo sulla composizione degli schemi e una migliore visibilità degli errori per facilitare il rilevamento e il debug.
L'Apollo federation ha rappresentato un progresso significativo per la creazione di ecosistemi API semplificati e rimane un'opzione valida per le aziende che desiderano implementare architetture IT federate.
Tuttavia, un approccio federativo basato su Apollo vincola gli sviluppatori a un'implementazione con un singolo fornitore, perché gli ambienti federati con Apollo possono accettare solo direttive e tipi definiti da Apollo da Apollo o tecnologie backend conformi ad Apollo. In altre parole, l'Apollo federation spesso limita la flessibilità del sistema, anche quando emergono nuove tecnologie.
Gli sviluppatori che cercano di ottimizzare la flessibilità mantenendo la funzionalità a livello unificato dell'Apollo federation potrebbero preferire l'open federation. Gli approcci di open federation consentono ai sistemi di combinare i dati di qualsiasi fornitore o tipo di API, comprese le API non GraphQL. Utilizzando strumenti come IBM API Connect, le aziende possono personalizzare e scalare i propri asset IT senza restrizioni di compatibilità e continuare ad adottare innovazioni da una serie di community tecnologiche.
GraphQL aiuta i clienti a richiedere esattamente i dati di cui hanno bisogno senza under- o over-provisioning delle risorse, il che lo rende un'ottima opzione per le aziende che cercano di ottimizzare l'efficienza operativa.
Data la sua flessibilità, non sorprende che GraphQL sia un linguaggio di query e un runtime sempre più popolare per le API.2 Tuttavia, man mano che le app web e mobili diventano più sofisticate, l'implementazione di un unico server GraphQL monolitico (e tutte le sue dipendenze) può diventare insostenibile. La federation semplifica gli ecosistemi GraphQL aiutando i diversi sottografi a lavorare insieme come un unico servizio GraphQL coeso.
L'implementazione di un'architettura GraphQL federata coinvolge i seguenti processi chiave.
Per definire gli schemi di sottografi è necessario identificare i confini del dominio e decidere come tali confini debbano interagire.
In un'architettura federata, ogni schema di sottografo rappresenta una porzione specifica del grafo dei dati complessivo; contiene tipi, configurazioni, query, mutazioni e sottoscrizioni che si applicano a un servizio o a un dominio. Un servizio di prodotto, ad esempio, potrebbe avere uno schema di sottografo che include tipi come prodotto e recensione, mentre un servizio utente potrebbe avere tipi utente e profilo.
Gli schemi di sottografi sono definiti in modo molto simile agli schemi GraphQL standard, ma con l'aggiunta di direttive specifiche della federation. Le direttive della federation forniscono istruzioni su come un sistema estende le entità attraverso gli schemi e su come il gateway dovrebbe risolvere campi specifici attraverso i servizi. Definiscono inoltre le chiavi per il riferimento alle entità.
Ad esempio, la direttiva @key specifica i campi che identificano un tipo nei grafi federati; quando viene distribuita, questa direttiva richiede al gateway di recuperare un'entità dal servizio che possiede il tipo specificato. La direttiva @extends indica che un tipo definito in uno schema di sottografo estende un tipo che ha origine in un altro, facilitando l'estensione del tipo (con campi aggiuntivi) in un altro servizio.
I servizi di sottografo sono servizi di back-end che implementano la logica di business per le API di sottografo corrispondenti. Ogni servizio di sottografo definisce la propria parte del grafo di dati e gestisce le query e le mutazioni correlate al dominio. I rispettivi resolver recuperano tutti i dati associati dalle fonti dati, dai database o dalle API REST appropriate.
I servizi di sottografo rivelano anche i loro endpoint GraphQL al gateway di federation, che li utilizza per comporre lo schema federato complessivo. Tieni presente che questi servizi possono essere scritti in qualsiasi linguaggio di programmazione, supponendo che il linguaggio supporti GraphQL.
I gateway di federation orchestrano la composizione dello schema e la pianificazione delle query. Con l'ausilio dei server di federation, i gateway mascherano i singoli servizi di sottografo, presentando al client un'API unificata.
Per configurare un gateway di federation, i team in genere specificano la posizione di ogni servizio di sottografo e impostano l'infrastruttura necessaria per il fetching dello schema, la pianificazione delle query, l'esecuzione e la gestione degli errori. Una volta attivato, il gateway recupera continuamente gli schemi dai servizi di sottografo per assicurarsi di disporre della versione più recente dello schema federato.
Una volta configurati i servizi di sottografo e il gateway di federation, gli amministratori distribuiscono l'intero sistema. Ciò include il provisioning delle risorse hardware e cloud, la configurazione delle pipeline di distribuzione, il monitoraggio delle prestazioni del sistema e la garanzia di un'elevata disponibilità delle risorse.
Non dovrebbe sorprendere che un monitoraggio costante in tempo reale sia essenziale per ottimizzare un ambiente GraphQL federato. Un monitoraggio attento consente ai team di rilevare e risolvere colli di bottiglia nelle prestazioni, errori di sistema e tempi di inattività non pianificati prima che causino problemi più gravi. Il monitoraggio consente inoltre di monitorare lo stato di integrità dei servizi di sottografo e del gateway di federation.
La GraphQL federation rappresenta un progresso significativo nello sviluppo di API GraphQL per sistemi distribuiti su larga scala. Consente ai team di lavorare su parti diverse di uno schema GraphQL in modo indipendente, integrando al contempo il loro lavoro in un'API unificata, il tutto senza interrompere l'esperienza dell'utente finale.
La GraphQL federation ha inoltre un'ampia gamma di casi d'uso, dall'implementazione dell'architettura di microservizi e dalla memorizzazione nella cache allo sviluppo dei prodotti e alle informazioni sulle operazioni, ed è stata adottata da aziende come Netflix, Airbnb, GitHub ed Expedia.
La GraphQL federation facilita anche altri aspetti:
In un ambiente federato, gli sviluppatori possono distribuire la responsabilità di domini di dati specifici su più servizi, consentendo loro di orchestrare e scalare i singoli servizi (e le loro funzioni) in modo più agile.
Poiché i servizi federati possono essere gestiti in modo indipendente, i membri del team possono lavorare sui rispettivi domini senza interferire l'uno con l'altro.
A differenza degli ambienti API REST , la GraphQL federation consente ai clienti di recuperare tutte le risorse e i dati di cui hanno bisogno con una sola richiesta, eliminando le ridondanze e ottimizzando l'implementazione delle risorse.
IBM API Connect è una soluzione completa di gestione delle API che utilizza un'esperienza intuitiva per consentirti di creare, gestire, proteggere, diffondere e monetizzare le API in modo coerente, contribuendo a potenziare la trasformazione digitale on-premise e nei cloud.
IBM API Connect rende possibile la creazione e l'implementazione di un'API di GraphQL a livello di produzione in pochi minuti. È sufficiente fornire i dettagli di connessione della fonte di dati per generare immediatamente un'API GraphQL sicura e ottimizzata.
Scopri i due diversi approcci adottati da questi framework per la creazione di API e i punti di forza e di debolezza di ciascuno.
Scopri perché IBM continua a essere riconosciuta come leader nell'API Management.
Esplora il toolkit di IBM API Connect.
Scopri perché IBM è stata nominata leader nel report Gartner del 2023: Critical Capabilities for API Management.
Questi tutorial forniscono istruzioni pratiche che aiutano gli sviluppatori a imparare a utilizzare le tecnologie nei loro progetti.
Note a piè di pagina
1 Apollo GraphQL Introduces Federation 2 to Get More Organizations to the Graph (link esterno ibm.com), BusinessWire, 3 novembre 2021.
2 Why GraphQL Needs an Open Federation Approach (link esterno a ibm.com), The New Stack, 16 novembre 2023.