1. casa
  2. Domanda e risposta
  3. GraphQL e Microservice Architecture

GraphQL e Microservice Architecture

2016-06-28 39 views
69

Sto cercando di capire dove GraphQL è più adatto da utilizzare all'interno di un'architettura Microservice.GraphQL e Microservice Architecture

C'è un dibattito sull'avere un solo schema GraphQL che funziona come gateway API che inoltra la richiesta ai microservizi mirati e costringe la loro risposta. I microservizi utilizzano ancora il protocollo REST/Thrift per il pensiero comunicativo.

Un altro approccio è invece quello di disporre di più schemi GraphQL uno per microservizio. Avere un server gateway API più piccolo che indirizza la richiesta al microservizio di destinazione con tutte le informazioni della richiesta + la query GraphQL.

primo approccio

Avere 1 GraphQL schema come un gateway API avrà un aspetto negativo in cui ogni volta che si cambia il vostro input contratto Microservice/uscita, dobbiamo cambiare il GraphQL schema di conseguenza sul gateway API Side.

secondo approccio

In caso di utilizzo dello schema GraphQL multipla per microservices, avere senso in un modo perché GraphQL impone una definizione dello schema, e il consumatore dovrà rispettare input/output data dal Microservice.

Domande

  • Dove trovate GraphQL la giusta misura per la progettazione di architettura Microservice?

  • Come si progetta un gateway API con una possibile implementazione GraphQL?

fonte

2016-06-28 Fabrizio

risposta

119

Definitivamente approccio # 1.

Avere vostri clienti parlare con più servizi GraphQL (come nel metodo # 2) sconfigge del tutto lo scopo di utilizzare GraphQL, in primo luogo, che è quello di fornire uno schema sui tuoi dati intero applicazione per consentire il recupero in un andata e ritorno

Avere un condiviso nulla architettura potrebbe sembrare ragionevole dal punto di vista microservices, ma per il codice lato client è un incubo assoluto, perché ogni volta che si cambia uno dei tuoi microservices, è necessario aggiornare tutte di i tuoi clienti Te ne pentirai sicuramente.

GraphQL e microservizi sono una soluzione perfetta, perché GraphQL nasconde il fatto che si dispone di un'architettura microservice dai client. Da una prospettiva di back-end, vuoi dividere tutto in microservizi, ma dal punto di vista del frontend, desideri che tutti i tuoi dati provengano da una singola API. Usare GraphQL è il modo migliore che io conosca che ti permetta di fare entrambe le cose. Ti consente di suddividere il tuo back-end in microservizi, pur continuando a fornire un'unica API a tutte le tue applicazioni e consentendo l'unione tra i dati di servizi diversi.

Se non si desidera utilizzare REST per i microservizi, è possibile avere ognuno di essi ha la propria API GraphQL, ma si dovrebbe comunque avere un gateway API. La ragione per cui le persone utilizzano i gateway API è rendere più gestibile chiamare i microservizi dalle applicazioni client, non perché si adatti bene al modello dei microservizi.

fonte

2016-06-28 14:57:52 helfer

+3

+1 avrei dovuto mettere un disclaimer sul mio post che non ho avuto esperienza con GraphQL, invece di rispondere basato su un brevissimo lavoro di lettura durante la ricerca per rispondere alla domanda. Penso che questa risposta affronti meglio la domanda dell'OP. –

+1

@helfer: questo ha davvero senso :) grazie. Ho poche domande in cima a questa splendida risposta. - Stai dicendo che GraphQL deve essere usato come gateway API? - Diciamo che ho un ** ordine ** Microservice che espone un endpoint REST o GraphQL. Una volta finito, devo aggiornare lo schema GraphQL principale per riflettere esattamente gli stessi dati che il microservice esporrà? Non suona duplicazione o si allontana dalla cultura dei microservizi che dovrebbe essere implementata in modo indipendente? Eventuali modifiche a un microservizio devono essere riflesse/duplicate nello schema GraphQL principale? – Fabrizio

+5

@Fabrizio la cosa bella con GraphQL è che anche se l'API REST del backend cambia, lo schema GraphQL può rimanere lo stesso, a patto che ci sia un modo per ottenere i dati che il servizio REST ha esposto in precedenza. Se espone più dati, il modo canonico per affrontare questo è semplicemente aggiungere nuovi campi/tipi allo schema esistente. I ragazzi di Facebook che hanno creato GraphQL mi hanno detto di non aver mai apportato una modifica al loro schema in quattro anni. Tutte le modifiche apportate sono state additive, il che significa che i nuovi client potrebbero utilizzare la nuova funzionalità, mentre i vecchi client continuerebbero a funzionare. – helfer

-1

Ulteriori informazioni sui microservizi, penso che GraphQL possa funzionare perfettamente anche nell'architettura senza server. Non uso GraphQL ma ho my own similar project. Lo uso come aggregator che invoca e concentra molte funzioni in un singolo risultato. Penso che potresti applicare lo stesso modello per GraphQL.

fonte

2017-08-23 08:32:49

1

Per l'approccio n. 2, infatti, è quello che scelgo, perché è molto più semplice che mantenere manualmente il fastidioso gateway API. In questo modo puoi sviluppare i tuoi servizi in modo indipendente. Rendi la vita molto più semplice: P

Ci sono alcuni ottimi strumenti per combinare schemi in uno, ad es. graphql-weaver e apollo graphql-tools, sto usando graphql-weaver, è facile da usare e funziona alla grande.

fonte

2017-09-27 07:30:12 HFX

0

Poiché l'architettura dei microservizi non ha una definizione adeguata, non esiste un modello specifico per questo stile, ma la maggior parte di essi avrà alcune caratteristiche degne di nota. Nel caso dell'architettura dei microservizi, ciascun servizio può essere suddiviso in singoli componenti piccoli , che possono essere modificati e implementati individualmente senza influire sull'integrità dell'applicazione. Ciò significa che puoi semplicemente modificare alcuni servizi senza ricorrere alla ridistribuzione delle applicazioni tramite il numero personalizzato microservices app development.

fonte

2017-12-03 05:52:55

Problemi correlati

 Problemi correlati