Personalize

Text Size

Layout

Navigation Position

[ topics . it ]

Mauro e lo Sviluppo Sostenibile

<< Il self-management non funziona, lunga vita al self-management | Home | “fat event”: cosa sono e perché crediamo ci servano >>

Services UI Composition: GraphQL

Quando abbiamo parlato di tecniche di recupero delle informazioni abbiamo introdotto il concetto di proxy.

GraphQL sembra essere la soluzione di tutti i mali :-) permettendovi di fare due cose, che voglio approfondire:

Implementare il concetto di “proxy” come lo abbiamo descritto
liberarvi del male assoluto che rappresentato dal versioning delle API REST pubbliche

Mentre il primo punto continua a farmi storce il naso, il secondo è in linea con la mia convinzione che i fat events non esistono. Appena iniziamo a parlare di scritture in un modello distribuitoci ritorneremo.

Devo assolutamente trovare il tempo di approfondire, già…trovare il tempo…

Post in questa serie:

lunedì 17 ottobre 2016 11:00

Your Comments.

# re: Services UI Composition: GraphQL
La cosa che non mi convince di GraphQL è la stessa che non mi convinceva di OData: avere un endpoint *non interno* che permette a chiunque di creare query arbitrariamente complesse è, probabilmente, forse, spararsi sui piedi da soli.

E si, lo so, finalmente con OData si può bloccare query se troppo complesse, cosa che infatti si può fare anche con i server GraphQL: il problema è che la procedura di analisi e blocco delle query permette sì di bloccare il 99% delle query che ammazzerebbero i server, ma allo stesso tempo bloccano "troppo", rendendo non eseguibili alcune query perfettamente safe.

Left by njy at 17/10/2016 17:10
# re: Services UI Composition: GraphQL
Capisco perfettamente e condivido il tuo punto di vista. Quello che mi chiedo è se i vantaggi superano gli svantaggi, potenziali, e di conseguenza in certi scenari il gioco valga la candela.

Devo studiare :)

Left by topics at 18/10/2016 10:04
# re: Services UI Composition: GraphQL
GraphQL non ha nulla a che spartire con il db mentre OData mi sembra di si.

Lo scopo è esprimere business query dove esprimi la forma dei dati che vuoi, oltre che alcuni criteri per recuperarli (e.g. paginazione), ma è principalmente la forma.

OData espone i costrutti di SQL, e quindi espone agli stessi rischi per certi versi, mentre mi *sembra* che il concetto di type system di GraphQL ti permetta di esprimere le capability del server e comunciarle al client e fintanto che il client rispetta con i suoi requisit quelle capability tutti vanno d'amore e d'accordo :)

Left by topics at 18/10/2016 16:33
# re: Services UI Composition: GraphQL
Nope, sorry: "GraphQL is a very flexible data query language. Unfortunately with flexibility comes also a danger of misuse by malicious clients. Since typical GraphQL schemas contain recursive types and circular dependencies, clients are able to send infinitely deep queries which may have high impact on server performance." (cit)

sangria-graphql.org/.../

Left by njy at 18/10/2016 18:16
# re: Services UI Composition: GraphQL
Problema interessante. Devo studiare, maledizione :)

Left by topics at 19/10/2016 15:23
# re: Services UI Composition: GraphQL
E pure io mi sa. Daje coi libri :D !

Left by njy at 19/10/2016 19:33

Comments have been closed on this topic.