Cos'è l'Overfetching?
Alla radice del motivo per cui si consiglia GraphQL c'è un concetto chiamato overfetching. In molte API, quando chiedi informazioni su un oggetto, l'API restituisce tutto ciò che conosce, perché non sa cosa ti interessa veramente. GraphQL (come SQL) ti permette di dire all'API esattamente cosa stai cercando prima che faccia la richiesta.
È come entrare in un ristorante e chiedere di portare tutto ciò che è nel menu al tavolo, per poi scegliere antipasto, portata principale e dessert. Il resto viene sprecato.
Un Esempio Pratico
Considera una query fatta da un immaginario dispositivo tascabile del cameriere:
query foodPricesForOrder {
menuItem(id: "Jxkjahdkfh==") {
id
description
longDescription
calories
price
picture
}
}
E se omettessimo longDescription? Risparmieremmo traffico di rete, anche se la query al database non risulterebbe notevolmente più veloce se tutti i campi si trovano nella stessa tabella.
Ma nota il campo picture — potrebbe essere un'immagine codificata in base64. Non la vogliamo su un'app tascabile per il cameriere. In REST, non avremmo altra scelta che riceverla, oppure lo sviluppatore dell'API dovrebbe creare un endpoint separato per le immagini. Peggio ancora, la soluzione REST potrebbe costringere il client a fare chiamate separate per ogni piatto.
Come GraphQL Risolve Questo
GraphQL ti permette di chiedere solo ciò di cui hai bisogno. Se un resolver è associato al campo picture (in AppSync, Apollo o qualsiasi server GraphQL), viene attivato solo quando quel campo appare nella query. Finché non lo includi, non ne sostieni il costo.
Questo è vero in tutta l'API Legalesign. I campi che richiedono lookup costosi — oggetti correlati, valori calcolati, payload ampi — vengono risolti solo quando li richiedi.
La Lezione
Quando progetti le tue query, pensa a quali campi ti servono davvero. Escludi tutto ciò che la tua UI non usa. Ridurrai la dimensione del payload, la latenza di rete e il carico di calcolo lato server.
Vedi Designing Queries per ulteriori linee guida pratiche.