Design Graphql - più query rispetto a più variabili

0

Sto cercando di capire gli svantaggi ei vantaggi del progettare un'API graphql in due modi. Un modo è quello di normalizzare le query di livello superiore e utilizza le variabili per fornire funzionalità diverse. L'alternativa è denormalizzare e fornire query di livello superiore più sfumate. Comprensibilmente ci sono probabilmente casi d'uso per entrambi i progetti, ma voglio solo raccogliere alcune opinioni.

Da un lato, è bello avere le query di livello superiore normalizzate, poiché è facile da ricordare (soprattutto se la query è una mappatura 1 a 1 per gli oggetti codice). Un pacchetto di variabili potrebbe essere fornito come un modo per alterare la funzionalità. Spostare l'API in avanti significherebbe pochissime modifiche alle query di primo livello e più come deprecare le variabili supportate.

Questo sembra importante in quanto una delle principali inerzie che ho sperimentato con graphql riguardo alle query deprecating è la necessità di aggiornare i servizi esistenti.

D'altra parte, le query normalizzate sembrano molto "CRUD". Ho avuto molte realizzazioni dolorose che la mentalità "CRUD" non funzionerà bene con graphql in passato.

    
posta David Zhang 30.04.2018 - 15:49
fonte

0 risposte

Leggi altre domande sui tag