This is the first explanation I've seen, that properly highlights the strengths of GraphQL. Any other blog or video I've seen (even recent ones), seem like they are just fanboys, repeating what somewhat else said and actually have no idea what is going on. Thank you for this video!
+Waliur Rahman Not exactly. Field functions get the thing passed that they are fields on. In the example at around 21:24, there is only one DB query for one user object with the given ID. Once that object is returned, GraphQL passes it to each field functions to do whatever you want with it: return property, do 'join', etc.
so when you define your data fetching via a function for each field is the idea that you are sending a query for each field?? this seems totally wasteful. It would make more sense to have an adapter of some sort for your data store of choice that composes a query to fetch all necessary fields. Using bandwidth in terms of overfetching is bad, but with a query for each field you are exponentially increasing network i/o... Maybe I'm confused
Charlie Hoover we definitely do not recommend doing some kind of dispatch per every field. Its expected that some fields will result in a dispatch (Promise, in JS) and others will be much cheaper simpler functions.
Lee Byron even better, with promises the persistence layer (or repository) can enqueue requests for certain things (e.g. for every event by ID) then only send a single query for all of them later (before serialization? at the next tick? - whatever seems less hacky)
This is the first explanation I've seen, that properly highlights the strengths of GraphQL.
Any other blog or video I've seen (even recent ones), seem like they are just fanboys, repeating what somewhat else said and actually have no idea what is going on.
Thank you for this video!
Best piece of media I've ever seen to help me understand graphQL
Very well presented talk and distinctive outfit. Love it!
Fantastic explanation. Also great to see the React Europe vids coming in.
Excellent work there, particularly the wonderfully abstracted way to nest queries.
Is there any example of the library hooked up to an actual db? I briefly looked through graphql repo, but could only find the graphql piece.
At 22:22 there is mention of "design and build graphql server" will we be seeing this?
Gui He /watch?v=gY48GW87Feo
Some similar goals to OData, with query projection and graph/schema definition and traversal.
Great presentation!
I liked it. Good one :)
Individual queries for each field? Say whaaaaa...t?
+Waliur Rahman Not exactly. Field functions get the thing passed that they are fields on. In the example at around 21:24, there is only one DB query for one user object with the given ID. Once that object is returned, GraphQL passes it to each field functions to do whatever you want with it: return property, do 'join', etc.
amazing
so when you define your data fetching via a function for each field is the idea that you are sending a query for each field?? this seems totally wasteful. It would make more sense to have an adapter of some sort for your data store of choice that composes a query to fetch all necessary fields. Using bandwidth in terms of overfetching is bad, but with a query for each field you are exponentially increasing network i/o... Maybe I'm confused
Charlie Hoover the function doesn't have to send the query immediately. See github.com/graphql/graphql-js/issues/26
Charlie Hoover we definitely do not recommend doing some kind of dispatch per every field. Its expected that some fields will result in a dispatch (Promise, in JS) and others will be much cheaper simpler functions.
Lee Byron even better, with promises the persistence layer (or repository) can enqueue requests for certain things (e.g. for every event by ID) then only send a single query for all of them later (before serialization? at the next tick? - whatever seems less hacky)
+Spiun666 Bingo! github.com/facebook/dataloader is an implementation of that exact idea.
good one
duh native app to embed a web page what a dumb idea