GraphQL, inventato da Facebook per risolvere un problema molto specifico, è diventato uno standard. Le applicazioni client lo utilizzano per leggere e manipolare i dati esposti dai server back-end. È così flessibile che recentemente GitHub l'ha adottata per tutte le sue API. Il paradigma è semplice e tuttavia potente tale da consentire la manipolazione flessibile e la loro composizione da molte fonti diverse. Mauro offre in questo intervento un'introduzione a GraphQL, partendo da una breve storia e poi analizzando come GraphQL risolva i tipici problemi in cui i progettisti API e i loro consumer si possono imbattere.
28. @mauroservienti#webappconf17
Recap
• It’s a specification, not an implementation
• Clients, within schema bounds, decide what they
want
• When schema evolves services can easily be
backward compatible
• A Node.js reference implementation is provided
• @ graphql.org:
• Samples
• Implementations for different stacks (graphql.org/code/)
• Intro tutorials and guidance
Inventato da Facebook. Hanno dichiarato di non aver introdotto una sola breaking change negli ultimi 2 anni
Recentemente adottato da GitHub
Se non avete controllo sui client (fai un esempio) il vostro peggior incubo sono le breaking change, in caso contrario il problema è molto relativo.
È molto semplice non ve le potete permettere. Fine de giochi.
Diciamo che in sistemi enormi (Amazon, Facebook, GitHub, i Bancomat nel mondo) possiamo dire che siamo esattamente in questa situazione
Avete quindi il problema che il business evolve, quindi i servizi evolvono e i client (o in generale chi interroga una API) non sono sotto il vostro controllo
la conseguenza è che in un dato momento T è molto probabile che un client non sia in grado di consumare una API che è cambiata
Attenzione che addictive o branching evolution non sono mai un problema, la rimozione di informazioni e quindi la contrazione dello schema è una disruptive change, che implica un profondo cambiamento nel business.
I metadati
I metadati
I metadati
I metadati
Tipi che a loro volta possono essere custom type
I metadati
Altre informazioni semplici
I metadati
E infine un nuovo tipo complesso, che dichiara una «releazione» 1 -> n
Notate il salto di qualità? La semantica anche nelle query
Mutations
Mutations
Che cosa voglio fare
Con quali informazioni
Che cosa voglio come risposta
Allo stesso modo la cooperazione avviene sulle mutation
Se non avete controllo sul client non potete sperare di dettare cosa il client vuole, è il client che decide
Quello che potete fare quindi è:
definire lo schema
Dare ad ogni servizio la possibilità di partecipare nella costruzione della risposta o nell’esecuzione della mutazione
A questo il client, nei limiti dello schema, può decidere cosa vuole
Se lo schema evolve i servizi possono garantire retrocompatibilità per la loro parte