GraphQL: è il “killer” delle API REST?

Dopo l’implementazione del supporto GraphQL in Parse, molte persone mi hanno contattato con alcune domande, alcune delle quali preoccupate per il futuro delle API REST.
GraphQL le “ucciderà”?
Cosa succederà ai miei metodi API REST? Devo riscrivere il mio codice?

In questo articolo tratterò queste domande, ma la risposta breve è: no, non dovete preoccuparvi perché GraphQL non “ucciderà” l’API REST e non dovete nemmeno preoccuparvi di riscrivere i vostri metodi API REST già funzionanti.

Allora, qual è il problema di GraphQL?

Un’idea sbagliata che la maggior parte delle persone che mi contattano ha, è che GraphQL non è qui per sostituire l’intero backend.

GraphQL non sostituirà il backend. Né il frontend.

GraphQL è un linguaggio di interrogazione, un modo per specificare per la vostra API quali informazioni state cercando e un runtime che otterrà tali informazioni dai vostri dati preesistenti.

È solo un modo diverso (migliore, direi) per dire all’applicazione esattamente ciò che deve sapere e poi ricevere quelle informazioni.

Non ci si deve preoccupare dei metodi API REST già esistenti e funzionanti. Continueranno a funzionare come adesso anche se si adotta GraphQL. L’unica cosa da notare è che GraphQL funziona solo su Parse 3.5.0 e successivi, quindi, se si proviene da Parse 2.x o precedenti, ciò implica anche un cambiamento della struttura del codice di Parse.

Quindi, se si utilizza Parse 3.0 o superiore, non ci si deve preoccupare. Basta scegliere una versione superiore alla 3.5.0 e il gioco è fatto.
Se si utilizza Parse 2.X, si dovrà fare un po’ di lavoro di codifica.

E perché GraphQL se la mia API REST funziona già?

Anche questa domanda si presenta spesso e credo che ci siano alcuni vantaggi chiave per scegliere GraphQL rispetto all’API REST.

Nel breve periodo, se la vostra applicazione è già stata scritta utilizzando l’API REST e soddisfa tutte le vostre esigenze, non ha senso migrare a GraphQL e riscrivere il codice solo per motivi di sicurezza.

D’altra parte, se state iniziando ora o prevedete un’applicazione in evoluzione, che diventerà più complessa e volete essere pronti per una manutenzione semplificata in futuro, GraphQL può davvero aggiungere e portare molto valore.

Avete detto valore?

Sì, l’ho detto.

GraphQL presenta alcuni vantaggi chiave che semplificano lo sviluppo del codice, la manutenzione nel tempo e possono persino aiutarvi a risparmiare sul trasferimento dei dati! Sì! Avete letto bene.

Andiamo avanti voce per voce:

• Semplificare lo sviluppo del codice

  All’inizio, quando si inizia con GraphQL, si potrebbe dover produrre un po’ di codice in più. Non lasciate che questo vi spaventi.
  GraphQL renderà le vostre query più semplici da scrivere, specialmente se utilizzate la nostra GraphQL Console. L’uso degli schemi creati automaticamente da Parse e la pubblicazione di metodi generici e specifici per le query e le mutazioni di tutte le vostre classi vi faranno risparmiare molto tempo. E intendo proprio tanto.
  Documentazione? Nessun problema. Abbiamo pensato anche a questo. Ed è anche generata automaticamente.
  Inoltre, con GraphQL i vostri sviluppatori potranno contare sugli schemi generati da Parse, in modo da sapere in anticipo quali sono i metodi disponibili, i parametri per ciascun metodo e anche quali sono i ritorni (output) disponibili. Non è più necessario tirare a indovinare o chiedere agli altri cosa fa quel metodo, quali parametri sono necessari o cosa restituisce. È tutto lì per voi.

