TypeScript , GraphQL e NestJS costituiscono le parti principali del nostro stack in Dandy. Insieme, forniscono un potente ecosistema e un set di strumenti che ci consentono di muoverci rapidamente mantenendo un sistema robusto e affidabile. Le caratteristiche principali che ci forniscono sono:

• Sicurezza di tipo end-to-end
• Client generati automaticamente (per chiamate frontend e interservizi) tramite Graphql Code Generator
• Separazione delle preoccupazioni per i nostri microservizi tramite GraphQL Federation
• Controlli dello schema, tracciamento e metriche di integrità tramite Apollo Studio

Per iniziare, daremo un'occhiata al sistema da tre punti di vista: la generazione del codice che collega i componenti senza soluzione di continuità, il flusso delle richieste in fase di esecuzione e l'aspetto del codice dal punto di vista di uno sviluppatore che lavora su servizi e applicazioni all'interno il sistema.

Generazione del codice

Ecco la pipeline di generazione del codice, che opera in poche fasi:

Passando attraverso questo:

• Abbiamo più servizi di backend e applicazioni React rivolte agli utenti.
• I nostri servizi di backend definiscono i graphqltipi di oggetti utilizzando i decoratori GraphQL di NestJS, oltre a risolutori per gestire query e mutazioni su tali oggetti.
• Backend servizi generano i propri schemi GraphQL utilizzando generazione file di schema di NestJS funzione .
• Il nostro servizio Apollo Gateway utilizza tali schemi e genera uno schema federato che li combina, consentendo ai client di inviare operazioni GraphQL a qualsiasi dei nostri servizi sullo stesso endpoint.
• I nostri pacchetti di generazione client utilizzano il graphql-codegenpacchetto e lo schema federato per generare tipi Typescript per tutti gli oggetti nel nostro schema.
• graphql-codegenviene quindi utilizzato per generare tipi e codice runtime per operazioni definite all'interno di .graphqlfile nei nostri pacchetti client. Il nostro pacchetto client frontend genera hook React utilizzando Apollo Client, mentre il nostro pacchetto client backend utilizza il graphql-operationspacchetto npm per generare una classe client.

C'è molto da fare, ma le cose sono molto più semplici quando elaboriamo le richieste in fase di esecuzione:

La cosa fondamentale qui è che le app non devono mai interagire direttamente con i servizi di backend, né i servizi di backend tra loro: tutte le app e i servizi inviano query e mutazioni al gateway, che quindi le invia in modo appropriato. È importante sottolineare che questo è vero anche se la richiesta richiede che i dati siano composti da più servizi.

Codice

Per concludere, facciamo entrambi un passo indietro alla generazione del codice mentre ingrandiamo per dare una breve occhiata a come appare in pratica il codice effettivo (sia sviluppato che generato).

Come ricorderai, tutto inizia con classi e resolver definiti nei nostri servizi di backend:

Da quelli, generiamo uno schema GraphQL che include:

Successivamente componiamo lo schema federato (che unisce gli schemi dei nostri vari servizi), ma lo ometteremo qui poiché il nostro esempio utilizza solo un singolo tipo di oggetto da un singolo servizio.

Quindi viene generato un boilerplate per rendere il tipo di dati e la query utilizzabili dal frontend:

Che alla fine assomiglia a qualcosa del genere:

Il client di backend e l'utilizzo sono simili, tranne che il codice generato sfrutta il graphql-requestpacchetto indipendente dall'ambiente invece degli hook Apollo/React.

Conclusione

Questo è un esempio molto semplice, ma soprattutto sarebbe altrettanto semplice da usare se il tipo di dati e il risolutore fossero molto più complicati, o anche se la query richiedesse l'assemblaggio di dati da più servizi.

Nei prossimi articoli, approfondiremo alcune delle interessanti tecnologie e tecniche di cui abbiamo appena scalfito la superficie. Se c'è qualcosa di cui sei particolarmente interessato a saperne di più, contattaci e facci sapere!