• Semplificare la manutenzione

  La manutenzione con GraphQL è molto semplice. Poiché le chiamate all’API sono essenzialmente le stesse, cambiare solo la query o la mutazione che si passa, aggiungere o rimuovere valori o parametri restituiti è facile come cambiare la query o la mutazione per riceverli o consegnarli.
  Non è necessario modificare molte chiamate, blocchi o promesse. Si cambia la query o la mutazione: FATTO!

• Risparmiare sul trasferimento dei dati

  Dopo un po’ di tempo di lavoro in Back4app è abbastanza comune aiutare i clienti a ottimizzare il loro codice per ottenere risposte più veloci. E da tutti i problemi che riscontro nei codici dei clienti, la maggior parte è dovuta al recupero di dati di cui l’applicazione non ha bisogno in quel momento.
  Un errore molto comune quando si ha a che fare con le API REST o anche con i framework Parse è quello di recuperare tutte le informazioni di un oggetto, per poi utilizzarne solo una parte. Per esempio:
  Abbiamo una classe chiamata Persona con alcune proprietà: nome, telefono, indirizzo, codice fiscale, e-mail e altre ancora.
  Di solito chi usa le API REST o i framework Parse cerca di interrogare l’intero oggetto Persona, recuperando tutte le sue proprietà e poi usandone solo una o due.
  Con GraphQL, dovendo specificare esattamente le informazioni da recuperare, lo sviluppatore non ha la possibilità di recuperare informazioni non necessarie, il che si traduce in payload molto più piccoli e in risposte più rapide, minor consumo di piani dati e meno traffico in uscita in generale. Non è fantastico?

Provate

Il modo migliore per vedere i vantaggi che GraphQL può apportare al vostro processo di sviluppo è provarlo.
Ecco alcuni scenari con cui potete giocare e vedere come si comporta:

• Provare a creare una query GraphQL senza specificare esattamente ciò che si vuole recuperare

  Non sarà possibile farlo. Verrà richiesto obbligatoriamente di specificare ciò che si desidera e verrà recuperato solo quello. Nient’altro.
  Se voi o i vostri sviluppatori dimenticate di farlo, GraphQL non glielo permetterà.

Manca ciò che sto recuperando

Ecco fatto!

• Cercare di cambiare un oggetto usando una query

  No, non è così. Volete cambiare qualcosa? Usate il metodo corretto: Mutazione.
  Se voi o i vostri sviluppatori sbagliate metodo, GraphQL non li lascerà procedere.

Una query per cambiare i dati? No, no, no!

La mutazione vi copre!

• Oggetti multipli. Query multiple? No! Una sola query!

  GraphQL rende davvero facile recuperare informazioni su più oggetti con una sola query, semplificando lo sviluppo e rendendo il codice meno soggetto a errori.
  Immaginiamo di avere una classe Person e che una persona possa avere un cane, dalla classe Dog. È necessario recuperare informazioni da entrambe le classi: il nome e l’età della persona e il nome e la razza del cane. Facile facile:

Versioning? Perché?

Il codice di versionamento fa tanto 2018.
Aggiungete nuovi campi alla vostra query. Le vecchie chiamate funzioneranno ancora:

Questo funziona

Anche questo funziona. Le chiamate al vecchio tipo continueranno a funzionare.

Campi deprecati, avete detto? Anche questo è facile:

Conclusione

GraphQL non è qui per uccidere qualcosa. È qui per portare un nuovo modo di fare le cose vecchie. Migliore, più veloce, più facile da mantenere e meno incline agli errori.

Vi terrà in carreggiata quando sbaglierete. Vi dirà cosa potete o non potete fare.

Insieme a Parse e ai metodi autogenerati (sia generici che specifici) e alla documentazione, vi farà imparare la sua strada in modo semplice.

Se non avete mai provato, dovreste farlo. Tutti i ragazzi più in gamba lo fanno.

Se volete saperne di più su GraphQL e REST, consultate il nostro post su Medium.